Document Version: 1 MSPatching ---------- - Purpose: To fix the existing (faulty) functions by replacing them with the fixed ones. - System restart is not the only option when module to update is in use. ColdPatching ------------ - replacing functions by replacing their containers - files and sections. An image to patch is "atomically replaced" with the image that contains all code and data that contains the the original one plus the fixed functions and the redirections to them (the embedded hooks). The functions to update are statically hooked and the hooks transfer the execution to the fixed functions in '.text_CP' section of a coldpatch module. This section and the following '.DBG_POR' section were added when creating the coldpatch module from the updated module sources. '.DBG_POR' section contains module imports, exports and a debug information. The debug information for the coldpatch module usually consits of two entries. The first entry is of CODEVIEW type, the second is RESERVED10. RESERVED10 data contains a coldpatch debug information that is comprised of 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. HotPatching ------------ - 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: 1) How to write the new function with instructions pointing to target module and with this conjuncted 2) 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 E9 Rel32 jmp FnContinue FnStart: FnStart: FnStart: FnContinue: 8B FF mov edi, edi EB F9 jmp $-5 55 push ebp 55 push ebp 55 push ebp 8B EC mov ebp, esp 8B EC mov ebp, esp 8B EC mov ebp, esp 56 push esi 56 push esi 56 push esi 57 push edi 57 push edi 57 push edi 8B 35 g_Data mov esi, g_Data ;fixup required 8B 35 g_Data mov esi, g_Data 8B 35 g_Data mov esi, g_Data 5x 90 5x nop E9 Rel32 jmp FnContinue FnStart: FnStart: FnStart: 55 push ebp 55 push ebp 55 push ebp FnContinue: 8B EC mov ebp, esp EB F8 jmp $-6 8B EC mov ebp, esp 56 push esi 56 push esi 56 push esi 57 push edi 57 push edi 57 push edi 8B 35 g_Data mov esi, g_Data 8B 35 g_Data mov esi, g_Data 8B 35 g_Data mov esi, g_Data ;fixup required FnStart: FnStart: FnStart: 55 push ebp 55 push ebp 55 push ebp 8B EC mov ebp, esp 8B EC mov ebp, esp 8B EC mov ebp, esp 56 push esi 56 push esi 56 push esi 57 push edi 57 push edi 57 push edi 8B 35 g_Data mov esi, g_Data E9 Rel32 jmp FnContinue FnContinue: CC int 3 8B 35 g_Data mov esi, g_Data ;fixup required * Sources - 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