Someone may ask what is the purpose of debugging PE loader, here are a few reasons:
- checking why executable is not loaded properly (imports, TLS, other initialization related issues)
- looking for some hidden features (e.g. LdrpCheckNXCompatibility)
- plain curiosity
Of course debugging ring 3 part of PE/PE+ loader can reveal only part of the truth, for the second part (or rather first part if I want to be strict) there is MiCreateImageFileMap function inside ntoskrnl (source code of this function can be found in Windows Research Kernel: \base\ntos\mm\creasect.c, it is a bit old, but most of the stuff hasn’t changed much). In this short article I’ll cover only x86 and x64 of ring 3 part.
Ring 3 entry point for the new process (and also thread) is located in NTDLL, it is exported as LdrInitializeThunk, more information about this callback can be found at Skywing’s blog: http://www.nynaeve.net/?p=205. Basically above post inspired me to think about some other method to debug process initialization. It was few years ago and I came with a very simple idea (flawed, as it turned out lately when I got back to this project). Initial concept looked like this:
- Create process with dwCreationFlags set to CREATE_SUSPENDED
- Allocate one temporary page in the new process (VirtualAllocEx)
- inject small shellcode which will check PEB.BeingDebugged field in the loop and in case of debugger detection loop will end and int3 will be executed
- Redirect LdrInitializeThunk to the shellcode
- Resume process
- Attach favourite debugger
I was using this scenario and it was sufficient at that time, however it was sometimes failing. Recently I got back to this and finally found the reason. There is a race condition, because during debugger attachment system creates additional thread that should do DbgBreakPoint. So in my case, after resuming application, one of the threads was reaching my shellcode and second one was waiting until I hit ‘step over’ instead of ‘step into’ and in some cases it was taking the initialization process first, leaving me with the already initialized application. Here is new version of the x86 shellcode:
BITS 32 _begin: jmp _skip push 0 push 0 mov eax, 12345678h ; NtTerminateThread call eax _skip: call $+5 pop eax mov word [eax - ($ - _begin - 1)], 9090h mov eax, [fs:18h] ; TEB mov eax, [eax + 30h] ; PEB _loop: pause cmp byte [eax + 2], 0 ; PEB.BeingDebugged je _loop int3 mov eax, 12345678h ; LdrInitializeThunk mov dword [eax], 12345678h ; restore original mov word [eax + 4], 1234h ; code jmp eax
And the x64 version:
BITS 64 default rel _begin: jmp _skip xor rcx, rcx xor rdx, rdx mov rax, 1234567890abcdefh ; NtTerminateThread call rax _skip: mov word [_begin], 9090h mov rax, [gs:30h] ; TEB mov rax, [rax + 60h] ; PEB _loop: pause cmp byte [rax + 2], 0 ; PEB.BeingDebugged je _loop int3 mov rax, 1234567890abcdefh ; LdrInitializeThunk mov dword [rax], 12345678h ;\ mov dword [rax + 4], 12345678h ;| restore original code mov dword [rax + 8], 12345678h ;/ jmp rax
Above code takes care of the second thread created during debugger attachment, so before entering the loop it overwrites first two bytes of the shellcode (jmp _skip) with NOPs and second thread goes directly to NtTerminateThread.
To make life easier I’ve created small application called LdrDebug that utilize above method. It will detect format of the executable (PE or PE+), inject proper version of shellcode and print PID of the created process:
e:\...\LdrDebug\Release>LdrDebug.exe notepad64.exe Creating process: notepad64.exe Arguments : (null) Type : x64 PID : 6216 (00001848) e:\...\LdrDebug\Release>LdrDebug.exe notepad.exe Creating process: notepad.exe Arguments : (null) Type : x86 PID : 6988 (00001B4C) e:\...\LdrDebug\Release>LdrDebug.exe /x64 notepad.exe Creating process: notepad.exe Arguments : (null) Type : x86 PID : 4240 (00001090)
There is additional switch ‘/x64′ that can be used to debug x64 part of x86 process under WOW64 subsystem. Application was tested on Windows 7, so I can’t guarantee that it will work on any other system. It might not work under Windows 8, as it uses wow64ext library and I had some reports that this library is not working on that system.
Link to binary package: http://rewolf-ldrdebug.googlecode.com/files/rewolf.ldrdebug.zip
Link to google code page: http://code.google.com/p/rewolf-ldrdebug/