08 Jun

What’s wrong with this file – ASLR is tricky!

I love magic tricks. My absolute favorites are "there's nothing up my sleeve" kind of tricks. You can look at the equipment, you can examine magicians outfit, everything seems fine - yet the rabbit magically appears and disappears.

Here's a similar reversing challenge for you: https://www.mediafire.com/?38evlc6gmyieskn

This EXE file contains relocations. It has all the necessary necessary flags in PE header. And it gets ASLR support in Windows 10, as you can see in picture:
win10_has_aslr
But on Windows 7/8.1 this poor executable will be always loaded at it's preferred imagebase 0x400000, and doesn't get ASLR support:
win7_no_aslr
Can you figure out what's so special about it? smile

I will provide the correct answer in one week. Or you can provide your opinions in comments. Extra respect awarded for detailed answers and explaining how you figured that out. Extra extra respect if you knew the answer even before looking at the executable. smile

6 thoughts on “What’s wrong with this file – ASLR is tricky!

  1. Nice!

    I admit I still haven't found the reason (shame on me!) ... but that's something related to relocations. If I strip them, the executable changes its image base.

    When I'll have some more time ... I'll analyze better :)

    Regards,
    Tony

  2. hmmm, if I "add" the ABSOLUTE item for the relocations (i.e. read: increase from 12h -> 14h the size of block and relocation directory size) it doesn't allocate at the default address ... is it the right road?

    If it's the right road ... Now, I'll need to understand why is needed/important? :P

  3. First (and only) IMAGE_BASE_RELOCATION has wrong size set, it should be size of the relocation items (+ terminating 0x0000 WORD) + sizeof(IMAGE_BASE_RELOCATION), in your exe it's set to 12h but it should be set to 14h. Also you need to update this size in directories for the relocation (IMAGE_DIRECTORY_ENTRY_BASERELOC).

  4. Thank you kao!
    The quote from specification strictly doesn't say it should *end* on a 32-bit boundary however ... but maybe that's what they (also) mean to say ;)

    Best Regards,
    Tony

Leave a Reply

Your email address will not be published.