Windows 基于调试器引擎缺陷引发的调试陷阱
本帖最后由 狐白小刺客 于 2021-9-27 11:15 编辑WOW64环境 Windows 10 专业版 19043.1237
众所周知在AMD64环境上，32的程序，我们可以使用CS段切换至x64环境，可以执行x64指令 0x33段选择器（天门） - 恶意软件技术 (malwaretech.com)
当然切换环境后，也是能在调试器里正常工作的，如果手动中断在环境里，调试器引擎可能需要支持x64指令，否则无法正常工作
那么我们正常运行，应该怎么样才能被检测呢, 这就要说个特殊的指令，int3int 3 (KiBreakpointTrap)
为什么说是特殊呢，因为配合切cs可以达到出其不意的效果
在正常环境下 切cs后使用int3，会得到一个STATUS_BREAKPOINT异常，如果没有注册异常接管，会崩溃。
如果在不支持(x64引擎)的调试器里运行，则什么都不会发生，但STATUS_BREAKPOINT异常依旧会有，内核会分发这个异常 但调试器好像不会接收到这个异常，程序正常工作
至于为什么会发生这个情况 一个是调试器汇编引擎的问题，（可能）以及int3的特性 ContextFrame.Rip -= 1; ，两个集中一起就会发生这种情况
当然像ICEBP UD2等指令不会发生这种情况
push 0x33
call Label1
Label1:
add dword , 0x05
retf
int3
call Label2
Label2:
mov dword , 0x00000023
add dword , 0x0D
retf
测试调试器： x32dbg，ollydbg，windbg。 都会引发这种情况
关于反制的方法目前有更换调试器引擎
内核处理要判断cs环境
（SegCs & 0xfff8)== 3 * 16 && WoW64Process != NULL
即可
更新内容：其实就是内核分发异常的时候没有判断wow64执行x64代码，从而没有对齐堆栈地址，引发后续的一系列问题
x64 Rsp =Rsp ;
wow64 Rsp =Rsp & 0xfffffff0UI64;
欢迎评论探究,我只是大概的分析
来自我博客的一篇文章
师傅，我发不了短消息，您看一下我的打招呼内容 十分感谢大佬 十分感谢大佬 谢谢分享 看着很不错，回复一个看看 感谢楼主 感谢楼主 谢谢分享 必火 正好需要谢谢分享啊