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

  • Thread starter Thread starter Arpi Jakab
  • Start date Start date
A

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
 
Arpi Jakab said:
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.
Click to expand...

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
 
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
 
Arpi Jakab said:
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?
Click to expand...

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
 
Back
Top