Not working on Win10 15063
andronoob opened this issue · 23 comments
Hi, hFireF0X.
Thanks for your sharing.
I have tested this patch with a simple NTFS FSD hook driver, but it seems that PatchGuard is not successfully disabled, while DSE seemed to be indeed disabled, since the driver which was only self-signed successfully loaded into the kernel, with testsigning disabled.
I did nothing in the FSD hook, except DbgPrint and calling original MajorFunction. Dbgview shows that FSD hook successfully intercepted IRPs.
The Bugcheck codes match following pattern:
Bugcheck 109 (0xa39f****, 0xb3b6****, 0xffff****, 0x1c)
Original comment:
I'm testing on a freshly installed Win10 15063 x64 in VBox.
Simply launched patch.exe, and then pressed ENTER to continue.
but the program just showed the following line:
Patch: Press any key to exit
Then, window just disappeared after I pressed ENTER.
After that, it seems that neither ntoskrnl.exe nor MBR was modified.
You need to type CONTINUE all uppercase and then press enter. You just cancelled everything.
Sorry... What a funny mistake I've made.
The patch has been done successfully. I'll look in to see what will happen.
Thanks!
BTW, is it possible to disable PatchGuard using a driver which loads on boot? (just like procmon23.sys?)
Everything is possible, but why. Such bypasses was already implemented (see Skywing link in readme.md) before and even in various malware (WinNT/Turla for example). And all of them were later succesfully patched by next patchguard update.
PatchGuard is in ntoskrnl and initialize at it load. Which mean you have to:
- reverse it, for all required os, find a way to disable verification routines or patchguard timers.
- manage to load your unsigned driver (I doubt that your legally signed driver for PatchGuard bypass will last long before certificate revocation)
As you see this way is much more complicated and basically almost useless, because MS will update PatchGuard in next Windows 10 update again and broke your public method.
While the goal of this patch is to not allow this Microsoft whatever DRM/pseudosecurity rootkit code to even start. There is still possibility of reaction on this patch from MS, but because of wide variety of supported versions it leave as enough space to retaliate. Slightly longer "why not" is here in #1
However if you still want - do it, I completely support your startup.
Regarding to your first post, can you show bcdedit output for your current entry?
Also version of your ntoskrnl.exe and if possible attach it somewhere and give a link to download.
bcdedit showed that "Patch Guard Disabled" is the {current} entry, and it has been set to default.
C:\Windows\System32>bcdedit
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
description Windows Boot Manager
locale zh-CN
inherit {globalsettings}
nointegritychecks Yes
default {current}
resumeobject {d75c3dc6-26ad-11e7-9724-f3533f0ccaca}
displayorder {d75c3dc7-26ad-11e7-9724-f3533f0ccaca}
{current}
toolsdisplayorder {memdiag}
timeout 10
Windows Boot Loader
-------------------
identifier {d75c3dc7-26ad-11e7-9724-f3533f0ccaca}
device partition=C:
path \Windows\system32\winload.exe
description Windows 10
locale zh-CN
inherit {bootloadersettings}
recoverysequence {d75c3dc8-26ad-11e7-9724-f3533f0ccaca}
displaymessageoverride Recovery
recoveryenabled Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \Windows
resumeobject {d75c3dc6-26ad-11e7-9724-f3533f0ccaca}
nx OptIn
bootmenupolicy Legacy
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\osloader.exe
description Patch Guard Disabled
inherit {bootloadersettings}
recoveryenabled No
nointegritychecks Yes
osdevice partition=C:
systemroot \Windows
kernel ntkrnlmp.exe
resumeobject {a0a08b2d-2994-11e7-8278-806e6f6e6963}
nx OptIn
bootstatuspolicy IgnoreAllFailures
C:\Windows\System32>fc ntoskrnl.exe ntkrnlmp.exe
Comparing files ntoskrnl.exe and NTKRNLMP.EXE
00000160: E7 A8
00000161: 0F 8E
004C748B: 28 00
004C748C: 04 00
004C748E: C0 00
0054C59C: 8B 31
0054C59D: CE C9
0073E0DC: 40 B0
0073E0DD: 55 01
0073E0DE: 53 C3
I edited the output, since I'm not using an English version of Windows. I just translated some localized words into English.
Version of both two files: 10.0.15063.138
ntoskrnl.exe is kept unmodified as a backup, so it has a valid digital signature.
https://www.virustotal.com/en/file/30360ff2a41ab8ce733280aedfe61c0bbcb76a82cdb3d6c1f2859767f3d20ea5/analysis/
Patch before PG is able to initialize is a good idea, but modifying winload and ntoskrnl on disk is not friendly to Windows Update, since the updates to the kernel won't be applied to the PG-disabled ntoskrnl. In other word, I'd better have to disable Windows Update as well?
Maybe the attempt to patch PG initializing function by loading a boot time driver is too naive. But, it seems to be possible while using a MBR or .efi bootkit, which will do the patch in the memory, instead of modifying files stored on disk, so no matter how ntoskrnl changes, it will be patched by the bootkit, so that PG won't be able to start.
I wonder if such a bootkit is possible? especially on EFI based systems.
Thanks for your help.
Thanks for update. I forwarded this issue to Fyyre.
Yes, you have to update manually in normal configuration and patch again. Yes EFI bootkit sound very good. However since ntoskrnl also changing in these updates - you will have to update your software too. Simple example - cummulative update arrived and turned your system to the bsod loop, just because they updated PG and there is no guarantee that method you use will work again. So if you going to develop something like this - never release it on public anywhere, not as source not as article.
Hello,
Would it be possible to acquire your NTFS hook for further testing? Regardless, I will examine a few more things on my end
Thanks
Regarding question -- is possible to disable PG using mbr code. Answer is yes, my bootkit_fasm did just this.
Thank you, I will perform some testing.
Issue is now fix. 15063 fully running NTFS hook or DKOM. Update of code to follow in some days.
Please re-checkout the main branch, perform test. Report status here.
Thank you.
Tested KeInitAmd64SpecificState patch on 14393.447, did NTFS FSD hook, no bugcheck in about 5hrs.
Thank you for feedback =) Is excellent hearing this!
Tested KiFilterFiberContext patch on 15063.0, no bugcheck with NTFS FSD hook in about 7 hrs.
Unfortunately, symbol files of 15063.296 are still failing to download.
They failing to download to every newly updated system I tried because MS didn't pushed updated symbols to their symbols server yet.
Manually patched 15063.296 with a hex editor, using KiFilterFiberContext patched 15063.0 kernel as reference.
Loaded NTFS FSD hook driver. 12 hours later, no bugcheck.
MS released symbols for 15063.296 kernel.
Closing this issue. No Pg bugchecks occur after extensive testing.
Hi Fyyre,
I am using your tool to disable patch guard on windows 10 build version 1709, after running the tool, I checked bcdedit and it is updated with patch guard disable and booted my PC using disable patchguard boot option, it seems that all is good, so to confirm it further I used https://gist.github.com/andronoob/d5882c5e6d21f3dea534a68434abe040 andronoob NTFS FSD hook filter and starting this service using following tool:
- sc create FsFilter binPath= C:\temp\FsFilter1.sys type= kernel
- sc start FsFilter
But I am getting blue screen and windows crashing, means patch guard is not disabled.
Can you please help me, what I am doing wrong? your quick response will be highly appreciated.
Thanks
BR,
Adeel
@adeelmunir I've just pasted the inf file. Please use that inf file to install.