A forum for reverse engineering, OS internals and malware analysis 

 #25997  by Microwave89
 Wed Jun 03, 2015 1:15 pm
Hi Kernelmode.info!

(As all of the following addresses are given by ASLR, their absolute values mean nothing)

I have a very short question:
When one retrieves the virtual size of .text section of ntdll.dll (from section header) the section last byte's offset can be calculated by:
PAGE_ROUND_UP(pNtdllBase + text RVA + text VirtualSize ) - 1.
For Windows 7 SP1 x64 ntdll.dll I then get an offset of 0x775f2000-1 while having the AllocationBase at 0x774f0000.

However, if process hacker 2.35 performs a memory query, it gives me an executable size of 0x102000 derived from the end of header section at 0x774f1000 and start of next section at 0x775f3000.
If I calculate the next sections offset by doing:
Code: Select all
PNT_DELAY_EXECUTION fpDummyNtdllFunc = (PNT_DELAY_EXECUTION)NtDelayExecution;

status = NtQueryVirtualMemory(INVALID_HANDLE_VALUE, (PVOID)fpDummyNtdllFunc, MemoryBasicInformation, &memInfo, sizeof(memInfo), &u64RetLength);
if (status){
	//DebugPrintA("0x%lX Memory Query Failed!", status);
	DebugPrint2A("0x%lX Memory Query Failed!", status);
	return FALSE;
}
nextSection = (ULONGLONG)memInfo.BaseAddress + memInfo.RegionSize
"nextSection" equals 0x775f3000, which is in fact correct.

Hence, the memory manager somehow added one more page when mapping ntdll.dll.
Where does this come from? Where does this page come from?
All I found out so far, is that in the very last page exist functions like RtlAllocateMemoryZone I never heard about. A short research didn't show useful results except that they are used for debugging/exception purposes?!

Can you point me in a good direction to understand the cause of this issue?

Thanks in advance :)

Best Regards

Microwave89

EDIT: I think I found the reason by myself. There exists another section which is readable-executable in memory, too.
The section is named "RT" and it is obviously merged with the .text section as both have the same attributes.