Vector35
Debugger takes an extraordinarily long time to become usable on large binaries
I'm debugging a very large binary (~58 MB). Just attaching the debugger and copying the view is a 5-10 minutes process. (Can provide the binary if necessary, but I don't think it has much to do with the particulars of it - just the size.)
Is there any way that this could be sped up? I would love to be able to do my debugging in BN since I do all my analysis there, but the load time is just bordering on unusable compared to e.g. IDA.
There is a current workaround and a future solution to this. When you launch the target, set Input File to an empty string, so that the debugger will NOT try to rebase your existing database and adding it into the debugger binary view. That should make the launch process almost instant. However, the drawback is you no longer have your analysis info in the debugger binary view, which means you can still debug it just fine, but you do not have function/variable names in it. You may wish to split the view and view the PE view and debugger view side by side so you have an idea of what is going on.
Issue https://github.com/Vector35/debugger/issues/470 will make the situation less annoying. You will only need to wait for a while on the first launch. In subsequent launches, the debugger binary view is reused so it should also be very fast.
Out of curiosity, what is it that takes so long when copying the binary view to the debugger view? FWIW, in my case, the executable has ASLR disabled so the load base will always equal the image base.
Could you try rebasing your binary and see how long it takes? The copying process is essentially the same as a rebasing, though with the same base.
Now that you said the ASLR is disabled, I think it is taking a bit too long. Could you please via with the binary via slack or email?
The binary is available in this GitHub release: https://github.com/alexrp/tera-re/releases/r387486 (TERA.unpacked.exe)
By the way, I'm just now realizing that my wording was misleading: The copying takes a couple of minutes, but it's the full reanalysis that happens in the debugger view afterwards that really takes a long time.
By the way, I'm just now realizing that my wording was misleading: The copying takes a couple of minutes, but it's the full reanalysis that happens in the debugger view afterwards that really takes a long time.
Thanks for the explanation! I will have a look later and get back to you. I am a bit overloaded at the moment.
This should have been fixed since we are no longer creating a debugger binary view during launch. The original view (e.g., PE view), is used for debugging and the extra regions in the memory space is added as overlays on top of it. If the input binary has ASLR on, then there will be one rebase operation that could take some time; if the binary has ASLR turned off, it should be very fast