Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Fun fact: proxychains uses LD_PRELOAD [0] to hook the necessary syscalls [1] for setting up a "proxy environment" for the wrapped program, e.g. `connect`, `gethostbyname`, `gethostbyaddr`, etc. (Note this also implies that it could be leaky in some cases when applied to a program that uses alternative syscalls to make an external connection, or a program that is not dynamically linked. I would not recommend depending on proxychains for any sort of opsec, even though it's often recommended as such a tool.)

[0] https://github.com/haad/proxychains/blob/master/src/proxycha...

[1] https://github.com/haad/proxychains/blob/master/src/libproxy...



There are a lot of small utilities which are built upon LD_PRELOAD, for example.

- fakeroot: Gives the running program the impression that it is running as root, often used for example for building debian packages. This will let the build script create a directory tree which it believes is owned by root and then when that directory tree is packed by tar, tar will also see root as the owner and the .tar-archive will have root as the user/group for the files in the final debian package.

- faketime: Gives the running program the impression that it is running at some specific time. Usefull for testing code during specific events like leap-years, etc.

- eatmydata: Will ignore all fsync() and related system calls which ensures files are written to permanent storage. I have used this once for running a database during a testsuite, and databases are much faster when they do not have to wait for the data to reach permanent storage.


My favorite tool that (ab)uses LD_PRELOAD to do something useful is `stdbuf`: https://linux.die.net/man/1/stdbuf

The implementation is completely bonkers. The tool sets some environmental variables, then spawns a child process with LD_PRELOAD set to load a library (libstdbuf.so) which has a some initialization code that runs when the library is loaded, and that based on the environmental variables, calls setvbuf() from inside the child process to override the buffering behavior.


tsocks: route all network traffic through a socks gateway with elegant per-process controls. (i guess a proxychains ancestor?)


faketime could've been used to circumvent time bombs in software. This could for example allow you eternal trial access. Nowadays stuff just requires networking with internet connection though.

You could also use LD_PRELOAD to get a different MAC address. This would've work with FlexLM.

Though its probably easier with a bit of hexediting or disassembling to modify the binary personally, I get fuzzy feelings of love from the type of software cracking which does not require modified binaries.


libnaw uses it to wrap and authenticate connect() and accept() calls.

frida uses it to wrap and inject... anything.

These programs have all been around for quite a long time. I think libnaw has been around since early 2000s at least.


> proxychains uses LD_PRELOAD [0] to hook the necessary syscalls [1]

Technically, it uses LD_PRELOAD to hook the necessary libc functions. As, at least on x86-64, a syscall is just a CPU instruction like any other, you can't hook into it through LD_PRELOAD or any other tricks that don't involve the kernel (apart from rewriting the program before you execute it). That's also why it doesn't work on e.g. Go programs, as they don't use libc.


> As, at least on x86-64, a syscall is just a CPU instruction like any other, you can't hook into it through LD_PRELOAD or any other tricks that don't involve the kernel (apart from rewriting the program before you execute it).

On most Unix systems, you can use ptrace to intercept system calls from another process. This is how tools like rr or strace work.


Ptrace is one of a number of ways to hook syscalls without LD_PRELOAD.

The gVisor docs list 3 ways: KVM, systrap, ptrace https://gvisor.dev/docs/architecture_guide/platforms/ :

> systrap: The systrap platform relies seccomp’s SECCOMP_RET_TRAP feature in order to intercept system calls. This makes the kernel send SIGSYS to the triggering thread, which hands over control to gVisor to handle the system call. For more details, please see the systrap README file.

> systrap replaced ptrace as the default gVisor platform in mid-2023. If you depend on ptrace, and systrap doesn’t fulfill your needs, please voice your feedback.

> ptrace: The ptrace platform uses PTRACE_SYSEMU to execute user code without allowing it to execute host system calls. This platform can run anywhere that ptrace works (even VMs without nested virtualization), which is ubiquitous.

> Unfortunately, the ptrace platform has high context switch overhead, so system call-heavy applications may pay a performance penalty. For this reason, systrap is almost always the better choice.

The Falco docs list 3 syscall event drivers: Kernel module, Classic eBPF probe, and Modern eBPF probe: https://falco.org/docs/event-sources/kernel/

Dynamic linker > Systems using ELF: https://en.wikipedia.org/wiki/Dynamic_linker#Systems_using_E...


The tup[1] build system also uses ldpreload injection as an aspect of its (additionally(?) FUSE-based) dependency-specification enforcement.

1: https://github.com/gittup/tup/blob/master/src/ldpreload/ldpr...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: