Windows 基于调试器引擎缺陷引发的调试陷阱

音乐之家1

众所周知在AMD64情况上，32的程序，我们可以利用CS段切换至x64情况，可以实行x64指令 0x33段选择器（天门） - 恶意软件技能 (malwaretech.com)

当然切换情况后，也是能在调试器里正常工作的，如果手动中断在情况里，调试器引擎可能需要支持x64指令，否则无法正常工作

那么我们正常运行，应该怎么样才能被检测呢, 这就要说个特殊的指令，int3  int 3 (KiBreakpointTrap)

为什么说是特殊呢，因为配合切cs可以达到出其不意的效果

在正常情况下 切cs后利用int3，会得到一个STATUS_BREAKPOINT异常，如果没有注册异常接管，会瓦解。

如果在不支持(x64引擎)的调试器里运行，则什么都不会发生，但STATUS_BREAKPOINT异常依旧会有，内核会分发这个异常 但调试器好像不会吸收到这个异常，程序正常工作

至于为什么会发生这个情况 一个是调试器汇编引擎的题目，（可能）以及int3的特性 ContextFrame.Rip -= 1; ，两个集中一起就会发生这种情况

当然像ICEBP UD2等指令不会发生这种情况

[Asm] 纯文本检察 复制代码push 0x33call Label1Label1:add dword [esp], 0x05retf int3 call Label2Label2:mov dword [esp+0x04], 0x00000023add dword [esp], 0x0Dretf

测试调试器： x32dbg，OllyDbg，windbg。 都会引发这种情况

关于反制的方法目前有更换调试器引擎
内核处理要判断cs情况
（SegCs & 0xfff8)== 3 * 16 && WoW64Process != NULL
即可

更新内容：其实就是内核分发异常的时间没有判断wow64实行x64代码，从而没有对齐堆栈地点，引发后续的一系列题目
x64 Rsp =Rsp ;
wow64 Rsp =Rsp & 0xfffffff0UI64;


接待评论探究,我只是大概的分析

来自我博客的一篇文章
来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！