

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.Īn 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. This tends to be complicated because certain instructions (in certain architecture) are position based. That is, it is required to properly function regardless of where in memory it is located. In order to be ASLRed, an image must be relocatable. 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.

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. Why is this happening in the first place?Ĭhanging image bases to a different random address each time an image is loaded is called Address Space Layout Randomization (In short, ASLR).


I read at this post saying that win32 exe never use ASLR. 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. However, every time I run the program in OllyDbg, the image would located an a different base address. Both the packed and unpacked binary have fixed image base of 0x400000 (Checked by various PE tools).
