1

After compiling proxychains-ng with Apple Silicon --fat-binary-m1 support on macOS 12 (M1 Max), I'm finding that the binary is immediately terminated by the operating system. Intuition pushed me towards thinking there's some kind of a permission problem, but I've been unable to isolate such a problem so far. Even when running lldb it doesn't even get to an initial breakpoint.

I'll share the pertinent shell results in macOS that lead me to this point in hoping that someone might have seen something similar or may know what's going on:

$ git clone https://github.com/rofl0r/proxychains-ng.git
$ cd proxychains-ng
$ CFLAGS="-g3 -O0" ./configure --fat-binary-m1 --sysconfdir=/opt/homebrew/etc/
...
$ make
$ ./proxychains4
fish: Job 1, './proxychains4' terminated by signal SIGKILL (Forced quit)
$ ./proxychains4 ping 1.1.1.1                                                                                           
fish: Job 1, './proxychains4 ping 1.1.1.1' terminated by signal SIGKILL (Forced quit)
$ lldb proxychains4 ping 1.1.1.1
(lldb) target create "proxychains4"
Current executable set to '~/src/proxychains-ng/proxychains4' (arm64e).
(lldb) settings set -- target.run-args  "ping" "1.1.1.1"
(lldb) b main
Breakpoint 1: where = proxychains4`main + 60 at main.c:69:8, address = 0x0000000100003578
(lldb) run
error: process exited with status -1 (no such process.)

For good measure I've verified that SIP and Gatekeeper are off:

$ csrutil status                                                                                                      
System Integrity Protection status: disabled.
$ spctl --status
assessments disabled

In attempting to dig a bit deeper to see if there's a system call that's triggering the kill, I can't seem to get anywhere. ktrace and dtruss just aren't getting me anywhere.

Any thoughts on what's going on here?

ylluminate
  • 12,102
  • 17
  • 78
  • 152
  • Look in the system console log (you can see this in Console.app). That's a bit of a firehose, so you have to first find where debugserver (that's the debug stub lldb uses to actually control programs) starts up by filtering for messages from "debugserver". You might see debugserver telling you why the app failed to launch. Or, if another agent disallowed the launch, it might write that error in the log around the debugserver messages. The best way to find that is to note down the time of the debugserver message, undo the filter, and then scroll back to that time. – Jim Ingham Jun 09 '22 at 17:51
  • Note, Console.app doesn't record these messages when it is not open, so you first have to open Console.app, select the system log, THEN start your debug session, then do the searches above. – Jim Ingham Jun 09 '22 at 17:53
  • Thanks @JimIngham do you happen to have a shell/Terminal based methodology for log tailing now that Apple's mucked up logging that makes things a little cleaner and simpler to isolate things? I really hate opening Console.app nowadays. – ylluminate Jun 09 '22 at 21:12
  • There's a "log" command for this purpose. `man log` has lots of details on its uses. – Jim Ingham Jun 09 '22 at 22:34

1 Answers1

4

I think I know what is going on. You have built a Universal binary including an arm64e slice. Since the arm64e ABI is not yet stable, only system binaries can use the arm64e ABI. In terminal, the system just ignores the arm64e slice, since it isn't allowed to run, and runs the arm64 one instead. But lldb isn't as restrictive, and tries to run the arm64e slice, and that fails. You can fix this either by not building the arm64e slice (which isn't going to run anyway). Or you can do target create -arch arm64 proxychains4 to tell lldb to run the arm64 slice.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • Very interesting. I'll need to dig into this a little further. I think the reason that this is being used is so that it can be executed with both types of binaries that may be used in the shell with it. Sometimes some things from Homebrew and otherwise are x64 while other times they're arm64... Not sure what to think about what will come of this kind of dual-usage scenario given your remarks/observation here. I'll test this when I get a chance this evening. – ylluminate Jun 09 '22 at 21:14
  • It makes sense to build universal {x86_64/arm64} binaries for the reasons you describe. But there are no systems that ONLY run arm64e binaries. So for all practical purposes at present arm64 and x86_64 are the two you need to get a binary that will run everywhere. Unless you are trying to play around with the arm64e ABI specifically I don't think there's any reason to include arm64e till the ABI is declared final. – Jim Ingham Jun 09 '22 at 22:37
  • Very interesting - https://github.com/rofl0r/proxychains-ng/issues/453#issuecomment-1151703574 reports that other people have reported success with "arm64e" arch... Discombobulating!!! – ylluminate Jun 10 '22 at 00:07
  • There's a boot-arg that will allow the use of the arm64e ABI, for instance: https://stackoverflow.com/questions/67695609/building-for-arm64e-on-apple-silicon Most likely the people reporting success have that boot arg set. – Jim Ingham Jun 10 '22 at 16:39
  • Ah, that makes sense. Nice find and thanks for calling attention to that. Will investigate further. I assume that adding this boot-arg will facilitate still running `arm64`, but also then in addition `arm64e` so as to have both available, right? – ylluminate Jun 10 '22 at 17:28
  • 1
    Right. At this point arm64e is opt-in (with currently a small set of invitee's). This just allows developers to play around with the ABI. – Jim Ingham Jun 10 '22 at 17:37