system dlls are not loaded at preferred image base in RC2 (5744)

[Arpi Jakab]

Hi,

The preferred loading address for ntdll.dll v6.0.5744.16384 is 0x77EE0000,
yet the loader rebases the dll to 0x77AE0000. Since ntdll is the first to
load, it is certainly not colliding with other system dlls that would cause
the rebase. Not sure about RC1, but this certainly worked in XP. I noticed
that kernel32.dll is also rebased. This seems like a general problem with
the loader.

- Arpi

 

[Alan Adams]

The preferred loading address for ntdll.dll v6.0.5744.16384 is 0x77EE0000,
yet the loader rebases the dll to 0x77AE0000. Since ntdll is the first to
load, it is certainly not colliding with other system dlls that would cause
the rebase. Not sure about RC1, but this certainly worked in XP. I noticed
that kernel32.dll is also rebased. This seems like a general problem with
the loader.

Also known as the feature Address Space Layout Randomization (ASLR).
http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx
http://blogs.msdn.com/michael_howar...Windows-Vista_1920_s-ASLR-Implementation.aspx

Alan Adams

 

[Arpi Jakab]

Thanks that helps. The benefits of ASLR are clear for published
applications, although the non-determinism of dll base addresses does pose
some cross-box or cross-reboot debugging difficulties. Is there a way to
disable ASLR or just the rebasing of system dlls in RC2?

- Arpi

 

[Alan Adams]

Thanks that helps. The benefits of ASLR are clear for published
applications, although the non-determinism of dll base addresses does pose
some cross-box or cross-reboot debugging difficulties. Is there a way to
disable ASLR or just the rebasing of system dlls in RC2?

I don't know of, but have never looked for, such control.

Seems a little reaching though to try and call it a "debugging
difficulty". I'm assuming you're saying that you can't look at where,
for example, ntdll!ZwCreateFile is on one process and assume its still
at that address the next time the process loads and/or on another
machine.

While true, you can no longer assume that, its not that the debuggers
haven't long provided us the means with which to easily deal with
that. You would debug no differently that if you were chasing a DLL
that constantly collides; setting breakpoints by symbol offset rather
than address, etc.

The need for ASLR in a published application is actually the more
dubious proposition for me. Non-predictability of Windows system APIs
is actually the stronger suit of ASLR on Windows, from my perspective
anyway.

Alan Adams