Hacker News Reader

I guess I wasn't sure that DT_NEEDED entries covered everything. Sometimes you have stuff that happens in DT_INIT constructors.

View on HN

Dynamic dlopen calls do not appear in the ELF at all, these are "normal" function calls.

correct. you cam call dlopen anywhere so loading it into memory or even executing all easy to reach paths wont guarantee you'd get that. you might do full symbolic execution but your 'ldd' might take days or weeks :'D

My model for LDD in my head was, "run the app up until the entry point of the executable, print the loaded DSOs, and exit() before ever starting the exe." That'd get you potentially more libraries than if you just statically examine the needed libraries recursively.

I think in this case, you might be able to resolve the ones in DT_NEEDED on the disk, and parse those elf headers, and do that until they don't have any DT_NEEDED in there anymore which you didn't touch.

The reason it doesn't find all with a simple elf-parse is that included libs might depend on other libs. I'd say if your linker can figure out before executing anything after the entry-point what to resolve, it has read it from ELF files it has seen by parsing the initial executable.

I was really surprised honestly to see LDD executes stuff, but I suppose it's a very old thing, from before 'untrusted' executables were really a (big) thing.

Reply on news.ycombinator.com