qiling icon indicating copy to clipboard operation
qiling copied to clipboard

Can't use gdb to debug musl loader

Open ciapatakoza opened this issue 4 years ago • 3 comments

Hi, I am in progress of porting qiling for platform that use musl libc on ARM. I managed to run pure C binary, however when i tried to run C++ application the qiling crashed on find_sym2() function in musl while loading "libc++.so". The crash occurred in musl loader before even entering the entry-point in the main binary. So i decided to use gdb in qiling to stop application in loader before crash and record execution flow (to be able to restore application state). I managed to set the break point in the loader and Unicorn has actually stopped binary in the loader, however the gdb client received PC register set to main binary entry-point instead of the actual address from the unicron, therefore further debugging was not possible (gdb did not allow to set PC value to the correct one).

So how i can force qiling to send proper registers to gdb client in order to debug musl loader?

ciapatakoza avatar Mar 23 '21 07:03 ciapatakoza

Hi! Thanks for your interest. Musl implementation is largely different from that of glibc, which qiling assumes in many places. Could you provide your test binary or a robust way to reproduce the problem?

wtdcode avatar Mar 23 '21 13:03 wtdcode

Unfortunately I am not able to share the binary. However, the the described issue about gdb should be generic problem for all ELF binaries, as in the code i have seen that Qiling use the main binary entry point as address for the break point. However i would like set the break point on the loader and debug loader. So just take any ELF file (could be x86 Linux), set the break point on the loader and connect using gdb client. Then you will see that PC register points to the main binary entry point instead of the loader.

Musl implementation is largely different from that of glibc, which qiling assumes in many place

Could you provide some examples on this (what kind of assumptions and where to find them in the code)? This will really help me to find the problem and will help others in the future to add support for other loaders.

ciapatakoza avatar Mar 23 '21 13:03 ciapatakoza

Unfortunately I am not able to share the binary. However, the the described issue about gdb should be generic problem for all ELF binaries, as in the code i have seen that Qiling use the main binary entry point as address for the break point. However i would like set the break point on the loader and debug loader. So just take any ELF file (could be x86 Linux), set the break point on the loader and connect using gdb client. Then you will see that PC register points to the main binary entry point instead of the loader.

Could you provide the output log? You could send it to https://t.me/lazymio if convenient.

Could you provide some examples on this (what kind of assumptions and where to find them in the code)? This will really help me to find the problem and will help others in the future to add support for other loaders.

Mostly in qiling/loader/elf.py.

wtdcode avatar Mar 23 '21 13:03 wtdcode

Will you be able to try the latest version of Qiling and see if you still face same issue. There is lots of rework since 2021. Feel free to open a new issue if you have any similar problem.

xwings avatar Oct 06 '22 03:10 xwings