Open superevr opened 2 years ago
proxychains4 binary sets up the OS's preloading mechanism via environment variables, then execs the host binary. if the shared library then isnt injected properly, we have no way of controlling execution in that program. the only way i can imagine making this work would be to have the proxychains4 binary fork(), then exec the host binary in a second process, and then somehow communicate some "yep, it worked" status back to the proxychains4 binary. then, the main process would have to wait until the child process exits and pass on its exit status. if it didn't work, there would need to be some heuristic, like waiting a certain amount of time and then killing the child process. this appears kinda fragile, because if we wait too long the process could already have made its connections unproxified. so this seems to be a lot of effort for a half-assed solution. if you have a better idea, let me know.
I'll have to look into it more understand how the library is injected. Ideally would want a way to confirm that it was successful, but before the process sends other network traffic.
Perhaps there is a way to see if the called binary is SIP protected?
I thought it might be related to the file flag restricted
that you would see running something like below, but that theory was incorrect.
% /bin/ls -lO /usr/bin/curl [1] [7:17 PM]
-rwxr-xr-x 1 root wheel restricted,compressed 519040 May 9 16:30 /usr/bin/curl
Perhaps there is a way to see if the called binary is SIP protected?
i don't know, the entire mac support is based on figuring things out based on feedback from mac owners.
Originally posted by @rofl0r in https://github.com/rofl0r/proxychains-ng/issues/453#issuecomment-1191302363
Is it possible to detect and add a warning when hooking was unsuccessful? I understand that I can't use
/usr/bin/curl
, I'll use /opt/local/bin/curl from MacPorts instead. But if I forget, or my path is set up wrong and I use the system curl instead, it would be great to terminate the execution entirely, or at least display a warning that the connection did not go through the tunnel.Successful proxychain using non-system curl
Unsuccessful proxychain using system curl
If I'm not paying close attention, I'll see the returned IP address, the connection was successful, and not realize that it didn't load the chain it's not the correct socks server ip. Instead, I'm recommending an error like
An error like this would have saved me a good amount of troubleshooting with the macports version of proxychains-ng (4.14), which doesn't work at all on Monterey/m1 mac. It will still run curl, but not through the tunnel and give no indication of problems.
Thanks