hotpatch

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

学习了

大哥能否翻译一下，E文吃力