WinDbg如何对Qiling模拟环境中偏移不同的地址设置断点

问题根因说明 #

你遇到的两个核心问题本质独立，先做拆解：

1. Qiling模拟失败的直接原因是你运行的snake.exe是托管.NET程序，依赖mscoree.dll导出的_CorExeMain入口初始化CLR运行时，Qiling的Windows根文件系统默认未实现该托管程序启动API，直接执行就会触发内存访问异常。
2. WinDbg断点不生效的原因是你混淆了Qiling模拟环境和本地Windows的地址空间：
   • Qiling是用户态模拟器，会强制按PE优选基址加载模块，所以snake.exe固定加载到0x400000，入口点就是0x4033ae
   • 本地Windows开启了ASLR，你的snake.exe实际加载基址是0x00e60000（从WinDbg的ModLoad日志可查），和Qiling的0x400000完全不一致，所以直接对0x4033ae下断根本无法命中；且你看到的初始int3断点是系统调试器的初始断点，此时程序入口点确实已经执行完成。

解决步骤 #

方案1：优先修复Qiling模拟问题（推荐，无需调整WinDbg逻辑） #

• 给_CorExeMain添加Qiling模拟钩子：Qiling框架支持自定义未实现API的Hook逻辑，你可以直接给该API返回符合预期的执行结果，或者自行实现逻辑跳过CLR初始化（如果你的程序逻辑可剥离托管依赖的话）。
• 如果要调试Qiling内部的执行流程，直接使用Qiling自带的调试接口或GDB远程调试即可，不需要使用WinDbg：Qiling本身支持挂载GDB stub，你可以直接在GDB中对0x4033ae下断，地址和模拟环境完全匹配。

方案2：在本地WinDbg中设置有效断点 #

• 先计算入口点RVA：Qiling中snake.exe的加载基址是0x400000，入口点是0x4033ae，因此入口点RVA为0x4033ae - 0x400000 = 0x33ae。
• 等WinDbg中目标程序加载完成后，用lm m [模块名]获取本地加载基址（你的日志中显示模块名是ConsoleGraphics.exe，按实际名称调整即可），比如你日志里的基址是0x00e60000，那么实际入口地址就是0x00e60000 + 0x33ae = 0x00e633ae，对这个地址下断即可命中。
• 也可以直接用bu [模块名]!EntryPoint或者bu $exentry直接对程序入口点下断，不需要手动计算地址，WinDbg会自动匹配加载基址计算正确的虚拟地址。

额外注意点 #

你本地WinDbg加载的是32位版本的mscoree.dll（路径为SysWOW64），说明你本地启动的是32位版本的程序，而Qiling模拟的是x86_64环境，两边架构不一致也会导致地址、指令逻辑完全不同，调试时需要保证两边架构统一，要么都用32位要么都用64位。

内容的提问来源于stack exchange，提问作者J.Todd