Inconsistency/bug with GetProcAddress

[Felix Nawothnig]

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. :)

http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767/ 
says:

 > 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).

Felix