Replace the global export lookup with a fixed list of system
libraries (libc.so, libc.so.6, libsystem_c/kernel/pthread), using
whichever are present, to avoid matching same-named exports from the
app's own code, per review feedback.
fcntl is not exported by libsystem_c.dylib on Darwin (it lives in
libsystem_kernel.dylib), so the setup block threw and aborted all
native hooks, leaving connect() uninstrumented. Resolve each symbol
from the module first, then fall back to a global lookup.
Previously SOCKS interception didn't work without DEBUG_MODE (whoops)
and tried to intercept UDP even though that wouldn't work either. We no
longer intercept UDP at all (although we can block it for HTTP/3) and
everything should work correctly the rest of the time, with some other
improvements around logging en route.
Since the global Java bridge isn't available, Java.available doesn't
generally work. In the native connect script, our new approach was
incomplete due to using raw kernel APIs instead of the libc compatible
layer (which seems to be the standard API).
This reverts commit 6eec741f5c.
This doensn't actually work correctly, as connect() will return -1
(treated here as failure) for sockets that are still in progress, when
opened non-blocking, and therefore we end up logging these as failures.
We need to handle async connection state detection - that's a bit fiddly
from inside Frida, so for now let's just roll this back.
b1gb1t