ASLR and the new linker

Well, the VS team shipped VS2005 SP1. You'll need the updated linker to support ASLR on Windows Vista. All it does is add a new setting to your PE header.

So grab the update, and link your EXE with the new /dynamicbase option.



Comments (16)

  1. Bovine says:

    Could people using downlevel linkers simply add the appropriate bit to the EXE header if switching linkers is inconvenient?  Perhaps EDITBIN.EXE or a new third-party utility could be used for this?

  2. dispensa says:

    Any idea why the RTM SDK didn’t support this, or perhaps when you expect to see it added? (cf.

  3. Hey Michael,

     Are there any other security features that are new in VS2005 SP1?


    Kyle Randolph

  4. >>Kyle Randolph

    afaik, that’s all; it’s a service pack, not a "feature pack" after all.

  5. Skywing says:

    Bovine: Yes, if they were using link.exe + editbin.exe from VS 2005 SP1 or the WDK.  You need to use that version of the linker in order to have it set the flag.  (Remember that editbin.exe is a thin wrapper that simply launches link.exe with a special parameter that puts it into "editbin" mode.)

  6. dejani says:

    Hi Howard,

    I was bit confused by this blog entry so I run a test of my own to see how’s ASLR related DEP/NX bit. To do the test I wrote a little program:

    int global = 0;

    int __cdecl _tmain(int argc, _TCHAR* argv[])


    int x = 0;

    printf("x:tt0x%xn", &x);

    printf("global:tt0x%xn", &global);

    printf("main:tt0x%xn", _tmain);

    return 0;


    By inspecting addresses displayed on screen I could find out whether Vista does:

    1) Stack address space layout randomization

    2) Data ASLR  

    3) Code ASLR

    First I compiled the code as Win32 application and run it on Vista. The output was always the same.

    Then I compiled it for vista with /dynamicbase linker option and run the image on DEP and non-DEP processor.  Vista randomized all three addresses as expected in both cases. So NX enabled processor  is not prerequisite for ASLR but supplement to improved security.

    There are two things I have noticed:

    1) The message on “Data Execution Prevention” tab on Performance Options dialog for non DEP enabled systems sais: “Your computer’s processor does not support hardware-based DEP. However, Windows can use DEP software to help prevent some types of attacks”.  This requires at least “More details” link to explain what is DEP software, where to find it, how to install it….

    2) If you run small application (such as this one I posted) more than once in row you’ll notice that only stack address of the x variable changes. If you put the binary on network share and run it from there, randomization always happens for all three addresses. Of course, this is also the case with system reboot: first start after each reboot gives different output, but all other subsequent application runs give different result for address of x variable on stack only. This actually means that if I was hacker trying to hack say a small binary service I can be sure that each time I crash the service the next time it comes up global data and code base will be in place as in last run, only stack addresses would change. This gives me more chance to succeed in my attack. I guess this has something to do with prefetcher or some cashing in the system, but I would rather have my application assigned all the addresses randomized each time application starts.

    I hope all this makes sense.


  7. Dejani

    1) ASLR does not require DEP to make ASLR work. ASLR works *better* when DEP is enabled. XPSP2 and later support another form of DEP, named software DEP, which does not require CPU support. This other form of DEP is also called SafeSEH, and it’s also a linker flag (/safeseh)

    2) what you’re seeing is expected. The stack address will juggle around as each thread starts up, but the base image address is fixed until the system is restarted. We "assign" image addresses on reboot only.

  8. Kumar says:

    Just 1 question

     Is ASLR applied for the kernel(NTOSKRNL.EXE) itself.     Is ASLR applied on kernel mode drivers.

    waiting 4 the reply

  9. Kernel mode has always had a form of ASLR.

  10. Thanks, I’ve used link.exe v8.00.50727.762 from Visual Studio 2005 SP1 and changed the PE bit using the command line option that you’ve suggested.

    Diff showed that the only change in the header are “DLL flags”, which became 0×0040.

    Stack now show different base each time I run the executable.

    Code base only changes when I reboot the machine.

    Entry points of Windows DLLs seem not not change at all. For example, GetProcAddress(GetModuleHandle(’kernel32.dll’), ‘ExitProcess’) each time gives the value of 0×7700D85E, regardless the ASLR bit in the PE header.

    Why GetProcAddress always gives the same value, and why the image base only changes after I restart Windows Vista!?

    Is it intended by Microsoft that ASLR doesn’t affect the results of GetProcAddress? E.g. it always returns 0×7700D85E as an address for ExitProcess() API function. Does it mean that I can simply jump to 0×7700D85E to get this API function called, and I will be able to call other functions like CreateFile similarly? What is the point of ASLR then?

  11. Nikolai Soloviov says:

    Hi dejani,

    Please check the phrase "However, Windows can use DEP software to help prevent some types of attacks" that You’ve posted. Wasn’t it really "However, Windows can use software DEP to help prevent some types of attacks"? The order of words is critical here.

  12. [Default] Spotlight on: Windows Vista [Default] Microsoft Across America Launch Event The release of

  13. ss says:

    Randomizing image base will not prevent anything since no one uses the hardcoded API addresses in viruses/trojans/whatever. It is very easy to find the needed APIs dynamicaly.

  14. ss, sure they often find APIs dynamically – by calling LoadLibrary, which is at a random location.

  15. ss says:

    Michael: no, I meant without even using LoadLibrary. You can just find image base of the library e.g. by searching ‘MZ’ in the memory and taking into account that it is always page-aligned, when find the PE header and finally reach the export table.

  16. ss: I think you’re missing the point. You’re talking about finding addresses after you have reliable code execution – which is not what ASLR is about. We’re preventing reliable code execution in the first place!

Skip to main content