系统环境是win10 1809 17763.437

我没有研究怎么解密上下文，我主要是想办法得到Pg蓝屏时候的堆栈，然后根据对应的方法找对应的攻击措施。

对于dpc例程来说，最有帮助来判断是不是pg的dpc就是DefferContext，很多资料都提了。

首先我做的是hook KiDispatchException，一方面是能够更快的触发PG，另一方面是在PG接手异常前，DbgBreakPoint()，让调试器接管，这样就可以得到PG调用的堆栈。在KiDispatchException中我们可以判断rip，rbx，rdx。大多数通过异常触发DPC都是触发KiCustomRecurseRoutinex这里，但是不管你是把rip跳过那条异常指令还是给一个合法的寄存器让他解引用来绕过异常，后面都还是会出另一个异常，而且有时候会连续验证2次。

PatchGuard会在_except块里恢复寄存器，然后再执行这个函数正常的功能。也就是说没有执行他的except块后面正常执行的时候还是会蓝屏。

下面是其中一次的堆栈，

上面是其中一种，攻击方法是hook KiProcessExpiredTimerList，

原理是替换一个垃圾DPC让Pg执行。我一开始还想过hook _guard_dispatch_icall来处理所有的函数指针调用，发现一hook就死机，不管是虚拟机还是主机都一样。

在打第二次虚拟机快照的时候，Pg又蓝屏了。这一次他并没有通过异常，也没用DPC。我想了一会没想出来他是怎么触发的。

然后我从PG的上下文内存分配入手，一开始我什么也不知道，就直接hook ExallocatePoolWithTag来试一下，在所有分配大字节全部断下

然后看堆栈，因为pg执行是没有模块并且临时分配的，windbg肯定识别不出名字，把堆栈过滤一下，一个个排除可疑线程，结合IDA，能够断到这里来

这个函数特征码 8B 81 F8 07 00 00 0F 31 48 C1 E2 20，我把这个函数叫PgAllocateContext，第一个参数就是上一次或全局上下文，作用是分配新的上下文准备验证。从这里可以看到PatchGuard至少有2种内存分配，后面好像还一种，但是又好像没什么关系。一个MmAllocateIndependentPages，一个ExAllocatePoolWithTag，MmAllocateIndependentPages这个除了pg一般系统函数用不到，而且绝大部分是用ExAllocatePoolWithTag分配的。一般情况，PG在系统开机时候生成一个或多个上下文，然后验证的时候，再临时分配新上下文并且马上开始验证，但是，有时候pg不临时分配context，看后面还有一种情况。还有pg调用函数都是通过KeGuardDispatchIcall用context内容跟作为索引来调用的。

既然我们断到了那个pg分配上下文的线程，我们就记住这个线程地址，然后恢复虚拟机快照直接找这个线程，因为pginit在开机就被调用了，他的验证手段选择完了，如果他选择是单独的一条线程，那他没验证的时候一定是通过某个方法在等待执行。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)