01是处理硬段和单步异常之类的中断 0E是处理内存页面方面的中断
还有msr 82 就是syscall的r0处理函数 但是他都不是inline Hook 是直接把寄存器里的值改掉的
还有msr 82 就是syscall的r0处理函数 但是他都不是inline Hook 是直接把寄存器里的值改掉的
Win7 dnf除了降低权限和DebugPort清0外还替换了个假的cr3
我把 调试权限和进程权限DebugPort 和cr3解决后 用windows调试器调试的症状就是 会程序崩溃
所以现在只能用VEH调试了 VEH因为有TP有idt01的存在
所以导致了
硬件断点失效
单步失效
所以我们开始分析IDT
先打开xt 看看TP idt01的地址
结果发现 这里面的数据和系统IDT完全不一样 根本牛头不对马嘴 这里有个CALL 我们跟进去
然后......发现还是牛头不对马嘴 这里面一大堆计算 他还ret了出来 所以 这是肯定一段混淆 然后用ret返回真实的idt地址
这是以前分析的 所以前面地址不一样 入口这里还是没有变化 这里看不懂啥意思的话 可以自己去分析一遍 我写的可能有点乱
现在的IDT才对 一大堆保持环境 因为这里是IDT01 所以进来的时候rsp所在的位置是 _KTRAP_FRAME+0x168的位置这 个结构在我上篇分析IDT的帖子里有图片
因为veh断点是R3的操作 所以我们来看R3的处理 他干了啥 我文档上和windbg上面显示的地址不是一样的 不过代码他没有变 都是一样的 因为我文档有注释 所以我们看文档(在win7双机调试dnf的时候 会发现windng能断下来 但是不能单步 就是这里搞的鬼 R0处理的地方他有个单步位取反的操作)
他判断先前模式后 然后有各自的操作 下面是R3
这里他进了一个CALL 有4个参数 当前cr3 _KTRAP_FRAME+0x170 dr6 dr7
我们跟进去
这里面这个用方框框起来的地方 不知道这串运算有啥用 好多地方都有这样的运算 看不懂 晕晕
0x04
然后碰到了第一个CALL 参数就一个 cr3 穿进去比较的
这里找到里个一存储CR3的数组 我们用WINDBG看看里面的东西
这是一个存储结构体指针的指针 而这个结构体就是存储CR3之类信息的结构体 往下面看汇编代码
我们发现 他取到了这个结构体指针 用CR3和偏移为0 70 80的几个值比较了 所以这里应该存的也是CR3
用WINDBG看
从图中可以看出这个结构体0偏移位置为假的cr3 因为他PTML4都是空的
经测试 +0x70是存储真实CR3的位置
判断相同 对上了就会直接CR3就会直接返回 跳出去
这个函数里就做了一件事清 循环判断了CR3 判断正确了就返回这个存储CR3的结构体指针 错误了就返回0 图中我们看r8是结构体的指针ebx是循环了多少遍
这里乘以c700我们可以猜测出 这个结构体大小为c700
现在TP更新了 这个结构体大小变成D828了
然后我们返回到上一层
[注意]APP应用上架合规检测服务,协助应用顺利上架!