ld_preload is the lazy way of doing userland rootkits. there are other ways. For example, you can patch libc, and by patch I mean there are different ways of p

ld_preload is the lazy way of doing userland rootkits. there are other ways. For example, you can patch libc, and by patch I mean there are different ways of patching. a simply binary patch is unreliable because it'd be pinned to a specific version but you can parse the elf symbols dynamically and patch them, even when libc is updated (assuming certain critical symbols are unlikely to ever change) so it becomes reliable. a lot of "static" programs still dynamically load libc. There is also a more aggressive but easily detectable approach, just patch every elf file on the system so that that the _start/entry always does something to prevent discovery of the malware like messing with the plt so that all function calls are proxied through rootkit code, where the rootkit filters for parameters and return values it doesn't like. Kernel rookits are great but secure boot is also a thing, if implemented correctly it would be very difficult to beat. you don't even have to go full on rootkit, just a stealthy implant running as root via a hijacked dynamic library (doesn't have to be libc) will do. this isn't windows, it's not like there is a reliable/common way of making sure system libraries are legit (like authenticode/pe signing). The package managers make sure the correct binaries are being installed but they don't have something like sfc on windows (system file checker) that refuses to let the system boot if files are corrupt and/or restore tampered system executables.