Qiling/gdb remote debugging not working

[redmed666]

Work environment

Questions	Answers
OS/arch/bits (mandatory)	Kali x64 64
File format of the file you reverse (mandatory)	PE
Architecture/bits of the file (mandatory)	x86/32
r2 -v full output, not truncated (mandatory)	radare2 4.5.0-git 24691 @ linux-x86-64 git.4.4.0-138-g64e6df500 commit: 64e6df5004b2718526761503a48437e82be3471e build: 2020-05-06__08:57:06

Expected behavior

Remote debug working.

Actual behavior

radare2 outputs this:

= attach 0 0
ptrace (PT_ATTACH): No such process
= attach 0 0
ptrace (PT_ATTACH): No such process
= attach 0 0
ptrace (PT_ATTACH): No such process
ptrace (PT_ATTACH): No such process
= attach 0 0
ptrace (PT_ATTACH): No such process

It is also breaking at address 0x0 instead of the entry point of the executable. Moreover, no matter if I continue or step, it doesn't change anything.

Steps to reproduce the behavior

Step 1: ./qltool run -f ./your.exe --rootfs ./rootfs/ --gdb 0.0.0.0:9999 Step 2: r2 gdb://127.0.0.1:9999

[XVilka]

Qiling is based on the unicorn, right? Which is based on the very old qemu, whose gdbserver has changed protocol a bit since. Just a blind guess though.

[redmed666]

Hi,

Apparently, Qiling is implementing itself its gdbserver (in qiling/debugger/gdbserver/gdbserver.py). I will try to see the differences between their implementation and what radare2 expects.

[radare]

You missed the -d flag in r2

R2 wprks well with qilin

On 10 May 2020, at 10:13, redmed666 notifications@github.com wrote:

 Work environment

Questions Answers OS/arch/bits (mandatory) Kali x64 64 File format of the file you reverse (mandatory) PE Architecture/bits of the file (mandatory) x86/32 r2 -v full output, not truncated (mandatory) radare2 4.5.0-git 24691 @ linux-x86-64 git.4.4.0-138-g64e6df500 commit: 64e6df5 build: 2020-05-06__08:57:06 Expected behavior

Remote debug working.

Actual behavior

radare2 outputs this:

= attach 0 0 ptrace (PT_ATTACH): No such process = attach 0 0 ptrace (PT_ATTACH): No such process = attach 0 0 ptrace (PT_ATTACH): No such process ptrace (PT_ATTACH): No such process = attach 0 0 ptrace (PT_ATTACH): No such process It is also breaking at address 0x0 instead of the entry point of the executable. Moreover, no matter if I continue or step, it doesn't change anything.

Steps to reproduce the behavior

Step 1: ./qltool run -f ./your.exe --rootfs ./rootfs/ --gdb 0.0.0.0:9999 Step 2: r2 gdb://127.0.0.1:9999

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[redmed666]

Indeed, the -d flag was missing. But I have another issue. It seems that radare2 doesn't handle properly the breakpoint address. It doesn't add the PE base address to the entrypoint address. So it connects to qiling's gdbserver, it receives correctly the address of entrypoint but doesn't break at it and begins at 0x00000 instead of 0x

[radare]

use -B or -m to map the bin in the same baddr of the remote site to slide those offsets

On 11 May 2020, at 12:27, redmed666 notifications@github.com wrote:

Indeed, the -d flag was missing. But I have another issue. It seems that radare2 doesn't handle properly the breakpoint address properly. It doesn't add the PE base address to the entrypoint address. So it connects to qiling's gdbserver, it receives correctly the address of entrypoint but doesn't break at it and begins at 0x00000 instead of 0x

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radareorg/radare2/issues/16797#issuecomment-626617216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG75FSH62BSXW3LKYWMQKDRQ7HKRANCNFSM4M5EQTLQ.

[redmed666]

Ok, found a way to make it work.

1) r2 - 2) doof gdb://127.0.0.1:9999/0 3) enjoy

The file is mapped and the commands are working as expected so that's nice. But that seems pretty quirky that r2 -d gdb://127.0.0.1:9999/0 doesn't work, no? Or at least maybe that could be documented somewhere?

Also, something that doesn't work is the breakpoints. With gdb, you can see in the info print that Qiling could add a breakpoint at the address specified but it doesn't add it when r2 sets one (and so continue until the end).

Thanks for your help!

[radare]

Yeah the -d way should work

On 11 May 2020, at 19:38, redmed666 notifications@github.com wrote:

 Ok, found a way to make it work.

r2 - doof gdb://127.0.0.1:9999/0 enjoy The file is mapped and the commands are working as expected so that's nice. But that seems pretty quirky that r2 -d gdb://127.0.0.1:9999/0 doesn't work, no? Or at least maybe that could be documented somewhere?

Thanks for your help!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.