针对TP hook 0E 页表异常断点 处理方法 理论处理

恢复OE hook处理 不小菜不会 所以想了个方法 没实践 不过理论可行。

先说理论流程，我们都知道。TP处理了页表 就是CR3 这里说的环境是无VT win7 X64.

在虚拟机环境，完全确定无VT下 创建进程回调 先拿到CR3的值 然后创建个系统线程延时10秒后对比 CR3后恢复内存读写就OK了。

那么在实体机器上就不同了，BIOS关闭VT 不彻底（不应该是不彻底 是BIOS关不掉），但是TP还是HOOK了OE 而CR3症状是 不仅CR3值被改，连PDE PTE表也会被清0，

那么这个情况。我们读内存流程最后就是KeStackAttachProcess后切换CR3 ，当系统进程正常读写的时候因为CR3值为0会产生个OE中断TP在里面判断进程合法后给CR3正确赋值(当然这里完全可以保存你所读他保护进程的地址。然后上传分析。)然后返回中断EIP继续执行 那么我们可以在执行完正常读内存流程后 切换回原CR3 拦截得到 正确的页表KeUnstackDetachProcess这个地方 当正确系统进程拿到需要读的值后 会切换回原CR3 ，这个时候我们就可以判断当前进程CR3是否是DXF 当前线程是否为csrss进程 如果是 那么我们就保存当前 TP的CR3和页表 这样就能自己换算直接读物理内存 （爽歪歪直接读写 ，TP完全无任何感知，除了CRC），当然你也可以 恢复被他清0了的页表 走正常流程读写，不过现在还得处理句柄权限，还有msr寄存器，说不定那个地方就被他感知了。 所以直接物理内存，安全无副作用。美滋滋.连内存属性都可以不用管 。哪怕是虚拟内存不允许写入。你照样给他写进去。(语文不好，自己想法。有错误别喷.欢迎指出)