3 ms·

The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice. AV/EDR produc

The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice. 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!)

monocasa 3y ago
If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.
- sim7c00 3y ago
  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
  - pests 3y ago
    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

monocasa 3y ago

If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.

sim7c00 3y ago
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
- pests 3y ago
  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