Running binary compiled with external libraries

[mageyer23]

*Describe the bug It seems that even though the required shared object/library is placed in the correct folders in the rootfs provided, the binary doesn't seem to be able to detect its location and would report that there is no such file or directory when accessing this shared object (like pthread in this case).

Sample Code

ql = Qiling(["arm.out"], "binaries/arm_linux", output="debug")
ql.run()

This is the basic code that I am using to just run the binary and have placed the .so files in the right directories based on the debug output when it is searching for the file. The binary that I am using is a ARM ELF

Expected behavior The binary should be able to access the library required and be able to execute the file.

Screenshots

[xwings]

run a file command on your libpthread.so.0 ?

[mageyer23]

Binary: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, BuildID[sha1]=93525371420688fc565cdaaa9d2de15168c5c879, not stripped

so.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, BuildID[sha1]=30ae17cd11193b5ed3758987339ed587352e1b79, for GNU/Linux 2.6.16, stripped

I have tried using what the linux system does which is to symbolic link libpthread.so.0 to the actual library libpthread-2.13.so as well as rename the actual library directly to libpthread.so.0 in the rootfs provided,

[xwings]

Do have your /binaries/arm_linux/lib/ld-linux.so.3 too ? I am not too sure what happen, in our repo we have multithread binary that works with libpthread.

[mageyer23]

Ah, I got it now. I was using the repo's libraries which are newer than the ones needed by the binary and now it works with the correct libraries. Sorry for the trouble!

One more thing, for this error:

I would basically have to trace the binary to see whether some syscall or required file is missing correct? Since it basically crashes at the start of the binary.

[xwings]

This could be millions of reason, checkout https://docs.qiling.io/en/latest/faq/

You can always turn on the disasm mode and check that is the actual cause

[mageyer23]

Hi,

Can I ask about the difference between how qiling interprets libraries against the way qemu user mode does it?

When I run qemu-arm -L [path to libraries] [binary] , the binary seems to be able to run perfectly fine with the expected output but qiling seems to throw errors with regards to certain library dependencies not being met despite providing the same rootfs and binary.

[xwings]

Do you have more specific test case ?

[learn-more]

What I noticed on windows is that only the imports of the main binary are processed, any additional libraries loaded do not get their imports processed.

[xwings]

Issue close, due to author got no respose after a months.