4 ms·
This may be a good time to ask since I've been recommended to use LD_PRELOAD but it's always caused issues. Imagine this, a 'Bootstrap.so' is injected into a p
by convery 9y ago
This may be a good time to ask since I've been recommended to use LD_PRELOAD but it's always caused issues.
Imagine this, a 'Bootstrap.so' is injected into a process via LD_PRELOAD. This bootstrapper places a jump on the programs entrypoint that jumps to a bootstrap::callback function. This function wants to load other shared libraries though. So when it starts loading another library the bootstrapper gets unloaded and reloaded, which ofcourse breaks execution.
Would anyone know how to properly deal with this?
- saurik 9y agoWhy is the bootstrap.so being unloaded? It should be loaded into the process pretty permanently. If you have something calling dlopen/dlclose on it, maybe give it an extra dlopen.
- convery 9y agoThat's the issue, it shouldn't be unloaded. Yet when bootstrap.so calls dlopen(other.so); bootstrap.so gets unloaded and reloaded. I'll try adding a dlopen(bootstap.so) in the callback to increase the refcount though.
- Erwin 9y agoI experienced something similar in my data-driven permission restriction DSO. Turns out I was calling my initialization function multiple times because the system calls I overrode were called before my attribute((constructor)) function. I'd recommend running your program under gdb with a breakpoint in your function and checking out what the stack is like. Maybe your function is getting called from an unexpected place. In my case I was overriding fopen64 but glibc wanted to open some NSS related files before my init function was called.