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

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" <alanadams@nospam.nospam> wrote in message
news:50e3l21cd8n04fme47f7h8ol4t2kbetovq@4ax.com...

> "Arpi Jakab" <arpi_AT_replaysolutions_DOT_COM> wrote:
>

>> 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...26/608315.aspx
> http://blogs.msdn.com/michael_howard...mentation.aspx
>
> Alan Adams

"Arpi Jakab" <arpi_AT_replaysolutions_DOT_COM> wrote:

> 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