Introduction

With x64 versions of the Windows kernel, Microsoft has attempted to take an aggressive stance [1] against the use of a certain class of techniques that have been frequently used to ``extend'' the kernel in potentially unsafe fashions on previous versions of Windows. This includes patching the kernel itself, hooking the kernel's system service tables, redirecting interrupt handlers, and several other less common techniques for intercepting control of execution before the kernel is reached, such as the alternation of the system call target MSR.

The technology that Microsoft has deployed to prevent the unauthorized patching of the kernel that has been historically rampant on x86 is known as PatchGuard. This technology was initially released with Windows Server 2003 x64 Edition and Windows XP x64 Edition (known as PatchGuard version 1). The x64 editions of Windows Vista, and recently hotfixed versions of the Windows Server 2003 x64 kernel contain a newer version of the PatchGuard technology, known as PatchGuard version 2. The new version is designed to make it significantly more difficult for independent software vendors (ISVs) to deploy, in the field, solutions that involve patching the kernel after disabling the kernel patch protection mechanisms afforded by PatchGuard. The inner details of PatchGuard itself are much the same as they were in PatchGuard version 1 and thus will not be discussed in detail in this paper (excluding version 2's improved anti-debugging and anti-patch technologies). A sufficiently interested reader wishing some more background information on the subject may find out more about how PatchGuard version 1 functions in Uninformed's previous article [2] on the subject, ``Bypassing PatchGuard on Windows x64''.

PatchGuard version 2 takes the original PatchGuard release and attempts to plug various holes in its implementation of an obfuscation-based anti-patching system. In this respect, it has met some mixed success and failure. Although the new PatchGuard version does, on the surface, appear to disable the majority of the bypass techniques that had been proposed [2] as means to disable the original PatchGuard release, at least several of these techniques may be fairly trivially re-enabled through some minor alterations or additional new code. Furthermore, it is still possible to bypass PatchGuard version 2 without relying on dangerous (version-specific) constructs such as hard-coded offsets or code fingerprinting on frequently changing code. Additionally, aside from techniques that are based on disabling PatchGuard itself, there still exist several potential bypass mechanisms that have a strong potential to be ``future-compatible'' with new PatchGuard versions by virtue of preventing PatchGuard from even detecting that unauthorized alternations to the kernel have been made (and thus isolating themselves from any obfuscation-based changes to how PatchGuard's system integrity check is invoked). To Microsoft's credit, however, the resilience of PatchGuard to being debugged and analyzed has been significantly improved (at least with regard to certain key steps, such as initialization at boot time).