Having a 64bit machine for a month now, and in need to perform some tests on Windows x64 kernel, I decided it was time to take on Patchguard(PG). I started by searching the Internet for ways to disable it, and to my suprise there was almost nothing up to date on the subject.
I did found one working patch on PG by Fyyre. Pretty awesome work, I'd say. Basically he says to look for cross references of InitSafeBootMode and patch the one he points as critical. I found it pretty simple to follow, and wondered how a multi-billion dollar product can be broken so easily.
So, I started looking for tips in code that could denounce PG hot paths, and I found one:
I did found one working patch on PG by Fyyre. Pretty awesome work, I'd say. Basically he says to look for cross references of InitSafeBootMode and patch the one he points as critical. I found it pretty simple to follow, and wondered how a multi-billion dollar product can be broken so easily.
So, I started looking for tips in code that could denounce PG hot paths, and I found one:
Looking for cross references of KdDebuggerNotPresent. There are a bunch of them, but restricting the search to the following operations you get the critical path that enables PG:
1. cmp operations,
2. followed by conditional jump,
3. followed by a unconditional jump to the it's own location, locking the cpu.
The only two functions that relate to this, are KiFilterFiberContext and KiEnablePatchGuard.
It is as Microsoft didn't want us to enter this functions with a debugger, which is understandable as that could compromise PG, but they should at least not leave this red flags behind.
2 comentários:
It's documented behaviour that Patch Guard (aka KPP) will be disabled if a kernel debugger is present. Otherwise you'd be unable to set breakpoints etc.
Reference: http://msdn.microsoft.com/en-us/windows/hardware/gg487353.aspx (See "Is there any way to disable patch protection?")
Yeh, my key point was just that although the huge efforts by Microsoft to protect the kernel, as shown by Skape and Skywing papers, they seem to have left some clues to target the KPP setup. One of those, WinPE mode, was exploited by TDL, for example.
Enviar um comentário