rizinorg / cutter

Free and Open Source Reverse Engineering Platform powered by rizin
https://cutter.re
GNU General Public License v3.0
15.93k stars 1.15k forks source link

WinDbg remote debugging interface placement #1886

Open yossizap opened 5 years ago

yossizap commented 5 years ago

Is your feature request related to a problem? Please describe.

In 9ae170b I added WinDbg to the remote debug dialog box thinking that it will support all windbg debug modes over pipes with some fixes. After closer inspection, it turned out that R2's WinDbg implementation only supports kernel debugging and adding regular remote windbg won't be trivial. I'll try working on it but it's in a lower priority.

Since opening this type of remote debugging will just open a completely different binary(windows kernel), I was wondering whether there's a workflow in which people debug window kernel binaries after loading them through ida/r2. Otherwise, I would just move this debug interface to Cutter's launch dialog for people to directly open windbg for kernel debugging.

yossizap commented 5 years ago

I wasn't aware of this at the time of writing, but it turns out that the WinDbg implementation supports listing all of the processes currently running in the debugged kernel with dp and then attaching to one of them with dp=. We could use the launch dialog for direct kernel debugging while "remote connect" will search dpj for our exe's name(fail if's missing) and attach to the specific exe with dp=. A more advanced user could obviously jump between processes but this sort of dictates a more sane workflow that we could also add rebasing to.

XVilka commented 4 years ago

Also will need some changes/improvements after network KD support is merged https://github.com/radareorg/radare2/pull/17340

XVilka commented 4 years ago

With the merge of DbgEng support locally on Windows systems and renaming the URI schemes, please see the updated WinDbg chapter of Radare2 book for the user cases on how to use and how it should look: