I unpacked a UPX packed PE binary. Both the packed and unpacked binary have fixed image base of 0x400000 (Checked by various PE tools).

However, every time I run the program in OllyDbg, the image would located an a different base address. It would change the image base when I reopen the binary and start run it, and would not change the image base when I click the restart icon in OllyDbg. I read at this post saying that win32 exe never use ASLR. Is this true? I have win7 pro and OllyDbg1.10.

Here is my real question. The unpacked executable have some address reference invalid. They are all using the standard win32 base 0x400000.

For example, I have the following instructions in my unpacked program, the reference to the 407018 is invalid.

  • How could I fix this address reference?
  • How to change all the address references in the format of 0x40xxxx to 0x1150000 in code section? Is there a tool to do this?

01153F2B  |. A1 18704000    MOV EAX,DWORD PTR DS:[407018]
01153F30  |. 8365 F8 00     AND DWORD PTR SS:[EBP-8],0
01153F34  |. 8365 FC 00     AND DWORD PTR SS:[EBP-4],0
01153F38  |. 53             PUSH EBX
01153F39  |. 57             PUSH EDI
01153F46  |. 74 0D          JE SHORT CrackME.01153F55
  • The base randomization happens because of ASLR. You can disable ASLR for that specific binary (and thus make the references valid) using this tool: setdllcharacteristics -d your_file.exe
    – rev
    Sep 2, 2015 at 17:32
  • 2
    Hi, @AcidShout Thank you pointing out this. There is one bit in the header that can disable the ASLR in win32 binary. I have done this in CFF explorer. My problem has been solved!!!
    – Harry
    Sep 3, 2015 at 14:35
  • 2
    so you used CFF explorer? you can post an answer to your own question, which is explicitly encouraged
    – rev
    Sep 3, 2015 at 14:40

1 Answer 1


Why is this happening in the first place?

Changing image bases to a different random address each time an image is loaded is called Address Space Layout Randomization (In short, ASLR). Most modern OSes employ ASLR on user mode processes (Some OSes do that for kernel mode code as well, at least partially) where this is possible.

The major advantage of ASLR is that it increases the difficulty if exploiting memory corruption based exploits (often requires a information leak type of bug to mitigate), and therefore encouraged by the security community.

In order to be ASLRed, an image must be relocatable. That is, it is required to properly function regardless of where in memory it is located. This tends to be complicated because certain instructions (in certain architecture) are position based. For example, on the x86 architecture the CALL instructions can be either relative or absolute, making it impossible to change the addresses at which the image is loaded without risking crashes.

An image can either make sure it only uses relative instructions (which might be difficult at times) or provide a relation table as part of the image file. A relation table explicitly lists all absolute addresses used in the image for the loader to fix in case the image is relocated.

How to avoid ASLR?

Obviously, disabling ASLR is not encouraged because of the protection it provides. On 64bit windows user mode ASLR is mandatory, so you simply cannot disable it. However, on 32bit windows, you're allowed to and can disable it by disabling the relevant PE flag, by un-checking the marked checkbox in the following image:

disabling ASLR

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.