Inconsistency/bug with GetProcAddress
felix.nawothnig at t-online.de
Sun Aug 7 05:44:16 CDT 2005
Mike McCormack wrote:
>> Yes it is. NTDLL and KERNEL32 are both mapped to always the same
>> address on >=NT4 (in NT3 only NTDLL was at a fixed address however).
> KERNEL32 and NTDLL are special cases because they are loaded first when
> the address space is empty, and since the NT kernel has no address space
> randomization they will consistently end up at the same address.
> As far as I know, there's no *garantee* of that, it just happens to be
> that way. If you know otherwise, please point me to the relevant
> documentation. :)
> When creating a process, the loader on Win 2000, Win XP and Win 2003
> checks if kernel32.dll and user32.dll (their names are hardcoded into
> the loader) are mapped at their preferred bases; if not, a hard error
> is raised. In WinNT 4 ole32.dll was also checked. In WinNT 3.51 and
> lower such checks were not present, so kernel32.dll and user32.dll
> could be anywhere. Anyway, the only module that is always at its base
> is ntdll.dll. The loader doesn't check it, but if ntdll.dll is not at
> its base, the process just can't be created.
It's a common technique to rely on the fact that exports from kernel32
reside at the same address to use CreateRemoteThread calling LoadLibrary
for remote code injection (this is not what Vitaliy's App is doing here
but the assertions are the same).
More information about the wine-devel