DEV Community

Cover image for Windows Hot Patching Mechanism Explained
Bartosz Wójcik
Bartosz Wójcik

Posted on • Updated on

Windows Hot Patching Mechanism Explained

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:


push ebp
mov ebp,esp
mov eax,ecx
mov edx,0400h
Enter fullscreen mode Exit fullscreen mode

Function after the hook is set:


; 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


mov edx,0400h


; save original registers & CPU flags states
; execute hooking code, manipulate original parameters etc.

; 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
Enter fullscreen mode Exit fullscreen mode

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:

Hot patching bytes

Notice the difference. It looks like this:

; 5 nop instructions
db 90h, 90h, 90h, 90h, 90h


; mov edi,edi takes 2 bytes
mov edi,edi

push ebp
mov ebp,esp
mov eax,ecx
mov edx,0400h
Enter fullscreen mode Exit fullscreen mode

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.


; 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 '',0


; sample hook handler code
; it replaced every call to:
;  SetWindowTextA(hWindow, lpString);
; with
;  SetWindowsTextA(hWindow, "");
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


_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 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


_test_hooks endp
Enter fullscreen mode Exit fullscreen mode

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)