Dave Maynor’s Vista ASLR tricks post got me thinking. And today, after some inspiring presentations at TechEd last week, I took the time to do some testing. Set the appropriate bit (0x4000) in the DLL Characteristics field of the PE header, and you turn on ASLR for your program of choice. So clearing the bit will disable ASLR, but will Windows File Protection prevent you from changing the program? I didn’t think it would, because you’re only touching the PE Header, which is not protected by the Authenticode signature.
Turns out it does work: you can disable ASLR for a given program, like Internet Explorer. And WFP will not restore the file. But for another reason than I thought: with Vista, WFP is actually called Windows Resource Protection. And it works differently: files are protected by Security Descriptors, and are not replaced automatically when deleted or modified. So the neat trick of deleting a system-file in Windows XP (like utilman.exe) only to see it reappear a couple of seconds later, doesn’t work anymore with Vista. Change the Security Descriptor of the file in Vista (taking ownership and giving you delete rights), delete the file, and it’s gone. No more resurrection.
If you want to play with the ASLR toggle, you can use stud_pe to edit the PE Header and Process Explorer to test it.
So why would you disable ASLR? I don’t know, I just think it’s a funny trick 😉 . But maybe you got an idea? Let me know, post a comment.
Didier Stevens 
Hi didier.
Yoy have an excelent blog!
Any executable can decide to participate in ASLR by setting bit 0x40 in the field DLL CHARACTERISTICS. You have a document write by the symantec team submitted in the blackhat 2007.
The thing is that any user with admin privileges, can disable this feature, making it easier an attack code execution for the executable.
Its a funny trick!!
Click to access bh-dc-07-Whitehouse-WP.pdf
Sorry for my English…. Spanglish its better for me…. 🙂
regards
Comment by Juanillo — Sunday 25 November 2007 @ 14:58
>I didn’t think it would, because you’re only touching the PE Header, which is not protected by the Authenticode signature.
That’s the most retarded thing I read in a long time. Of course the signature covers the header, moron. Hey, what do I know, the PE header “only” contains such irrelevant, purely advisory fields as the entry point offset, and it would take all of 10 minutes to check that flipping the DLL characteristics bit does indeed invalidate the signature anyway. BUT WHAT THE BLEEP DO I KNOW, I’m not a card-carrying IT Security Professional !
The sheer stupidity of certain statements just jumps at your face, screaming
Comment by KJK::Hyperion — Monday 26 November 2007 @ 13:38
Is this part of your therapy?
Comment by Didier Stevens — Tuesday 27 November 2007 @ 8:58
I’m sorry, I had a bad day.
Comment by KJK::Hyperion — Thursday 29 November 2007 @ 10:22
Disabling ASLR is good for debugging, let’s say debugging windows DLLs (for ex. cracking).
I would suggest to create a simple DOS program that changes the bit.. let’s say “no_aslr.exe”
Boot from a USB Pen Drive with NTFS4DOS 1.9 Personal (it’s free and allows u read/write NTFS part.)
Use “no_aslr.exe file.dll” with any file.
Modifying files while in DOS do not affect the security permissions.
Comment by Luciano Aibar — Monday 21 April 2008 @ 7:23
I really enjoy your posts – very useful information. I need to turn off ASLR for a .NET executable on a Windows 7 VM. Resetting the bit in the PE header with stud_pe, DYNAMICBASE linker option,,MoveImages registry setting nor disabling system wide with EMET will stop my simple test exe from loading at a new address each time. How can I prevent this so I can debug at a known address in PIN?
Comment by Diane Stephens — Tuesday 21 April 2020 @ 14:29