System Call MSR Swap

A variation on the technique described in backref:4, it should theoretically be possible to swap the system call MSRs (or in fact several other processor control registers that are protected by PatchGuard) for the duration of DPC or timer DPC dispatching online, with the "tainted" values being restored after the dispatcher returns. The system call MSRs are responsible for designating the address of the system call dispatcher, and are thus an attractive target for third parties that would like to perform system call hooking.

The same basic concepts would be applied to this technique as previously described in the cr3 swap technique. If system calls are the only desired targets to hook, then the cr3 swap can be eliminated as unnecessary for single processor systems (as it would be safe to make and restore changes to the actual underlying physical pages before and after a DPC dispatcher call, using the return address on the stack as a way to return to the altered location without leaving opcodes patched in the kernel across dispatcher invocations). For multi-processor systems, some mechanism would need to be developed to allow the MSR swap to be made across DPC dispatchers while preventing code patches from becoming visible to a second processor. This is necessary because there could be more than one PatchGuard context executing simultaneously with the PatchGuard 3 addition of a probability to initialize a second check context at system boot time.

In order to block such a technique, Microsoft would likely be best served by making it difficult to locate all the regions necessary to patch in order to maintain the deception of an unpatched system across PatchGuard checks. The principal way to do this would be to create other, alternative launch vectors for PatchGuard that are unrelated to DPCs and, preferably, do not involve exported APIs that are easy to intercept from a third party perspective.