Hot Patching is a mechanism introduced in Windows XP if I remember correctly. It was created to solve the problems with hooking system library functions. For example to bugfix compatibility issues with older software running on a newer Windows version or applying security patches on the running machines.
How function hooking works at a low-level?
Normally hooking a function in DLL libraries or EXE files is about getting the memory address of the function and putting a so-called trampoline (a jump) to the hook handling routine in place of its first instructions. Sounds simple, right?
Let's take a look.
Sample function prologue (beginning) before setting the hook:
_function_x: push ebp mov ebp,esp mov eax,ecx mov edx,0400h ... Function after the hook is set:
_function_x: ; transfer execution to the hooking handler ; the original instructions were removed from ; the function prolog to put the JMP instruction ; that needs 5 bytes for encoding E9 xx xx xx xx jmp _hook_handler _after_the_trampoline: mov edx,0400h ... _hook_handler: ; save original registers & CPU flags states pushad pushfd ... ; execute hooking code, manipulate original parameters etc. ... popfd popad ; execute the code that's been cut off ; from the original function prologue ... push ebp mov ebp,esp mov eax,ecx ; return to the code after the trampoline jump jmp _after_the_trampoline This involves using a disassembler to get the correct size of the first instructions (different x86/x64 instructions have different sizes) and make sure to replace enough bytes (five to be exact) to fit the assembly jmp rel32 instruction (encoded as E9 xx xx xx xx bytes).
Problems with hooking prologue code with random instructions
But what if the first instructions are something else, like a call instruction? That would require rewriting the original call instruction or emulating it in the hooking handler code (we need to execute it after all!). But it's just troublesome to rewrite or emulate all the possible x86 instructions.
Microsoft has met such a demand for hooking and created a hot patching mechanism. The system library functions have a special prologue that makes it easy to quickly set up and remove hooks without having to bother to rewrite random instructions.
Function prologue with hot patching design
System library USER32.dll in HIEW hex editor and a sample function with hot patching code structure:
Notice the difference. It looks like this:
; 5 nop instructions db 90h, 90h, 90h, 90h, 90h _function_x: ; mov edi,edi takes 2 bytes mov edi,edi push ebp mov ebp,esp mov eax,ecx mov edx,0400h ... In hot patching enabled binaries (you need to build it with appropriate compiler flags!) the first bytes of the functions are always the mov edi,edi instruction (which does nothing by itself, it's like C++ version of 0=0; statement).
Before it, there is also a window (byte array) with five nop instructions encoded as 0x90, 0x90, 0x90, 0x90 bytes.
What's the deal here, huh?
First step. Putting a hook trampoline into such a constructed function consists of inserting the jmp short (encoded as two bytes EB xx opcode) instruction into this mov edi,edi instruction place.
Second step. It jumps to the above 5x nop window, where the call rel32 or jmp rel32 instructions are placed that jumps or calls the hook handler code.
So this time you don't have to worry about overwriting random function prologue instructions, because there is a standard construct that can be easily restored to the default value (unhooked).
The whole thing is trivially simple and allows you to quickly insert hooks without the need to use a library like Microsoft Detours.
Patching libraries using hot patching features
Below I present the code for MASM compiler, showing an example of setting a hook on SetWindowTextA function within our own process using hot patching code characteristics.
.data ; library to set a hook szLibUser db 'USER32.dll',0 ; hooked function name szSetWindowTextA db 'SetWindowTextA',0 ; original function address (after mov edi,edi prologue) lpOrgSetWindowTextA dd 0 ; default short jump instruction into 5 bytes NOP window ; it's encoded as a relative short jump instruction cHotPatchJmps db 0EBh,0F9h ; call _hook (E9 xx xx xx xx) instruction encoding cHotPatchCall db 0E9h dwHotPatchRel dd 0 szHookTest db 'https://www.pelock.com',0 .code ; sample hook handler code ; it replaced every call to: ; SetWindowTextA(hWindow, lpString); ; with ; SetWindowsTextA(hWindow, "https://www.pelock.com"); align 4 _hook_SetWindowTextA proc uses esi edi ebx, hWnd:dword, lpString:dword ; ignore the original lpString parameter ; and call the function with our bogus parameter ; push lpString <-- original parameter push offset szHookTest push hWnd call lpOrgSetWindowTextA ret _hook_SetWindowTextA endp align 4 _make_hook proc uses esi edi ebx, hProcess:dword, lpszLib:dword, lpszProc:dword, lpOrgPtr:dword, lpHookHandlerProc:dword ; check if the DLL is already loaded push lpszLib call GetModuleHandleA test eax,eax je _make_hook_exit ; get the function pointer push lpszProc push eax call GetProcAddress test eax,eax je _make_hook_exit ; save the function pointer to the EDI register mov edi,eax ; check if the first bytes of the function ; matches the bytes of the mov edi,edi instruction cmp word ptr[eax],0FF8Bh jne _make_hook_exit ; store the pointer to the code after the mov edi,edi ; instruction (where the real function starts) add eax,2 mov edx,lpOrgPtr mov dword ptr[edx],eax ; overwrite mov edi,edi instruction ; with a jump to the 5x NOP window push offset dwWritten push 2 push offset cHotPatchJmps push edi push hProcess call WriteProcessMemory ; hook handler routine address mov edx,lpHookHandlerProc ; let's build a call _hook_handler_proc instruction ; 5x NOP window memory address lea eax,[edi-5] ; call instruction is built like this: ; ; E9 xx xx xx xx ; ; where xx xx xx xx is 4 bytes of the relative ; address of the destination call address, relative ; to the position of the call instruction itself ; ; if we were to call the instruction right after ; any call instruction, for example like this: ; ; call _next_instruction_label ; _next_instruction_label: ; nop ; ; it would have been encoded as: ; ; E9 00 00 00 00 ; 90 ; ; to calculate the relative destination address ; take the destination pointer, subtract the call ; instruction pointer and its size (5 bytes) ; ; rel32 = dst - src - 5 ; sub edx,eax sub edx,5 mov dwHotPatchRel,edx ; patch library function memory, by overwriting ; the 5x NOP window with a call to the hooking ; handler routine push offset dwWritten push 5 push offset cHotPatchCall push eax push hProcess call WriteProcessMemory _make_hook_exit: ret _make_hook endp align 4 _test_hooks proc uses esi edi ebx ; our process ID call GetCurrentProcessId ; open our own process push eax push 1 push PROCESS_ALL_ACCESS call OpenProcess test eax,eax je _exit mov ebx,eax ; setup a hook mov edi,offset _make_hook push offset _hook_SetWindowTextA ; hook proc push offset lpOrgSetWindowTextA ; &lpOrgProc push offset szSetWindowTextA ; szApiName push offset szLibUser ; szLibName push ebx ; hProcess call edi ;_make_hook _exit: ret _test_hooks endp As you can see, hot patching can be used not only by Windows, but we can use it too to our advantage.
More low-level and reverse engineering resources
If you are interested in similar security and low-level topics, I invite you to read my articles about reverse engineering, malware analysis & assembler.
Top comments (0)