Skip to content
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

Closed
starryloki opened this issue Oct 21, 2021 · 27 comments
Closed

doesn't work in macOS 12.0.1 #409

starryloki opened this issue Oct 21, 2021 · 27 comments

Comments

@starryloki
Copy link

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.
image
image
but in kali it's fine(proved socks server works)
image

@rofl0r
Copy link
Owner

rofl0r commented Oct 21, 2021

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.

@starryloki
Copy link
Author

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.

@rofl0r
Copy link
Owner

rofl0r commented Oct 21, 2021

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.

@starryloki
Copy link
Author

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 adapted arm64 and only crash at intel in macOS12. At least I can use proxychains4 correctly in macOS11 x86.Although it may not be relevant.

@isokaze04
Copy link

Same issue here, it does not work after Monterey upgrade.

@rofl0r
Copy link
Owner

rofl0r commented Nov 1, 2021

well, then i guess someone needs to investigate what changed.

@rofl0r
Copy link
Owner

rofl0r commented Nov 5, 2021

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.

@NikoXu
Copy link

NikoXu commented Nov 16, 2021

Don't work after upgrading to Monterey.

And I got this. May be caused by the new SIP.

(base) ➜  project git:(main) csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

@starryloki
Copy link
Author

Don't work after upgrading to Monterey.

And I got this. May be caused by the new SIP.

(base) ➜  project git:(main) csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

but sip should only effect shipped bin.

@ifmung
Copy link

ifmung commented Dec 7, 2021

Don't work after upgrading to Monterey.

And I got this. May be caused by the new SIP.

(base) ➜  project git:(main) csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Don't work after upgrading to Monterey +1.

Even though I disable SIP

❯ csrutil status
System Integrity Protection status: disabled.

I have try brew or source compile to install, but the result is same that it always using my real IP.

@YangshengLu
Copy link

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:

[proxychains] config file found: /Users/luyangsheng/.proxychains/proxychains.conf
[proxychains] preloading /Users/luyangsheng/AndroidStudioProjects/proxychains-ng/libproxychains4.dylib
DEBUG:pid[40961]:init_lib_wrapper called from gcc_init
DEBUG:pid[40961]:get_chain_data()
DEBUG:pid[40961]:proxy_dns: thread
DEBUG:pid[40961]:[play] socks5 127.0.0.1:7891
[proxychains] DLL init: proxychains-ng 4.15-git-1-g7de7dd0
DEBUG:pid[40961]:loaded symbol 'connect' real addr 0x7ff81f511fe8  wrapped addr 0x10deb4540
DEBUG:pid[40961]:loaded symbol 'sendto' real addr 0x7ff81f512000  wrapped addr 0x10deb5470
DEBUG:pid[40961]:loaded symbol 'gethostbyname' real addr 0x7ff81f57cfb5  wrapped addr 0x10deb4e60
DEBUG:pid[40961]:loaded symbol 'getaddrinfo' real addr 0x7ff81f56c0b6  wrapped addr 0x10deb4f00
DEBUG:pid[40961]:loaded symbol 'freeaddrinfo' real addr 0x7ff81f56d88d  wrapped addr 0x10deb5000
DEBUG:pid[40961]:loaded symbol 'gethostbyaddr' real addr 0x7ff81f57d21d  wrapped addr 0x10deb5340
DEBUG:pid[40961]:loaded symbol 'getnameinfo' real addr 0x7ff81f56efa8  wrapped addr 0x10deb02e0
DEBUG:pid[40961]:loaded symbol 'close' real addr 0x7ff81f50f4c4  wrapped addr 0x10deb4430
DEBUG:pid[40961]:at_init()
DEBUG:pid[40961]:wait_data()
dlsym function address => 0x7ff81f55210f
connect function address => 0x7ff81f511fe8

connect function address is not change. it should be 0x10deb4540 but was 0x7ff81f55210f.
maybe DYLD_INSERT_LIBRARIES is not working anymore?

@yicong2007
Copy link

yicong2007 commented Dec 10, 2021

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:

[proxychains] config file found: /Users/luyangsheng/.proxychains/proxychains.conf
[proxychains] preloading /Users/luyangsheng/AndroidStudioProjects/proxychains-ng/libproxychains4.dylib
DEBUG:pid[40961]:init_lib_wrapper called from gcc_init
DEBUG:pid[40961]:get_chain_data()
DEBUG:pid[40961]:proxy_dns: thread
DEBUG:pid[40961]:[play] socks5 127.0.0.1:7891
[proxychains] DLL init: proxychains-ng 4.15-git-1-g7de7dd0
DEBUG:pid[40961]:loaded symbol 'connect' real addr 0x7ff81f511fe8  wrapped addr 0x10deb4540
DEBUG:pid[40961]:loaded symbol 'sendto' real addr 0x7ff81f512000  wrapped addr 0x10deb5470
DEBUG:pid[40961]:loaded symbol 'gethostbyname' real addr 0x7ff81f57cfb5  wrapped addr 0x10deb4e60
DEBUG:pid[40961]:loaded symbol 'getaddrinfo' real addr 0x7ff81f56c0b6  wrapped addr 0x10deb4f00
DEBUG:pid[40961]:loaded symbol 'freeaddrinfo' real addr 0x7ff81f56d88d  wrapped addr 0x10deb5000
DEBUG:pid[40961]:loaded symbol 'gethostbyaddr' real addr 0x7ff81f57d21d  wrapped addr 0x10deb5340
DEBUG:pid[40961]:loaded symbol 'getnameinfo' real addr 0x7ff81f56efa8  wrapped addr 0x10deb02e0
DEBUG:pid[40961]:loaded symbol 'close' real addr 0x7ff81f50f4c4  wrapped addr 0x10deb4430
DEBUG:pid[40961]:at_init()
DEBUG:pid[40961]:wait_data()
dlsym function address => 0x7ff81f55210f
connect function address => 0x7ff81f511fe8

connect function address is not change. it should be 0x10deb4540 but was 0x7ff81f55210f. maybe DYLD_INSERT_LIBRARIES is not working anymore?

I tried to add the following line into your source file:
printf("connect function address from dlsym => %p\n", dlsym(RTLD_DEFAULT, "connect"));
and it turns out that dlsym(RTLD_DEFAULT, "connect") gets the wrapped address as expected.
So DYLD_INSERT_LIBRARIES does work.
Add -flat_namespace in the compile stage of the simple C program and IT WORKS.
So it got to be DYLD_FORCE_FLAT_NAMESPACE that is not working.

@rofl0r
Copy link
Owner

rofl0r commented Dec 11, 2021

So it got to be DYLD_FORCE_FLAT_NAMESPACE that is not working.

interesting find. how can we apply this to get proxychains working again ?

@yicong2007
Copy link

So it got to be DYLD_FORCE_FLAT_NAMESPACE that is not working.

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.
example source file (hookconnect.c):

#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:gcc -dynamiclib hookconnect.c -o hookconnect.dylib
result:

@rofl0r
Copy link
Owner

rofl0r commented Dec 11, 2021

that's good news, thanks for your research.

earlier you said:

Add -flat_namespace in the compile stage of the simple C program and IT WORKS.

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 ?

@yicong2007
Copy link

yicong2007 commented Dec 12, 2021

that's good news, thanks for your research.

earlier you said:

Add -flat_namespace in the compile stage of the simple C program and IT WORKS.

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.
Therefore, if DYLD_FORCE_FLAT_NAMESPACE does not work now, and -flat_namespace in compile time is not practical, we have to face on the two-level namespace feature of the macOS, then we can use the DYLD_INTERPOSE macro.

rofl0r added a commit that referenced this issue Dec 12, 2021
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
@rofl0r
Copy link
Owner

rofl0r commented Dec 12, 2021

@yicong2007 i've pushed a branch called monterey, could you try whether this fixes the issue ?
pls see commit message of last commit of that branch to see how to activate the new code.

@malash
Copy link

malash commented Dec 13, 2021

Thanks @rofl0r
By following your comment after ./configure was executed, add -DMONTEREY_HOOKING to CFLAGS/CPPFLAGS in config.mak I try that branch on macOS Monterey 12.0.1 and it does work.

Here is the screen shot:

image

@rofl0r
Copy link
Owner

rofl0r commented Dec 13, 2021

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.

rofl0r added a commit that referenced this issue Dec 14, 2021
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.
@rofl0r rofl0r closed this as completed in e20c08f Dec 14, 2021
@rofl0r
Copy link
Owner

rofl0r commented Dec 14, 2021

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.

@asdfkj1
Copy link

asdfkj1 commented Dec 16, 2021

I don't understand, can you detontinence?

@rofl0r
Copy link
Owner

rofl0r commented Dec 16, 2021

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.

@jrydval
Copy link

jrydval commented Dec 29, 2021

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,
Jan

@rofl0r
Copy link
Owner

rofl0r commented Dec 29, 2021

  1. you need to compile master branch. monterey branch is already outdated.
  2. you probably need to disable SIP (but please try with master first and let us know whether it works without)

@jrydval
Copy link

jrydval commented Dec 29, 2021

Thanks for your answer - master compiled (config.mak checked for the -DMONTEREY_HOOKING flag), SIP enabled and proxychains doesn't work...

Best Regards,
Jan

@rofl0r
Copy link
Owner

rofl0r commented Dec 29, 2021

do you use system curl or homebrew curl ? the former is known to not work with hooking (any system binaries, that is).

@wandermyz
Copy link

wandermyz commented Jan 4, 2022

For me, confirming that system curl doesn't work but homebrew curl works. Monterey 12.1. Thanks for the fix!

proxychains4 /usr/local/opt/curl/bin/curl https://www.google.com
[proxychains] config file found: /usr/local/etc/proxychains.conf
[proxychains] preloading /usr/local/lib/libproxychains4.dylib
[proxychains] DLL init: proxychains-ng 4.15-git-8-g2739fb5
proxychains4 /usr/bin/curl https://www.google.com
[proxychains] config file found: /usr/local/etc/proxychains.conf
[proxychains] preloading /usr/local/lib/libproxychains4.dylib

(No DLL init log for system curl)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests