3 ms·
That's great, but unlike ldd, readelf won't walk the list of dependencies recursively.
by wyldfire 3y ago
That's great, but unlike ldd, readelf won't walk the list of dependencies recursively.
- deleted 3y ago[deleted]
- mycall 3y agonever fear, recursive and concat unix piping to the rescue
- stingraycharles 3y agoAt that point, why not just use ldd?
- saagarjha 3y agoBecause it executes the binary
- jagrsw 3y agoIf you're worried (like really worried) about a binary, then it can easily fool readelf (btw, it can fool ldd too), so eg the data from the ELF header is never used. Probably running `strace` or `perf record -e intel_pt` in a confined environ is the best option to see what a binary really does, short of using ida/disasm/gdb - but then a binary can discover the use of strace too, and behave differently :). It's turtles all the way down.
- SomeRndName11 3y agoHow exactly it would fool readelf, which works on entirely different principles?
- jagrsw 3y agoEg. by changing PT_INTERP to something else than usual (or dispensing with it, so the binary becomes a static one, still displaying DT_NEEDED), or exploiting bugs in ld.so, so the values shown by readelf become meaningless. I'm also not entirely sure that readelf/binutils was reviewed from sec-perspective, it might not be out of the question that readelf might show things which are then interpreted differently by either kernel (loading a basic static bin or ld.so/interpreter) or by ld.so itself.