DPC Routine Patching

A variation on technique 4.2, a very simple-minded approach to disabling PatchGuard would be to simply hook every possible DPC routine, check if the DPC is probably being called in order to execute PatchGuard's system integrity check, and if so, simply returning from the DPC to the kernel timer DPC dispatcher. In order to implement this approach, one first needs to locate each possible DPC routine. Technique 4.2 lists a number of viable algorithms for fingerprinting (and locating) each DPC routine; any (preferably multiple) of the suggested algorithms in that technique would be directly applicable to this proposed approach.

After one has identified all the possible DPC routines, all that is left is to patch each one to branch to driver controlled code. From there, the driver could make the decision as to whether the DPC is being invoked legitimately, or whether it is being invoked as part of PatchGuard's system integrity check process (easily identified by a non-canonical kernel address being passed as DeferredContext). If the DPC is PatchGuard-related, then all the driver need do to block PatchGuard is to immediately return to the DPC dispatcher.

This approach is fairly trivial to prevent (from Microsoft's point of view). Because it is signature-based, one possible counter-approach Microsoft could implement would be determining which signatures third party drivers use to detect PatchGuard DPCs, and altering the PatchGuard DPC routines to not match those signatures in the next PatchGuard version. Microsoft could also change the number of DPC routines to throw off drivers that assume PatchGuard will use exactly ten DPCs, or Microsoft could switch to an alternative delivery mechanism other than DPCs in order to prevent existing code that detects and hooks specific DPC routines from blocking PatchGuard.