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.
this is currently a NO-OP, but it's already useful in that it
clearly marks our hook functions that override libc.
this in preparation of adding support for MacOS 12.0.1 "Monterey",
which apparently requires a new dynlinker hooking method.
in ce655fdac8 the getnameinfo function
was factored into a separate TU to prevent its POSIX signature from
colliding with GLIBC's wrong prototype. since this has been fixed
in GLIBC 10 years ago, it should be safe by now.
undoing the workaround has the advantage that all hooked functions
are now available in the same place, which is a prerequisite for
a change i'm about to commit.
if it turns out there's still systems in use that use the old GLIBC
version with the wrong prototype, we can add a configure check
dealing with it.
introduced in 83bfa0b61d, the check_link_silent
option always returned the result from the rm -f command rather than
the result from the compiler.
fixes#400
Replace -o /dev/null by -o "$tmpc".out in check_link_silent and
check_compile otherwise test will fail with some bugged binutils
(https://sourceware.org/bugzilla/show_bug.cgi?id=19526) since version
4.13 and
35a674bdbc:
checking what's the option to use in linker to set library name ...
cannot find an option to set library name
package/pkg-generic.mk:249: recipe for target '/home/buildroot/autobuild/instance-2/output-1/build/proxychains-ng-4.14/.stamp_configured' failed
Fixes:
- http://autobuild.buildroot.org/results/9320d9b2c69882e23bbe7b30057eb8bee0c9d2e5
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
in scenarios where one is to spin up several processes with the same
proxy list in random mode, all processes started in the same second
would pick the same proxy due to using the same srand() seed.
closes#380
localnet with hostnames/DNS is not compatible with remote dns - if remote dns
is activated we get an ip from the remote dns resolver in the connect() call,
so we don't know whether the destination would match any localnet - except
from the ANY localnet 0.0.0.0 - in which case we would need to do a real DNS
lookup with the remote DNS ip involving both the rdns resolver to get the
original hostname back and then call the native DNS resolver function - for
which there is only getaddrinfo() when we don't want to support the 5
different gethostbyname_r() variants in existence, or using getaddrinfo(),
which in turn requires memory allocation/free() - in other words a huge mess.
we also can't easily check in the resolver whether an ANY-destination localnet
is enabled and the port matches, because the resolver might only resolve the
hostname at this stage, but not the destination port.
addressing #358
gethostbyname() is specified to transform simple numeric ipv4 addresses
into their binary form. since proxy_gethostbyname() was used as a
backend for all resolver functions, somehow we assumed the check for
an ipv4 was done from another site, however this didn't hold true when
the caller used gethostbyname() directly.
fixes#347
the buffer buff was only used for the initial handshake packets,
which in all supported protocols are usual less than a 100 bytes,
with user/pass and dns name at maximum we'd require 768 bytes,
which still leaves us a formidable 256 bytes for the rest of
the packet.
this fixes a segfault with microsocks which on musl uses tiny
thread stack sizes of 8KB.
careful analysis has shown that the buffer is only ever used for
at most a single hostname, so 256 bytes are sufficient.
the huge 8KB buffer caused stack overflow when used with microsocks,
which defaults to tiny thread stacks of 8KB with musl libc.
since many users complain about issues with modern, ultracomplex
clusterfuck software such as chromium, nodejs, etc, i've reconsidered
one of my original ideas how to implement remote dns lookup support.
instead of having a background thread serving requests via a pipe,
the user manually starts a background daemon process before running
proxychains, and the two processes then communicate via UDP.
this requires much less hacks (like hooking of close() to prevent
pipes from getting closed) and doesn't need to call any async-signal
unsafe code like malloc(). this means it should be much more compatible
than the previous method, however it's not as practical and slightly
slower.
it's recommended that the proxychains4-daemon runs on localhost, and
if you use proxychains-ng a lot you might want to set ip up as a service
that starts on boot. a single proxychains4-daemon should theoretically
be able to serve many parallel proxychains4 instances, but this has not
yet been tested so far. it's also possible to run the daemon on other
computers, even over internet, but currently there is no error-checking/
timeout code at all; that means the UDP connection needs to be very
stable.
the library code used for the daemon sources are from my projects
libulz[0] and htab[1], and the server code is loosely based on
microsocks[2]. their licenses are all compatible with the GPL.
if not otherwise mentioned, they're released for this purpose under
the standard proxychains-ng license (see COPYING).
[0]: https://github.com/rofl0r/libulz
[1]: https://github.com/rofl0r/htab
[2]: https://github.com/rofl0r/microsocks
using strstr() is a very error-prone way for config parsing.
for example if "proxy_dns" is being tested for the line "proxy_dns_old",
it would return true.
we fix this by removing leading and trailing whitespace from the line
to parse and use strcmp/strncmp() instead.
the if(1) has been inserted so we can keep the same indentation level
and not spam the commit with whitespace changes.
some lamer on IRC by the name of annoner/R3M0RS3/penis was complaining
that 3.1 is a lot better than proxychains-ng, because it happens to
work with the browser he's interested in.
since this wasn't the first time this is requested, let's give this
those lamers what they want: lame code!
since we caved in to demands that it should be possible to allow
hostnames in the proxy list section, we now got to deal with the
fallout. the code was calling at_get... assuming that the allocator
thread is always used.
simplify code by adding a new at_msg struct that contains both
the message header and the message body.
this allow e.g. atomic writes of the whole message instead of doing
it in 2 steps. unfortunately reads still have to be done in at least
2 steps, since there are no atomicity guarantees[0].
additionally the message header shrunk from 8 to 4 bytes.
[0]: https://stackoverflow.com/questions/14661708/under-what-conditions-are-pipe-reads-atomic
