Hacker News Reader

Comment by 1vuio0pswjnm7 | Hacker News Reader

None of the previous discussions on HN mentioned using readelf instead of ldd.

Whenever I want to quickly check for dynamically linked libraries in a program, I use

   readelf -d program

The use case I have is that I want to know what are the dependencies the program needs from the host system.

If I wanted to know what are the dependencies of a particular shared library I can use

   readelf -d library

View on HN

Note lddtree from pax-utils requires python and the elftools module, even though one can use readelf and objdump instead of python. https://raw.githubusercontent.com/ncopa/lddtree/main/lddtree...

If I wanted a recursive listing I would use libtree, a 56k .c file.

https://raw.githubusercontent.com/haampie/libtree/master/lib...

(author of libtree): I believe that downloading, compiling and running libtree is faster than the startup overhead of pax-utils lddtree ;) maybe C is the better scripting language?

    $ alias latest_libtree='curl -Lfs https://raw.githubusercontent.com/haampie/libtree/master/libtree.c | cc -o /tmp/libtree -x c - -std=c99 -D_FILE_OFFSET_BITS=64; /tmp/libtree'

    $ time latest_libtree /usr/bin/vim

    real 0m0.179s
    user 0m0.119s
    sys 0m0.019s
    /usr/bin/vim 
    ├── libpython3.11.so.1.0 [ld.so.conf]
    │   ├── libexpat.so.1 [ld.so.conf]
    │   └── libz.so.1 [ld.so.conf]
    ├── libgpm.so.2 [ld.so.conf]
    ├── libacl.so.1 [ld.so.conf]
    ├── libsodium.so.23 [ld.so.conf]
    ├── libselinux.so.1 [ld.so.conf]
    │   └── libpcre2-8.so.0 [ld.so.conf]
    └── libtinfo.so.6 [ld.so.conf]

That's great, but unlike ldd, readelf won't walk the list of dependencies recursively.

never fear, recursive and concat unix piping to the rescue

At that point, why not just use ldd?

Because it executes the binary

If 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.

How exactly it would fool readelf, which works on entirely different principles?

Eg. 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.

Reply on news.ycombinator.com