Rebasing and debugging

Question

So usually when I debug with IDA I don't come across any issues; however, with this one particular process (which is 9.9 MB in size before modules) IDA insists it rebase every single time it starts the process, which freezes IDA and forces me to wait a good 20-30 minutes before it actually starts.

Why does it do this, and can I somehow disable this? I'm new-ish to advanced debugging such as this so rebasing only makes a little sense to me.

Berwick

could you provide a bit more context?, like what operating system, maybe a link to the executable you are trying to debug? – Kristykristyn

Answer 1

In case anyone else finds this page like I did, this can also be caused if the DLL's preferred entry point is already in use it must rebase it before it can continue.

To correct this you can use the ReBase.exe tool that comes with the windows SDK (or visual studio)

ReBase.Exe -b 7600000 myBadBasedDll.dll so that will reset the base of the dll to 0x7600000. You then must do the rebase in IDA one last time to make your idb in sync (or make a new idb after you rebase)

Edit->Segments->Rebase Program...

In the new menu check the boxes for Fix up Program and Rebase the whole image and it should be good to go.

Bergeron

This is more relevant. Marking as answer. – Berwick

@Remko When working with DLLs you are mapping the DLL's address space in to your EXE's address space. If you are loading multiple DLLs two DLLs could have the same "Preferred address". When that happens the 2nd DLL to load gets a random available address. If that 2nd DLL is the one you are decompileing IDA will need to move it's base address for your decompiled code every time it runs. – Bergeron

Hey, so how would one find out whether a dll has a conflicting entry point or not? – Vivavivace

in my case I'm trying to debug executable, not DLL.. since executable offset is always zero(?), IDA shouldn't rebase anything, but rebase still happens – Crescantia

@Crescantia - thanks to ASLR, executables are loaded into random places within their own address space. Prior to that, it was a standard 0x400000. – Musketry

Answer 2

This question was answered by Will Donohoe on 31-05-2013. The website at the time of access is https://will.io/blog/2013/05/31/disable-aslr/

As explained on the site, the problem arose (at least in my case) as a result of Address Space Layout Randomization (ASLR). ASLR is enabled when the DllCharacteristics field of the PE Optional Header contains the mask IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE which has a value of 0x0040.

In my case the DllCharacteristics field was 0x8160 so clearly the 0x0040 mask was present.

The recurrent rebasing problem was corrected thus by removing the 0x0040 mask. Setting the DllCharacteristics field to 0x8120 or 0x8100 did the trick for me.

NB: The DllCharacteristics field can be located at an offset of 0x5E from the beginning of the PE Signature Offset when using a Hex Editor.

Wilson