Debugging will not work on windows when using r2pipe over http

[scrapbird]

If I try to debug with the python r2pipe API using http as transport I get the following errors:

C:\Users\IEUser\Desktop\radare2-w32-1.3.0>radare2.exe -c "e http.sandbox = false; e http.bind = 0.0.0.0" -qc=h -d C:\Users\IEUser\Desktop\49a48d4ff1b7973e55d5838f20107620ed808851231256bb94c85f6c80b8ebfc.bin Spawned new process with pid 968, tid = 3448 = attach 968 3448 bin.baddr 0x00400000 Using 0x400000 Assuming filepath C:\Users\IEUser\Desktop\49a48d4ff1b7973e55d5838f20107620ed808851231256bb94c85f6c80b8ebfc.bin asm.bits 32 Starting http server... open http://127.0.0.1:9090/ r2 -C http://127.0.0.1:9090/cmd/ [HTTP] fd384 /cmd/e%20scr.html%20%3D%20false [HTTP] fd384 /cmd/doo Spawned new process with pid 548, tid = 2884 File dbg://C:\Users\IEUser\Desktop\49a48d4ff1b7973e55d5838f20107620ed808851231256bb94c85f6c80b8ebfc.bin reopened in read-write mode Assuming filepath C:\Users\IEUser\Desktop\49a48d4ff1b7973e55d5838f20107620ed808851231256bb94c85f6c80b8ebfc.bin = attach 548 2884 [HTTP] fd384 /cmd/dc (548) loading library at 76FF0000 (C:\Windows\System32\ntdll.dll) ntdll.dll (548) loading library at 766F0000 (C:\Windows\System32\kernel32.dll) kernel32.dll (548) loading library at 74F20000 (C:\Windows\System32\KernelBase.dll) KernelBase.dll (548) loading library at 753A0000 (C:\Windows\System32\user32.dll) user32.dll (548) loading library at 76FA0000 (C:\Windows\System32\gdi32.dll) gdi32.dll (548) loading library at 75340000 (C:\Windows\System32\lpk.dll) lpk.dll (548) loading library at 77160000 (C:\Windows\System32\usp10.dll) usp10.dll (548) loading library at 76D20000 (C:\Windows\System32\msvcrt.dll) msvcrt.dll (548) loading library at 76510000 (C:\Windows\System32\advapi32.dll) advapi32.dll (548) loading library at 76DD0000 (C:\Windows\System32\sechost.dll) sechost.dll (548) loading library at 75290000 (C:\Windows\System32\rpcrt4.dll) rpcrt4.dll (548) loading library at 75470000 (C:\Windows\System32\shell32.dll) shell32.dll (548) loading library at 76F40000 (C:\Windows\System32\shlwapi.dll) shlwapi.dll (548) loading library at 767D0000 (C:\Windows\System32\ole32.dll) ole32.dll (548) loading library at 76640000 (C:\Windows\System32\oleaut32.dll) oleaut32.dll (548) loading library at 713A0000 (C:\Windows\System32\winhttp.dll) winhttp.dll (548) loading library at 71350000 (C:\Windows\System32\webio.dll) webio.dll (548) loading library at 6AD90000 (C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18837_none_ec86b8d6858ec0bc\comctl32.dll) comctl32.dll (548) loading library at 73610000 (C:\Windows\System32\msimg32.dll) msimg32.dll (548) loading library at 743A0000 (C:\Windows\System32\version.dll) version.dll (548) loading library at 72EF0000 (C:\Windows\System32\IPHLPAPI.DLL) IPHLPAPI.DLL (548) loading library at 76930000 (C:\Windows\System32\nsi.dll) nsi.dll (548) loading library at 72ED0000 (C:\Windows\System32\winnsi.dll) winnsi.dll (548) loading library at 71AF0000 (C:\Windows\System32\oledlg.dll) oledlg.dll (548) loading library at 735C0000 (C:\Windows\System32\wtsapi32.dll) wtsapi32.dll (548) loading library at 76A10000 (C:\Windows\System32\psapi.dll) psapi.dll (548) loading library at 74F70000 (C:\Windows\System32\userenv.dll) userenv.dll (548) loading library at 74F00000 (C:\Windows\System32\profapi.dll) profapi.dll [HTTP] fd384 /cmd/aaa TODO: esil-vm not initialized Cannot determine xref search boundaries Could not find an active thread for pid 12081136 = attach 12081136 12081136 Cannot attach to 12081136 Cannot attach to 12081136 Cannot attach to 12081136 [HTTP] fd384/cmd/%3F%20%60s%20%40%20%5Bsym.imp.KERNEL32.dll_VirtualAlloc%5D%60%7E%5B0%5D [HTTP] fd384 /cmd/drj GetThreadContext: 6 [HTTP] fd384 /cmd/db%20%5Bsym.imp.KERNEL32.dll_VirtualAlloc%5D Cannot place a breakpoint on 0xffffffff unmapped memory. See dbg.bpinmaps [HTTP] fd384 /cmd/db [HTTP] fd384 /cmd/drj GetThreadContext: 6 [HTTP] fd384 /cmd/px%20%40%200x0

If I execute the exact same commands inside the virtual machine it works, over r2pipe it won't.

I had to turn off the scr.html option as everything returned over http was in html and breaking any json parsing in r2.cmdj and messing with the output of r2.cmd.

Is there something I'm missing? Why will debugging not work over http? I've tried many different combinations of command args, starting the server by passing -qc=H and -qc=h, starting the server once r2 is loaded and get the same results.

I also tried with rap but that wasn't working either. Is there any way to remotely control r2 that works? I want to automatically unpack malware samples in a virtual machine but hate using windows so would rather run an r2pipe script in my linux environment.

Cheers

[Maijin]

Old r2, use the latest version to make tests -> http://bin.rada.re/radare2-w32-1.4.0-git.zip

[scrapbird]

@Maijin I'm using version 1.3.0, I'll update when I get home and let you know if the same thing is happening. Was a fix for this included in the recent release?

[scrapbird]

@Maijin I retried with the version you linked, same results. Works fine if I'm typing the commands myself, with r2pipe over http it fails with the above.

[radare]

Cc @skuater

On 29 Mar 2017, at 11:48, Brenton Morris notifications@github.com wrote:

@Maijin I retried with the version you linked, same results. Works fine if I'm typing the commands myself, with r2pipe over http it fails with the above.

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

[sanguinawer]

The problem become with command "doo", when file is reopened the handle become lost. Then the command "aaa" made a analisys using esil and change the debug backend to esil, to do their stuff, then switch to native debugger, and made a "dpa", and here come the problem, how we come from a "doo" and this command loose the handle into core->file->desc->fd, and dpa made the attach using it we get the error to attach.

All the problem come from when debug process is spawned and IOW32dbg is created, at creation the fd param always is -1.

PR #7247 must solved the problem.

[sanguinawer]

@radare plz, check all is ok and close issue

[scrapbird]

Hey @skuater thanks for looking into this for me. I literally just got to work but can check it for you tonight and let you know.