Closed Xoffio closed 1 year ago
Hi, can you please state precisely the missing feature that you want? Is it the ability to break on module load (like windbg's sxe ld:MyModule
)? Or is it the ability to break on a given address, without navigating to it?
Also in WinDBG I think you can combine breaking on module load and then setting a breakpoint on a given symbol with the breakpoint unresolved bu
command. Like bu MyModule!MyFunction
.
Hi @lwerdna. Binja debugger is missing the ability to debug modules that are going to be loaded into memory after the execution of a main program. For example, a DLL
What I showed previously is me trying to find a solution to the problem. I thought about breaking on module load with sxe ld:MyModule
so I can get the base address of the module, and then mapped to the static base address in Binja. bu
sounds like it can do similar but I don't know how to implemented on dbgeng.h
If I want to debug a library or a plugin on macOS I can use Hopper which gives you the chance to set the path of the main program that will load the plugin into memory. Then they manage to map the addresses once is loaded and I can debug the plugin. I don't know how they made it happen but it works very well.
If Binja is able to do this with its debugger it would be awesome. I have been doing some research about it and I think we can make it work. Keep in mind I am doing the testing on Win but the goal is to make it work on all architectures.
First we have to update the UI to let the user set the path of the executable (I had to go to the code a do it manually to test it out)
I had taken a couple of days to learn how to use Windbg and I find out that we can do this:
Break once the module loads into memory
Get the address of the module
Now I have:
0x901f0000
0x180000000
0x1819165cf
With this a can map/translate the breakpoints on Binja to the addresses of the loaded module into memory.