Geek Answers Handbook

Distant transition to ntdll.dll internal ZwCreateUserProcess

I am trying to understand how the Windows API creates processes, so I can create a program to determine where the exes are invalid. I have a program that calls kernel32.CreateProcessA . Following in OllyDbg, it calls kernel32.CreateProcessInternalA , which calls kernel32.CreateProcessInternalW , which calls ntdll.ZwCreateUserProcess . This function:

 mov eax, 0xAA xor ecx, ecx lea edx, dword ptr [esp+4] call dword ptr fs:[0xC0] add esp, 4 retn 0x2C

So, I follow the call to fs:[0xC0] , which contains one command:

 jmp far 0x33:0x74BE271E

But when I find this command, Ollie simply returns to ntdll.ZwCreateUserProcess in add esp, 4 immediately after the call (which is not in 0x74BE271E ). I set a breakpoint at retn 0x2C and I found that a new process was somehow created at runtime add esp, 4 .

Therefore, I assume that in the long jump there is some kind of magic. I tried changing the CS register to 0x33 and EIP to 0x74BE271E instead of actually doing a down jump, but that just gave me an access violation after a few instructions. What's going on here? I need to be able to dive deeper into the abstraction of this ZwCreateUserProcess to find out exactly how Windows creates processes.

+4
source share
3 answers
 jmp far 0x33:0x74BE271E`

This transition is part of the kernel. 0x33 - a special segment selector that points to some x86 element; this leads to a context switch to the kernel.

+5
source

The parts you are missing are part of the kernel. You will want to attach a kernel mode debugger and go to the ZwCreateUserProcess kernel code to find out how this process is created. You should also take a look at Chapter 5, Processes, Topics, and Tasks, for the 5th or 6th edition of Windows Internals. This chapter details the creation process.

+4
source

Actually, this transition is not included in the kernel, but switches to the usbode x64 WoW64 subsystem (Win32 to Win64).

The 33h selector is a special selector that spans a 4 GB memory space but is set to x64 mode. The jump goes to the 64-bit (but still usermode) part of wow64cpu.dll, which converts 32-bit API parameters to 64-bit and calls the API in the 64-bit ntdll.dll file (yes, you have two of them in WoW64 process). This ntdll, in turn, makes a real system call that goes into the kernel.

Here are a few links that describe the mechanism in more detail. You can also find more by looking for the term "heavenly gate."

http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/

http://wasntnate.com/2012/04/heavens-gate-64-bit-code-in-32-bit-file/

+3
source

More articles:


All Articles