@zer0mem

And also when you look at the third mentioned exit point, and keep eye on values from which are formed PatchGuard context address, you will trace smth like this :

So as you can see, when you are able to filter all exit points, then it should not be problem, in current state of PatchGuard, recognize if DerferredRoutine is related to PatchGuard and locate its context.

• Position of Syscall pointer inside PatchGuard context

nt!KiDispatchCallout method snapshot, i post here mainly because it clearly describe how to pwn PatchGuard. First DWORD would be always patched at the same value – probably because try to handle one of bypass technique ? – and cause of nature of decryptor you know how to looks like also first QWORD (0x085131481131482e), and it means disclosure of XOR_KEY! And when you take a deeper look at PatchGuard decryption mechanism, you can play with it in your own :

(even without xoring it would be possible to gather this xor_key -xoring is just pretty shortcut –> just keep in mind you are at the same level as PatchGuard, in your hook you have the same data available, and you can debug – disasemble – just play with code which calc this xor_key)

Position of Syscall ptr is relative to main function of PatchGuard, and position of this main function is stored in structure describing its context :

• Pwn PageGuard context

Two problems can raise when you try to patch :

1. Code is encrypted
2. Context is checksumed

But you known encryption mechanism, so you need just to implement encrypt / decrypt mechanism, and also Just Code and PAGEGUARD_STRUCT is encrypted, data are plain Second problem can be solved by disasembling checksum mechanism, and re-calc checksum on current data .. crc snapshot :

Problems & points to research:

• PageGuard is not one-threaded so it is necessary to handle with all threads
• Find out all exit points

Conclusions : PatchGuard is very nice piece of code, really challenging :) In my opinion there should be always way how to ‘defeat’ it (when you are at the same privilage level it is all just about gongfu ), but i guess thats not a point. Main reason in patchguard i see to force software vendors to avoid intercept kernel with hooks and altering key structures in undocumented way. But in this way of looking at problem, i did not come with idea why so much hardering. But i believe that it is interesting part of job for m$ developers, hide code, implement obfuscation, respond to new bypass techniques etc. – but it sounds familiar does not it ?

On the other side, when m$ do it also with anti-malware reasons, i am not sure that they do it effectively. Malware writers does not come to them with this kind of findings, instead of this they will implement and sales it. And when new bypass technique invented by malware writers would be uncovered what would m$ do next ?

… when they just update its patchguard it cause BSOD on infected machines =>users dont like bsod. With legitimate software vendors it is fault by 3rd party and user will blame crappy software. But in case of malware m$ will need to handle desinfection of system at first, otherwise they are screwed up by malware writers …

So i think PatchGuard is perfect for rule over software vendors, that they can not patch kernel, but not as malware protection. I think when m$ would to improve this code more efficiently they should to create some kind of competition like pwnium, but related to breaking the PatchGuard, it will gave reason for hardering PageGuard and it will be more fun