? 昨天在给系统调用入口下硬件断点时发现了两种不同的情况,结合IDA,Windbg,Intel文档思考了许久,记录一下自己的想法,并不保证一定正确,测试环境Win10 1903 x64
swapgs
之后和mov rsp, qword ptr gs:[7008h]
之前,这时的环境应该是gs已经切换但内核栈还未切换
swapgs
之后和切换内核页表之前,但是这并不影响IDT处理例程读取内核空间,因为IDT handler会根据KiKvaShadow切换CR3g
之后,Windbg接收到异常,堆栈如下KiDebugTrapOrFaultShadow
触发时,已经进行了堆栈切换,但是按照我们对x86异常处理的理解,这里由于是从nt!KiSystemCall64Shadow
触发的硬件断点,所以应该不存在权限切换,所以CPU应该不会自动切换堆栈,如下图
KiDebugTrapOrFault
时堆栈是正常可靠的0环堆栈,但是在Windbg中可以看到在nt!KiDebugTrapOrFault+0x65
发生了异常,经过分析,在这段代码中用到了异常前的堆栈进行数据存储,也就是说内核调试例程需要内核栈的支持,而我们触发硬件断点时堆栈还没有进行切换,因此在KiDebugTrapOrFault
异常处理例程中又发生了异常,从而引起了nt!KiDoubleFaultAbort
双重异常swapgs
这里,也就是gs还有没切换时触发KiDebugTrapOrFaultShadow
,然后Windbg按下g
之后虚拟机和调试器皆会无法响应经过在IDA中分析,以下想法皆为猜测,无法调试验证
KiDebugTrapOrFaultShadow
,但是由于此时的gs并未指向内核数据kpcr
,因此在KiDebugTrapOrFaultShadow
中读取gs寄存器时触发了SMAP(此时gs指向应用层的TEB)
,从而引发双重异常KiDoubleFaultAbortShadow
,但是由于双重异常处理例程中也使用了gs
,再次发生异常,不断重入KiDoubleFaultAbortShadow
导致进入死循环gs
和内核栈
设置完成后下硬件断点,Windbg就可以正常断下原文:https://www.cnblogs.com/DreamoneOnly/p/12779106.html