Windows X64 Patch Guard

First introduce the next PatchGuard, from Baidu Encyclopedia

PatchGuard is the Windows Vista kernel protection system that prevents any unauthorized software from trying to "modify" the Windows kernel, that is, the new Admiralty Hood of the Vista kernel. PatchGuard adds a new layer of security to Windows Vista, and the ASLR (Address Space Layout randomization) We've introduced to you is also below this security layer. PatchGuard can effectively prevent kernel-driven mode from altering or replacing any content of the Windows kernel, and third-party software will no longer be able to add any "patches" to the Windows Vista kernel. Is the Microsoft from the x64 structure to add a layer of protection technology, the core of the kernel to detect, if the kernel is found to be modified in the key location of the direct blue screen, and in the x64 also introduced DES, that is, the driver load requires a digital signature. We cannot "do what we like" under the x64 under the x86. For example, x86 play under the super-happy of the overloaded kernel in x64 basic impossible, SSDT can not hook, debugport can not clear zero and so on. But in Win7 x64 come out not long abroad Daniel Fyyre released the kernel hack tool, here gives the link http://fyyre.ivory-tower.de/followed by Daniel published the source code, I also just learn Daniel source code, record their learning process. Put the original text of Fyyre first.

//Disable PatchGuard - the easy/lazy way.
//for Vista SP2 & Windows 7 (X64)
//
//by Fyyre (thank you Roxaz for helping me to test)
//http://fyyre.l2-fashion.de/
//http://twitter.com/Fyyre

Last update: 19/03/2011

This txt file provides a general overview/outline for bypassing signature validation of critical system files (ntoskrnl, mainly) during
The Vista/Win 7 boot phase. It is documentation of the steps taken from start to finish, to reach the desired goal of removing
Kernel patch protection "PatchGuard" without use of a driver. We will call this the ‘lazy/easy‘ way to kill PatchGuard.

We cannot modify ntoskrnl without winload taking up issue...

Winload.exe is the Windows loader for Vista & Windows 7. Along with this, he makes some verification of digital signatures and
Assessment to make sure the files have not been modified. If modification of ntoskrnl is detected, the result is winload *refusing*
To boot Windows and launching a WinPE looking "Recovery Mode".

PART I { additional }: new way for patch of winload.exe

Function ImgpValidateImageHash - signature we locate: 8B C3 49 8B 5B 20 49 8B 73 28 49 8B 7B 30 4D 8B -- you may play with this one to make him smaller. as for this
Patching, use of dUP2... size of not a concern. First bytes replaced with xor eax, eax (STATUS_SUCCESS) .. all validations successful.

PART I: disassembly and modification of winload.exe

Starting from OslpMain, after loading the System registry hives(registry)... occurs a call to OslInitializeCodeIntegrity:

.text:00000000004016C3 call OslpLoadSystemHive
.text:00000000004016C3
.text:00000000004016C8 cmp eax, ebx
.text:00000000004016CA mov edi, eax
.text:00000000004016CC jl loc_401A08
.text:00000000004016CC
.text:00000000004016D2 mov ecx, ebp
.text:00000000004016D4 call OslInitializeCodeIntegrity <<-- =(


.text:00000000004057E8 OslInitializeCodeIntegrity proc near

Original code -->>

We will replace four bytes here:

48 8B C4 53
.text:00000000004057E8 mov rax, rsp
.text:00000000004057EB push rbx
.text:00000000004057EC push rbp


With: 0B0h, 01h, 0C3h, 090h ... which produce:

Mov al, 1
Ret
Nop

Save as winload.exe as osloader.exe (or whatever..) & correct PE checksum (LordPE and/or CFF_Explorer will do). Copy osloader.exe to \Windows\System32

PART II - new BCD entry:

Bcdedit /copy {current} /d "PatchGuard Disabled"

"The entry was successfully copied to {01234567-89ab-cdef-00ff-fff000ffffff}" <<-- GUID of new entry. each is different!

Bcdedit /timeout 10 <<-- number of seconds to show boot menu.

Bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} nointegritychecks 1 <<-- no validation of winload

Bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} recoveryenabled 0 <<-- optional... i dislike this feature, therefore disable.

Bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} path \Windows\system32\osloader.exe

Bcdedit /set {01234567-89ab-cdef-00ff-fff000ffffff} kernel ntkrnlmp.exe (name of modified ntos... =))

Part III: Skip Initialization of PatchGuard - - (driver not required)

As for this .txt, and PatchGuard... we are concerned with one function KiInitializePatchGuard(*1) which is called by KiFilterFiberContext.
KiInitializePatchGuard is a very large function located in the INIT section of ntoskrnl, you can easily locate him via two calls from
KiFilterFiberContext, by examination xrefs to exported dword InitSafeBootMode, searching for db 20h dup(90h) + db 044h ... or 48 81 EC 58 0F 00 00 to
Name a few...

PatchGuard does not initialize if we boot into safe mode. So to disable we just patch one conditional jxx

KiInitializePatchGuard:

Original code -->>
INIT: 000000014055D359 sub rsp, 0F58h
INIT: 000000014055D360 xor edi, edi
INIT: 000000014055D362 cmp cs: InitSafeBootMode, edi
INIT: 000000014055D368 jz short loc_14055D371
INIT: 000000014055D368
INIT: 000000014055D36A mov al, 1
INIT: 000000014055D36C jmp loc_1405600D9

Modified code -->>
INIT: 000000014055D359 sub rsp, 0F58h
INIT: 000000014055D360 xor edi, edi
INIT: 000000014055D362 cmp cs: InitSafeBootMode, edi
INIT: 000000014055D368 nop
INIT: 000000014055D369 nop
INIT: 000000014055D36A mov al, 1
INIT:000000014055D36C jmp loc_1405600D9 <<-- to end of KiInitializePatchGuard

And back to KiFilterFiberContext... and important detail:

The first jxx in KiInitializePatchGuard must not be taken & al == 1. When we return to KiFilterFiberContext, the jxx must be taken,
And EBX must not be xor‘d ... (unless enjoy BSOD).

INIT: 0000000140567110 loc_140567110:
INIT: 0000000140567110 test al, al
INIT: 0000000140567112 jnz short loc_140567116
INIT: 0000000140567112
INIT: 0000000140567114
INIT: 0000000140567114 loc_140567
114:
INIT: 0000000140567114 xor ebx, ebx <<-- bad
INIT: 0000000140567114

Anyways... nop the first jxx in KiInitializePatchGuard... save modified ntoskrnl.exe with a different name (i.e. ntkrnlmp.exe) ... fix checksum (PE header).
Then copy your modified kernel to \Windows\system32 -- with bcdedit -->>

Bcdedit /set {guid-of-new-entry} kernel ntkrnlmp.exe

When you reboot the system, loading your modified kernel should be a success... He will load without PatchGuard initializing, which will allow you to
Once again play in kernel mode without receiving BSOD as result...

This could be worked into mbr bootkit code as well... this is beyond the scope of our intention.

-Fyyre

References:
*1: Bypassing PatchGuard on Windows x64, by Skywing 12/1/2005

According to the article we first put Winload.exe into Ida, according to the article to locate the Oslpmain function (here I have imported the Winload.exe symbol table)

.text:00000000004016BE 4C 8B C6 mov r8, rsi
.text:00000000004016C1 8B CD mov ecx, ebp
.text:00000000004016C3 E8 94 04 00 00 call OslpLoadSystemHive //Load the registry unit
.text:00000000004016C8 3B C3 cmp eax, ebx
.text:00000000004016CA 8B F8 mov edi, eax
.text:00000000004016CC 0F 8C 36 03 00 00 jl loc_401A08
.text:00000000004016D2 8B CD mov ecx, ebp
.text:00000000004016D4 E8 03 41 00 00 call OslInitializeCodeIntegrity 

After discovering that the Oslinitializecodeintegrity function was called after the registry unit was loaded, we continue to follow

The original code

 
.text:00000000004057DC                   OslInitializeCodeIntegrity proc near
.text:00000000004057DC 48 8B C4          mov     rax, rsp
.text:00000000004057DF 53 push    rbx
.text:00000000004057E0 55 push    rbp
.text:00000000004057E1 57 push    rdi
.text:00000000004057E2 41 54 push    r12

All we have to do is replace the first byte, so that the whole function no longer executes, because in the next call Blimgquerycodeintegritybootoptions, Because Blimgquerycodeintegritybootoptioins verifies the validity of the Ntoskrnl.exe digital signature and refuses to load the Ntoskrnl.exe if it is illegal, we need to bypass this function

.text:00000000004057FB 48 8D 50 10 lea     rdx, [rax+10h]
.text:00000000004057FF 4C 89 68 20 mov     [rax+20h], r13
.text:0000000000405803 49 8B FD          mov     rdi, r13
.text:0000000000405806 4C 89 68 C8       mov     [rax-38h], r13
.text:000000000040580A E8 21 B6 02 00 call    BlImgQueryCodeIntegrityBootOptions

So the Ollinitializecodeintegrity function begins to return directly, skipping Blimgquerycodeintegritybootoptioins

will be   8B C4          mov       rax , 
RSP replaced with 1 C3   

Next up is Ntoskrnl.exe.

Based on the instructions in the article, navigate to the Kifilterfibercontext function and find the call to Kiinitializepatchguard

INIT: 0000000140577106 8B D1 mov edx, ecx
INIT: 0000000140577108 41 8B C9 mov ecx, r9d
INIT: 000000014057710B E8 30 62 FF FF call KiInitializePatchGuard //This is my own rename, the original is just an address, there is no symbol table

Start-up mode is detected where the Kiinitializepathcguard function starts

NIT: 000000014056D360 33 FF xor edi, edi
INIT:000000014056D362 39 3D 88 21 D1 FF cmp cs:InitSafeBootMode, edi //Check if it is started in safe mode. If you start PatchGuard in safe mode, it will not be initialized.
INIT:000000014056D368 74 07 jz short loc_14056D371 //The jump here is the initialization of PatchGuard, we will notp it
INIT: 000000014056D36A B0 01 mov al, 1
INIT:000000014056D36C E9 68 2D 00 00 jmp loc_1405700D9 //Direct jump to the end of the KiInitilizePatchGuard function, not initialized 

Then save and add our own "kernel" to the startup item.

Windows X64 Patch Guard