Question: Is it possible to get source module of an imported symbol?

[crazyhouse33]

Hi, I am not an expert in executable format and I must admit that it's really intimidating. Still I would like to get the origin source file of needed symbols from shared libraries. Lief looks like a good thing to use to do it in a cross platform manner. I read the doc and explored the api with a python interpreter. Yet I cant find a way of:

1. Get the path of the shared library defining a needed symbol. (That I can obtain via binary.dynamic_symbols)
2. Exploit the debug section of the shared library to get the source file defining the symbol.

Is there a way to do this with Lief?

Better yet, are you aware of a way to force the linker to print the info at link time ? Linker map only does the job for STATIC libs.

I am sorry to bother, I am not a security guy and despite documenting myself on the executable/ shared library subject, I still feel a bit lost. It seem to me that what I want to do should be doable, yet I really struggle to find a way of doing it.

[romainthomas]

Hello @crazyhouse33

Get the path of the shared library defining a needed symbol. (That I can obtain via binary.dynamic_symbols)

There is not simple way to do that. The loader will take the the first library that export the given symbol.

Exploit the debug section of the shared library to get the source file defining the symbol.

If the binary has been compiled with Dwarf information you could get the source filename associated with a given symbol but LIEF does not support Dwarf (yet?). Nevertheless you could use libelfin or pyelftools

Better yet, are you aware of a way to force the linker to print the info at link time

LD_DEBUG=all /bin/ls 

[crazyhouse33]

Okay. It would be amazing for lief to support DWARF. I will dig what info I can get from LD_DEBUG. I thought this kind of LD variable had effect only at runtime. I really thanks you for the hint. I will see what I can do with, report it here (even thought it's not lief related) for the eventual next guy that google this, and close the issue afterward.

[crazyhouse33]

The LD_DEBUG don't output object origin of a symbol, just the so from where to take it. Still it's a way to:

Get the path of the shared library defining a needed symbol

Unfortunately the LD env variables are indeed only useful at runtime and it seem that I am forced to run the process that the loader load, where it would be cool to load with BIND_NOW to get what I want without running the image with another option.

So I surrender on forcing the linker to output stuff at link time.

I still want to use lief. Use binary.dynamic_symbols, then run lib.binary.exported_symbols to match them up in the same libraries order (bin.libraries). Then I would have to use whatever the cross platform external tool/lib to parse the dwarf and get the original object file.

Regarding what I want to do, I would like to know if I really can do it like that with Lief:

1. Would it be really cross platform, because you tagged the question as ELF where I am looking for a cross platform solution.
2. Does the bin.libraries list is listed in the same order as the loader check the libraries for bindings?
3. By comparing ldd output with lief libraries, 2 seems okay. But some libraries are missing. I guess it's because libraries don't list libraries needed by the shared libraries linked to? So I need to take care of this recursively by myself as well?