Feature Request: Enhanced Disassembly View Esp. For Debugging Without Source Code
trustednstaller opened this issue · 0 comments
I would like to see the disassembly view much more enhanced so that one can debug solely through it i.e., when one doesn't have the source code or doesn't care for it. It should also be modifiable in that a user can annotate it as they're debugging i.e., adding comments to the right of it (; <user_comment>), adding posteroir/anterior comments above and below the disassembly, adding renaming memory locations, etc.
Also, it would be very useful to see symbol information within the disassembly view itself i.e., here's an example using Windbg's data model disassembler where there are symbols associated with the binary:
[0x7ffc86f2c528] : push rbx
[0x7ffc86f2c52a] : sub rsp,90h
[0x7ffc86f2c531] : mov rax,qword ptr [combase!__security_cookie (7ffc87205400)]
[0x7ffc86f2c538] : xor rax,rsp
[0x7ffc86f2c53b] : mov qword ptr [rsp+80h],rax
[0x7ffc86f2c543] : mov rbx,newAceOut (r8)
[0x7ffc86f2c546] : mov dword ptr [sidBufferSize (rsp+20h)],44h
[0x7ffc86f2c54e] : lea r8,[sidBuffer{[0]} (rsp+30h)]
[0x7ffc86f2c553] : xor edx,edx
[0x7ffc86f2c555] : lea r9,[sidBufferSize (rsp+20h)]
Even in cases where there is no symbolic information for the binary itself (completely stripped and we don't have the associated debug file), I would like for raddbg to at least show some symbolic information i.e., calls to particular memory locations should show symbolic information. Here are the same binaries in windbg and raddbg:
00007ff7`351d13a0 4883ec28 sub rsp,28h
00007ff7`351d13a4 e80b060000 call notepad!__security_init_cookie (00007ff7`351d19b4)
00007ff7`351d13a9 4883c428 add rsp,28h
00007ff7`351d13ad e92efeffff jmp notepad!__wmainCRTStartup (00007ff7`351d11e0)
00007FF7351D13A0 sub rsp, 0x28
00007FF7351D13A4 call 0x7ff7351d19b4
00007FF7351D13A9 add rsp, 0x28
00007FF7351D13AD jmp 0x7ff7351d11e0
Calls to any APIs within another module should be seen within the disassembly view:
0x7ffc861e4bb0 call KERNELBASE!BaseSetLastNTError (00007ffc`861e6990)
0x7ffc861e4be3 call ntdll!RtlInitUnicodeStringEx (00007ffc`88a4a820)
0x7ffc861e4bf5 call KERNELBASE!BaseSetLastNTError (00007ffc`861e6990)
0x7ffc861e4c3a call ntdll!RtlDosPathNameToRelativeNtPathName_U_WithStatus (00007ffc`88a4b6c0)
0x7ffc861e4c64 call KERNELBASE!BaseSetLastNTError (00007ffc`861e6990)
0x7ffc861e4d9f call ntdll!NtQueryInformationFile (00007ffc`88acf570)
0x7ffc861e4dd8 call ntdll!RtlAllocateHeap (00007ffc`88a6c610)
0x7ffc861e4e17 call ntdll!NtQueryEaFile (00007ffc`88ad1d00)
0x7ffc861e4e3b call ntdll!RtlFreeHeap (00007ffc`88a6aac0)
0x7ffc861e4f0d call ntdll!RtlReleaseRelativeName (00007ffc`88a5e240)
0x7ffc861e4f2c call ntdll!RtlFreeHeap (00007ffc`88a6aac0)
0x7ffc861e4f3d call KERNELBASE!BaseSetLastNTError (00007ffc`861e6990)
0x7ffc861e5029 call ntdll!SbSelectProcedure (00007ffc`88a5ec50)
0x7ffc861e5049 call ntdll!LdrpDispatchUserCallTarget (00007ffc`88abed30)
0x7ffc861e5099 call ntdll!NtCreateFile (00007ffc`88acfdf0)
0x7ffc861e5108 call ntdll!NtCreateFile (00007ffc`88acfdf0)
0x7ffc861e511a call ntdll!RtlReleaseRelativeName (00007ffc`88a5e240)
0x7ffc861e5139 call ntdll!RtlFreeHeap (00007ffc`88a6aac0)
0x7ffc861e5157 call ntdll!RtlFreeHeap (00007ffc`88a6aac0)
0x7ffc861e5169 call KERNELBASE!BaseSetLastNTError (00007ffc`861e6990)
0x7ffc861e5196 call ntdll!RtlSetLastWin32Error (00007ffc`88a832e0)
0x7ffc861e51bf call ntdll!RtlSetLastWin32Error (00007ffc`88a832e0)
0x7ffc861e51f0 call ntdll!NtSetInformationFile (00007ffc`88acf830)
Similar case with raddbg:
00007FF7351D148C push rbx
00007FF7351D148E sub rsp, 0x20
00007FF7351D1492 mov rbx, rcx
00007FF7351D1495 xor ecx, ecx
00007FF7351D1497 call qword ptr [rip+0xea4b] <===
00007FF7351D149D mov rcx, rbx
00007FF7351D14A0 call qword ptr [rip+0xea32] <===
00007FF7351D14A6 call qword ptr [rip+0xebfc] <===
00007FF7351D14AC mov rcx, rax
00007FF7351D14AF mov edx, 0xc0000409
00007FF7351D14B4 add rsp, 0x20
00007FF7351D14B8 pop rbx
00007FF7351D14B9 jmp qword ptr [rip+0xebe0] <===
raddbg also has the nice hover feature of registers in the disassembly view, it would be nice to add that to memory addresses as well in the disassembly view allowing one to "peek" into the code of a function without having to go there.
It would further be nice, if in the Address column of the Call Stack view, double-clicking the address pulls up the associated disassembly view instead of the source file (which is what it does). Again, for cases where there is no source file.
Furthermore, as a suggestion, I would recommend the Zydis disassembler (excellent C library) over udis as it is far more robust, much more thoroughly tested disassembler for x86.