这里我研究的问题只有Patchguard怎么让丫去死，至于DSE这种东西，随便找个过时的有任意代码执行问题的驱动（比如DCR，VBOX，金山某士）去Patch一下CI就可以了。今天我也不是来跟人分享VMX或者patch文件那些无功夫的过PG手法。
　　我今天要做的是继续以前老外的pg的梗（由于我的笔记本跑win8不能10秒开机，所以只能用win7来撸）。
　　老外有几篇关于PG攻击的文章：
　　http://www.mcafee.com/in/resources/reports/rp-defeating-patchguard.pdf
　　http://www.uninformed.org/?v=3&a=3&t=sumry
　　http://www.uninformed.org/?v=8&a=5&t=sumry
　　http://www.zer0mem.sk/?p=271
　　
　　不过统统不能解决真正的问题，最后一个连接除外。不过其中的分析让我们知道两件事儿，第一件事儿是PG的蓝屏是通过DPC或者TIMER调用KeBugCheckEx来的。第二件事儿是PG调用KeBugCheckEx的时候，会恢复KeBugCheckEx上的修改。
　　通过读老外的文章我们知道通过DPC来的必须经过KiRetireDpcList这个玩意才能到达蓝屏（而通过TIMER来的经过的函数比较奇怪，这里也不想管他）。
　　老外有一个思路就是hook KeBugCheckEx来处理TIMER的PG引发的0x109蓝屏，但是因为KeBugCheckEx有恢复hook的可能（新的PG是复制了BugCheck的代码），所以我选择了一个KeBugCheckEx内部的调用的函数来进行挂钩，然后通过堆栈读出RCX判断一下错误号，这个调用函数也是老外早就提供好的就是RtlCaptureContext。
　　
　　到这里我都和老外的思路近似，之后后面就不一样了。我只有2个hook点，我不想判断DPC是不是PG的，也不研究线程TIMER的枚举，我直接在KiRetireDpcList这里保存运行环境（CONTEXT），然后继续调用KiRetireDpcList代码，然后保存的恢复运行环境（RIP修好）。
　　如果发生了0x109蓝屏，那么经过我挂钩的RtlCaptureContext时，我主动插入一个DPC到DPC链条去，然后恢复保存的CONTEXT到Call KiRetireDpcList处的去重新执行的话（也就是说，把时光倒流了），这时候PG就无法蓝屏了。但是这里有一个小问题，如果来自线程TIMER的PG蓝屏，则不能开蜘蛛的大招 回到过去 去Pass掉TIMER。不过windows的机制让我知道如果在pg的timer里的时候，IRQL应该是PASSIVE级别的，在PASSIVE级别的话，可以将整个执行流程跳入线程开始去直接运行（这点是老外的资料里发现然后结合windbg调试出来的）。
　　
　　那么我绕过PG的工具设计思路就是：

//有2个hook点！
//RtlCaptureContext-->保存ecx等物-->OrgCap-->ProcPatchGuard-->其他
//											-->ECX==109 ,来自BugCheck-->修复STACK，重新插入空DPC
//																		-->如果IRQL是PASSIVE,则CallPointer去
//																		-->不是PASSIVE,则恢复环境-->到KiRetireDpcList重新执行DPC序列
//KiRetireDpcList -->保存环境-->原始-->还原环境
//

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课