Re:Any sufficiently advanced uninstaller is indistinguishabl...
by monocasa on Wednesday September 13, 2023 @11:30AM
(#37498119)
If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.
Re:Any sufficiently advanced uninstaller is indistinguishabl...
by sim7c00 on Wednesday September 20, 2023 @01:58PM
(#37587474)
im not sure how the implementation of ld preload works, but this is a linker directive if i am correct. the thing i am on about is the DT_DEBUG dynamic table entry. its an entry meant to allow a debugging dll to be loaded. you can overwrite it and point it to a malicious dll (with a bit of difficulties) to get injection going. its then hardcoded into tue binary by your modification. admittedly maybe ld preload is easier if thats allowed on a system
Re:Any sufficiently advanced uninstaller is indistinguishabl...
by pests on Thursday September 28, 2023 @03:08AM
(#37686335)
LD_PRELOAD is handled entirely by ld.so and includeed inside your ELF by the linker. It not only handles that but also all dynamic linking inside your program.
By writing a custom linker you can easily incercept all dynamic linking done at runtime and provide whatever you want to the program.
gcc -Wl,-dynamic-linker,/path/to/my/linker myprogram.c -o myprogram
AV/EDR products do try to prevent a lot of stuff. They can 'generically' block things like injection etc. by 'hooking all the things' and injecting into everything (yes, yuck :D and still kind of heuristic based i admit!) to make certain sections read only or remove executable mappings etc. (got/plt/stack/...)
Linux or more specifically ELF files also have an easy vector to allow injection by having a dynamic table entry for debugging purposes which can be trivially overwritten for example. "ibc.so" :(). I'm not sure anyone uses that entry validly... especially since there's better/less awkward debugging interfaces than injecting a debugger DLL into something :') at least in x86/64 Linux land. (ELFShell sure was fun tho!)