This is going to be a pretty small blog, today we will be discussing on how to undetour functions - mostly NT (Kernel-Related Functions), undetouring is a pretty simple objective to follow. The steps to follow in order to undetour NT functions.
We will be using NtOpenProcess as a example - this is the most common function to be detoured by various Malware & security utilities running in usermode (Ring3).
We will not be using kernel-mode drivers or such fancy equipment - just a usual application (.exe) but with tricks and techniques.
Now, the start of NtOpenProcess is more or less easy to guess the first few bytes:
mov eax, 23
lea edx, DWORD PTR SS:[esp+4]
If the function has been detoured this is how the first few bytes would look:
lea edx, DWORD PTR SS:[esp+4]
This means the 1st and 2nd instructions are overwritten as the size of the jump is 5 bytes, so to unhook this function all we need to do is replace the jmp with the overwritten instructions. The technique is same as detouring but patching different opcodes.
I will first discuss the steps needed to implement a "Anti-Rootkit" software:
- Grab the Address of target function, in our case it is NtOpenProcess
- Compare if the prologue contains jmps
- If so unprotect the prologue of the target function
- patch the original instructions\opcodes into original spaces
- re-protect the prologue of the target function
First we will grab the address of NtOpenProcess:
Now we will use compare and see if the prologue contains tell-tale signs of any detour being placed:
Now we will unprotect the prologue of the function:
Now use the hot-patching\detouring method in order to patch undetour code onto function:
All we are doing now is re-protect it back to it's original format:
Now we have successfully undetoured the function, the code above were all snippets so this is the whole code to successfully undetour NtOpenProcess without using kernel-mode drivers, all in all we did a simpler job. Complete Code:
This code would unhook NtOpenProcess without much trouble or problem, however this could fail on other Windows (apart from 7 x64) as I have tested this code on only Windows 7 x64.
Anyway in my conclusion, I want to say that this code itself is not very fool-proof, as if a Malware or Sandbox detoured GetProcAddress or equivalent on a lower level, and blocked or filtered you call it would be disastrous, mainly being they could give you a wrong address.
If this is the case why not call KiFastSystemCall or X86SwitchTo64BitMode directly by moving addresses into eax, and moving parameters on to esp. This would be a better idea as not many malwares detour vital system call stubs, or on x64 you can try perform a code segment change and directly call Wow64ServicesEx to bypass this or detour this it takes a lot of work so not many malwares will be able to protect themselves from un-hooking.
Anyway, it is getting too long so lets wrap things quickly - If you understand how we unhooked NtOpenProcess, you can unhook all functions using a little bit logic and debugging.
Thanks! Please Comment and Share - Hope You enjoyed and learned.