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

* * *

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.

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]