OpenRCE

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Wednesday, April 26 2006 11:50.34 CDT

Author:

EliCZ

# Views: 51011

Printer Friendly ...

Caveat Emptor

This article was not written to read like a novel. It is a to-the-point technical dump describing the inner workings of Microsoft's cold and hot patching process. The majority of the symbolic names listed below have been derived from NTDLL and NTOSKRNL. Please post any questions you may have directly (for the benefit of others) to this article and the author will gladly respond. The article may be updated in the future to include some of these answers inline.

A companion download including examples and appropriate header files is available for download: MSPatching.zip.

Cold Patching

Replacing functions by replacing their containers - files and sections.

The image to patch is "atomically replaced" with an image that contains all code and data contained within the original plus the fixed functions and redirections to them through embedded hooks. The functions to update are statically hooked and the hooks transfer the execution to the fixed functions in the '.text_CP' or '.text_CO' section of a coldpatch module. This section is followed by the '.DBG_POR' section in situations where the original '.data' section has to be modified. In other cases, the '.text_CP' / '.text_CO' sections are followed by '.data_CP' or '.data_CO'. Overall, there can theoretically be as many _CP / _CO sections as the original image has (.text, rdata, .data, etc..). The '.DBG_POR' section contains module imports, exports and a debug information. The debug information for the coldpatch module usually consists of two entries. The first entry is of CODEVIEW type, the second is RESERVED10. RESERVED10 data contains the coldpatch debug information that is comprised of the HOTPATCH_DEBUG_HEADER structure followed by HOTPATCH_DEBUG_DATA structure. HOTPATCH_DEBUG_HEADER.Type has value DEBUG_SIGNATURE_COLDPATCH. The contents of HOTPATCH_DEBUG_DATA are used in a process called 'target module validation' when the validation of the original module fails and hotpatch checks if there is a coldpatch present.

The atomic file replacement is realized by filling the SYSTEM_HOTPATCH_CODE_INFORMATION.RenameInfo structure and calling SYSTEM_HOTPATCH_CODE_INFORMATION.Flags.HOTP_RENAME_FILES sub-function of ExApplyCodePatch (SystemHotpatchInformation class of Nt/ZwSetSystemInformation) function. HOTP_RENAME_FILES sub-function is not implemented in the newer OS versions/builds.

Replacing the image on a volume doesn't mean that all the newly created processes will load/contain the updated image. For the system purposes, security or for increasing module loading speed, a sections can be emplyed in the process of the image loading. The section for a system module (ntdll.dll, ...) is updated by HOTP_UPDATE_SYSDLL sub-function (no structure required). The section for the loader (from \KnownDlls object directory) is updated by calling HOTP_UPDATE_KNOWNDLL with AtomicSwap sub-structure filled. The old object's name is swapped with newly created temporary object (update.exe names the section 'ColdPatchInstallationInProgres') in the object directory.

Hot Patching

Replacing functions by replacing their code in the memory. Available since Server 2003 SP0, XP SP2 x86, ia64, x64.

Functions were successfully fixed on the volume. Now they should be changed in the memory - in the kernel memory for kernel modules or in the memory of user processes that contain the module to update. The functions to patch are dynamically hooked - one sufficiently long CPU instruction or data (pointer, RVA) of the function to fix is replaced with a branch instruction (pointer, RVA) that redirects an execution flow to a fixed function in the hotpatch module. After applying the hooks, the patched module in memory looks like the coldpatch module, just the targets of the branch instructions do not lie within '.text_CP' section but in the code section(s) of the hotpatch module.

The hotpatch module may contain the debug information similar to the coldpatch's one, just RESERVED10 data consists of HOTPATCH_DEBUG_HEADER only and HOTPATCH_DEBUG_HEADER.Type has value DEBUG_SIGNATURE_HOTPATCH.

The hotpatch module must contain a section named '.hotp1 ' that is at least 80 bytes (sizeof(HOTPATCH_HEADER)) long and that must begin with a HOTPATCH_HEADER structure. The structure is used for validating the target module, fixing relocations and creating intermediate RTL_PATCH_HEADER structure.

When applying the hotpatch to a user module, an updating agent enumerates the processes and creates remote threads into them that execute ntdll.LdrHotPatchRoutine. Newer OS versions/builds allow the remote thread creation from the kernel mode when HOTP_INJECT_THREAD sub-function is called and InjectInfo sub-structure is correctly filled.

LdrHotPatchRoutine checks if HOTP_USE_MODULE flag is set and the target module, whose base name is specified in UserModeInfo.TargetNameOffset, is present in the process. When applying the hotpatch to a kernel module, (ntoskrnl.MmHotPatchRoutine) both HOTP_USE_MODULE and HOTP_KERNEL_MODULE flags must be set and KernelInfo sub-structure must be filled.

The Source (hotpatch) module is loaded and checked for the presence of '.hotp1 ' section, HOTPATCH_HEADER.Signature and Version. If RTL_PATCH_HEADER for the source module already exists, hooks were successfully applied and HOTP_PATCH_APPLY flag is clear, the hooks are removed. Otherwise RTL_PATCH_HEADER is created, the target module whose name is in HOTPATCH_HEADER.TargetNameRva is checked for presence and validated according to ModuleIdMethod using TargetModuleIdValue. If there's a validation mismatch, system checks whether the target module is the coldpatch according to the coldpatch debug info. If it is the coldpatch, PATCHFLAG_COLDPATCH_VALID flag is set in RTL_PATCH_HEADER.PatchFlags.

The functions to fix may access the target image, they can call its functions and use its variables (it means pointers and call and jump targets do not have to be in the hotpatch module because they point directly to the target module). Such codes must be fixed using special relocation fixups from HOTPATCH_HEADER.FixupRgnRva with respect to HOTPATCH_HEADER.OrigHotpBaseAddress and HOTPATCH_HEADER.OrigTargetBaseAddress. Then the functions function as they would be called from the original module. Number of the HOTPATCH_FIXUP_ENTRY structures in the HOTPATCH_FIXUP_REGION must be even number. If the hotpatch contains standard base relocations, they usually apply only to a pointers to hotpatch's import table (APIs).

Various places of the target module can be validated according to HOTPATCH_VALIDATION structures in HOTPATCH_HEADER.ValidationArrayRva. Validations with option HOTP_Valid_Hook_Target are skipped (those are the places to patch).

HOTPATCH_HOOK_DESCRIPTOR structures are prepared according to HOTPATCH_HOOK structures in HOTPATCH_HEADER.HookArrayRva. HOTPATCH_HOOK.HookOptions contain in their first 5 bits the length of the instruction to replace and it must be at least as long as the length of the branch instruction - the rest is, for some hook types, padded with bytes of value 0xCC.

Again there's possibility to validate the bytes that will be replaced (HOTP_Valid_Hook_Target has now no effect). If there's a mismatch and the patch place already contains the adequate branch instruction, a list of RTL_PATCH_HEADER structures in TargetModule.LDR_DATA_TABLE_ENTRY.PatchInformation is traversed and bytes at HOTPATCH_HOOK_DESCRIPTOR.CodeOffset are compared with the prepared branch instruction. If there's mismatch and the target module is the coldpatch, the validation succeeds for some hook types, for the other ones is checked whether the branch instruction points into the coldpatch.

Upon succesfull validation and hook preparation are the remaining members of RTL_PATCH_HEADER filled in, the sections of the target module are made writable and the hooks are written by calling ExApplyCodePatch with RTL_PATCH_HEADER.CodeInfo and HOTP_PATCH flag set. If the patch application succeeds, RTL_PATCH_HEADER is linked to TargetModule.LDR_DATA_TABLE_ENTRY.PatchInformation list.

There's no security issue: Debug and LoadDriver privileges must be enabled for all Cold/HotPatch operations except for user mode hotpatching or when applying CodeInfo directly. CodeInfo cannot be directly applied to kernel when calling ExApplyCodePatch from user mode.
CodeInfo is applied "os-atomically" - the preemption is unlikely.
Function to fix doesn't have to be compiled (/linked) with /hotpatch (/functionpadmin) option.
There's no public tool (special version of C compiler, linker?) for creating the cold/hotpatches. It is possible to write a tool that will add/write to '.hotp1 ' section of image created by normal compiling/linking but there are 2 problems:
- How to write the new function with instructions pointing to target module and with this conjuncted
- Fixup handling. Anyway, one doesn't have to use the target module functions/data so there's no need for the hotpatch fixups.

Hook Types

HOTP_Hook_None

HOTP_Hook_VA32
32 bit value/pointer, 4 bytes

HOTP_Hook_X86_JMP
x86/64 long relative jump, E9 Rel32, <-2GB..2GB-1>,
Rel32 constructed according to Hook/HotpRva,
>= 5 bytes, padded with 0xCC

HOTP_Hook_PCREL32
not yet implemented,
for fixing Rel32 of x86/64 call or jump, 4 bytes

HOTP_Hook_X86_JMP2B
x86/64 short relative jump, EB Rel8 <-128B..127B>,
Rel8 is in HotpRva,
>= 2 bytes, padded with 0xCC

HOTP_Hook_VA64
64 bit value/pointer, 8 bytes

HOTP_Hook_IA64_BRL
ia64 branch, at HookRva must be a supported template type
>= 16 bytes

HOTP_Hook_IA64_BR
not yet implemented

HOTP_Hook_AMD64_IND
x86/64 absolute indirect jump, FF 25 [Offset32 / Rip+Rel32]
HotpRva (+Rip) must point to a variable that contains a pointer to fixed function,
>= 6 bytes, padded with 0xCC

HOTP_Hook_AMD64_CNT
16bit value/pointer, 2 bytes Hook combinations are allowed - HOTP_Hook_X86_JMP2B + HOTP_Hook_X86_JMP is typical. When the distance hotpatch-target exceeds 2GB, HOTP_Hook_AMD64_IND must be employed on x86/64. One then needs a place to store the pointer specified in [Offset32 / Rip+Rel32]. For x86 it can be inside the hotpach module but for x64 not. HOTP_Hook_AMD64_IND + HOTP_Hook_VA64 is the solution. /hotpatch option for x64 is not yet implemented but I would suggest:

  Buffer: //for HOTP_Hook_VA64
    8x nop
  FnStart:
    48 8D A4 24 00 00 00 00  lea rsp, [rsp + 0]  - 2 bytes more than required
   or
    0F 8x 00 00 00 00   j?? $+6 - as long as required but slower

  In Colpatch/After Hotpatching it could look like:
  Buffer:
    Ptr64FnContinue
  FnStart:
    FF 25 F2 FF FF FF  jmp qword ptr [Buffer] //[Rip-14]
    CC
    CC

Of course there's possibility to make a triple patch: JMP2B -> IND -> VA64.

x86 Patch Examples

Function created with /hotpatch, "semi-hotpachable" function, "non-hotpatchable" function. You may notice there's replaced more than one CPU instruction (5x nop with long relative jmp) but the nops are not involved in the function - they serve as buffer.

Original Function

ColdPatch/After HotPatching

In Cold/HotPatch

5x 90         5x   nop
FnStart:      
8B FF         mov  edi, edi
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data


5x 90         5x   nop
FnStart:      
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data


FnStart:      
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data

E9 Rel32      jmp  FnContinue
FnStart:      
EB F9         jmp  $-5
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data


E9 Rel32      jmp  FnContinue
FnStart:      
55            push ebp
EB F8         jmp  $-6
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data


FnStart:      
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
E9 Rel32      jmp  FnContinue
CC            int  3

FnStart:      
FnContinue:   
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data
              ; fixup required


FnStart:      
55            push ebp
FnContinue:   
8B EC         mov  ebp, esp
56            push esi
57            push edi
8B 35 g_Data  mov  esi, g_Data
              ; fixup required

FnStart:      
55            push ebp
8B EC         mov  ebp, esp
56            push esi
57            push edi
FnContinue:   
8B 35 g_Data  mov  esi, g_Data
              ; fixup required

References

- Inside Update.exe - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/deployment/winupdte.mspx
- KB packages for Server2003 x86 that contain the cold/hotpatches: 819696, 823182, 888113, 893086, 899588, 901190

Article Comments Write Comment / View Complete Comments

Username	Comment Excerpt	Date
xpoy	a list of RTL_PATCH_HEADER structures in Target...	Monday, May 2 2011 10:45.37 CDT
lain32	Good!!	Sunday, November 30 2008 04:32.20 CST
h4x0r	heh, so microsoft actually got hot-paching done...	Monday, May 14 2007 18:44.09 CDT
EliCZ	819696, 823182, 888113, 893086, 899588, 901190 ...	Wednesday, January 24 2007 09:04.35 CST
mugg	Got an example of Microsoft using the 'hot-patc...	Tuesday, January 23 2007 01:26.44 CST
r1ck	Hot-patch is not persistent, is only in memory....	Friday, August 18 2006 13:49.09 CDT
EliCZ	Cold-patched image has the faulty functions red...	Friday, August 18 2006 01:45.52 CDT
r1ck	I'm a win32 ignorant, but why not to cold-patch...	Thursday, August 17 2006 16:07.29 CDT
JxT	This is a good write up, thanks for sharing!	Saturday, May 6 2006 03:38.03 CDT
Opcode	Awesome article! Thanks!!!	Thursday, April 27 2006 08:43.22 CDT

There are 31,320 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
hi!	Jul/01
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit