New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doesn't work in macOS 12.0.1 #409
Comments
check the issues threads here for macOS, there's a ton of things you have to do work around SIP, and let us know how you solved it once you solved it. |
Will do, I think you can also check .dylib’s compatibility. I’ve seen other software have dylib compatibility on macOS 12, like some software crack by TNT team. TNT use dylib injection to crack software and doesn’t work on macOS12 x86 anymore after there dylib adapted arm64. |
so it's probably because of fat binaries. i overheard in another thread here that apparently if a program (say, curl) is built as fat binary with arm + x86_64, the injected dylib needs to use the same format (e.g. fat arm64+x86_64), even though only one of the 2 embedded archs is used. |
Not exactly, TNT's issue showed up after they |
Same issue here, it does not work after Monterey upgrade. |
well, then i guess someone needs to investigate what changed. |
for the next chinese guy about to copy paste the text "Same issue here, it does not work after Monterey upgrade." : your comment won't change anything, so don't do it. what you should do instead is research WHY it doesn't work, and then share your findings and/or propose a solution. |
Don't work after upgrading to Monterey. And I got this. May be caused by the new SIP.
|
but sip should only effect shipped bin. |
Don't work after upgrading to Monterey +1. Even though I disable SIP ❯ csrutil status
System Integrity Protection status: disabled. I have try |
Don't work after upgrading to Monterey. With SIP disabled. I Compiled source with DEBUG enabled, test with a simple c program: #include <stdio.h>
#include <sys/socket.h>
#include <dlfcn.h>
int main() {
printf("dlsym function address => %p\n", &dlsym);
printf("connect function address => %p\n", &connect);
return 0;
} And got these output:
|
I tried to add the following line into your source file: |
interesting find. how can we apply this to get proxychains working again ? |
If with DYLD_FORCE_FLAT_NAMESPACE disabled, the DYLD_INTERPOSE macro still works. #include <stdio.h>
#include <netdb.h>
#include <sys/socket.h>
#include <dlfcn.h>
#define DYLD_INTERPOSE(_replacement,_replacee) \
__attribute__((used)) static struct{ const void* replacement; const void* replacee; } _interpose_##_replacee \
__attribute__ ((section ("__DATA,__interpose"))) = { (const void*)(unsigned long)&_replacement, (const void*)(unsigned long)&_replacee };
int my_connect(int sock, const struct sockaddr *addr, unsigned int len) {
printf("\033[31;1mhook connect function, real connect function => %p.\033[0m\n", &connect);
return connect(sock, addr, len);
}
int my_getaddrinfo(const char *node, const char *service, const struct addrinfo *hints, struct addrinfo **res) {
printf("\033[31;1mhook getaddrinfo: %s %s, real connect function => %p.\033[0m\n", node ? node : "null", service ? service : "null", &getaddrinfo);
return getaddrinfo(node, service, hints, res);
}
int main(int argc, const char * argv[]) {
return 0;
}
DYLD_INTERPOSE(my_connect, connect)
DYLD_INTERPOSE(my_getaddrinfo,getaddrinfo) Compile command: |
that's good news, thanks for your research. earlier you said:
did you try whether adding this to proxychains-ng Makefile makes proxychains work ? or would this need to be added to both proxychains-ng and the program hooked ? |
The -flat_namespace flag should be added to the program hooked, because it defines how the program hooked would find the function. Therefore adding -flat_namespace is not a real solution, it's just a clue, since we can't recompile every program we use in order to make this work. That's why we used the DYLD_FORCE_FLAT_NAMESPACE environment variable before, it takes the same effect as -flat_namespace flag, but in runtime. |
there's currently no build system support yet. after ./configure was executed, add -DMONTEREY_HOOKING to CFLAGS/CPPFLAGS in config.mak to activate this. addressing #409
@yicong2007 i've pushed a branch called |
Thanks @rofl0r Here is the screen shot: |
cool. now the only thing left to do is to figure out whether (and how) to enable this unconditionally on OSX >= 12.0.1 via the build system. |
there's currently no build system support yet. after ./configure was executed, add -DMONTEREY_HOOKING to CFLAGS/CPPFLAGS in config.mak to activate this. addressing #409 special thanks go to @yicong2007 and @YangshengLu for helping to figure out this new technique.
if anyone still uses big sur, it might be interesting to see whether the new hooking method also improves things there, and if so, modify the detection in configure to use it there as well. |
I don't understand, can you detontinence? |
if you have big sur, you could test whether manually turning on monterey hooking method using the instructions in the above mentioned commit message improves things. there's been some reports here that proxychains-ng doesn't work on big sur, but it appears to be have been caused by toolchain issues when targeting M1 aarch64 chip. |
Hi guys! Do I have to disable SIP to make proxychains-ng working on Monterey 12.1/M1? I have just compiled monterey branch and the curl seems to go directly to the net without my tor proxy... Best Regards, |
|
Thanks for your answer - master compiled (config.mak checked for the -DMONTEREY_HOOKING flag), SIP enabled and proxychains doesn't work... Best Regards, |
do you use system curl or homebrew curl ? the former is known to not work with hooking (any system binaries, that is). |
For me, confirming that system curl doesn't work but homebrew curl works. Monterey 12.1. Thanks for the fix!
(No DLL init log for system curl) |
Environment: macOS 12.0.1 x86_64, SIP disabled
I have ran
proxychains4 curl cip.cc
and no connection to socks server. It's same to shipped curl and curl from brew.but in kali it's fine(proved socks server works)
The text was updated successfully, but these errors were encountered: