静态动态分析闭环Ghidra MCP 集成调试器的断点、单步与ASLR地址转换详解【免费下载链接】ghidra-mcpGhidra MCP Server — 200 MCP tools for AI-powered reverse engineering. GUI plugin headless server, lazy tool loading, convention enforcement, batch operations, Ghidra Server integration, and Docker deployment.项目地址: https://gitcode.com/gh_mirrors/ghi/ghidra-mcpGhidra MCP 是一款为 AI 驱动的逆向工程打造的 MCP 服务器它最大的亮点之一就是把 Ghidra 的静态分析和调试器动态分析接入了同一个工作流。通过debugger_*系列工具AI 可以直接在真实进程中打断点、单步执行、读寄存器与内存并利用 ASLR 感知的静态↔动态地址转换把 Ghidra 里看到的地址和运行时的地址互相翻译——真正做到静态动态分析闭环。 核心关键词速览Ghidra MCP 调试器、断点breakpoint、单步执行step into/over/out、ASLR 地址转换static_to_dynamic / dynamic_to_static、非侵入式函数追踪一、两条调试器工具链按需选择Ghidra MCP 实际上提供了两套独立的调试器工具家族后端不同、平台不同选错会白忙一场工具家族后端适用平台典型工具Java 端 17 个/debugger/*端点Ghidra 原生 TraceRmiWindows 用 dbgeng其他系统用 gdb/lldb需要 GUICodeBrowser 中打开 Window Debuggerdebugger_launch、debugger_step_intoPython 桥 22 个 WinDbg 代理工具独立调试器服务器pybag 封装 dbgeng仅 Windows 可本地运行非 Windows 需指向远程 Windows 主机debugger_attach、debugger_trace_function关键源码位置Java 端点定义DebuggerService.javaMcpToolGroup(value debugger, ...)Python 桥代理层debugger.py两套工具族的使用说明TOOL_USAGE_GUIDE.md平台门控机制Python 桥会根据当前系统决定是否注册这 22 个工具。非 Windows 系统上本地调试器服务器根本跑不起来注册它们只会污染工具列表可用环境变量GHIDRA_DEBUGGER_TOOLS1/0强制开关默认地址在 config.pyGHIDRA_DEBUGGER_URL默认http://127.0.0.1:8099且只允许回环地址防止调试流量被重定向到外部主机。门控逻辑见 _debugger_enabled。二、从静态地址到断点最快配置方法2.1 启动目标进程launchGUI 端推荐流程先debugger_launch_offers列出可用启动器Windows 上通常是 dbgeng其他系统有 gdb local/remote/ssh再debugger_launch(executable_path...)启动目标。值得注意的工程细节debugger_launch返回启动成功并不等于可以查询。实现里会做三层等待直到状态真正就绪launch 方法等待当前 PC 落入目标镜像范围而不是停在 ntdll 等系统 DLL 里主动建立静态↔动态恒等映射addIdentityMapping否则后续static_to_dynamic会报No mapping found轮询模块列表与线程就绪。2.2 打断点支持软件/硬件/一次性Python 桥的debugger_set_breakpoint接受的是Ghidra 静态地址如0x6FD9F450自动翻译成运行时地址再下发支持三种参数组合源码bp_typesoftwareINT3 软断点默认bp_typehardware调试寄存器硬断点不破坏代码oneshottrue命中一次后自动移除配合debugger_list_breakpoints查看、debugger_remove_breakpoint(bp_id)按 ID 删除。Java 端对应debugger_set_breakpoint/debugger_remove_breakpoint/debugger_list_breakpoints源码断点是SW_EXECUTE软件执行断点。三、单步执行step_into / step_over / step_out 怎么选三个单步工具语义与经典调试器一致源码工具行为典型场景debugger_step_into进入函数体想看被调函数内部逻辑debugger_step_over跨过函数体只关心返回值不关心实现debugger_step_out运行到当前函数返回已经钻得太深想快速回到调用者Python 桥版本还支持count参数一次跳多步。⚠️ 新手常见坑连续两次单步偶发报DebuggeeRunningException。这不是 bug而是 Ghidra 的执行状态模型在异步追赶——step_into的 RMI 命令被接受后trace 的 STOPPED 状态还要几毫秒才落地。Ghidra MCP 的实现内置了等待重试机制STEP_SETTLE 常量说明AI 连续下发单步指令时不需要手动 sleep。其他常用控制工具debugger_resume继续、debugger_interrupt中断运行中的目标、debugger_registers读 EAX-EDI/EIP 等寄存器、debugger_read_memory读内存返回 hex dump 32 位 DWORD 解释、debugger_stack_trace调用栈返回地址自动映射为模块偏移。四、ASLR 地址转换详解静态↔动态闭环的核心这是整套调试集成里最有价值的部分。开启 ASLR 后每次运行Game.exe的加载基址都不同Ghidra 里反编译看到的0x6FD9F450和运行时进程里的地址完全对不上。Ghidra MCP 提供双向转换debugger_static_to_dynamic静态地址 → 运行时地址。基于DebuggerStaticMappingService并带最长 10 秒的映射沉降轮询重试源码debugger_dynamic_to_static运行时地址 → 模块偏移。先找到包含该动态地址的模块再算出偏移 动态地址 − 模块基址拿模块名和偏移回 Ghidra 查表即可源码Python 桥这边更进一步debugger_attach附加成功后会自动同步地址映射——它拉取 Ghidra 所有已打开程序的image_base一次性推送给调试器服务器自动同步逻辑。之后debugger_modules就能同时显示每个 DLL 的运行时基址、Ghidra 基址和两者偏移debugger_resolve_ordinal(dll, ordinal)甚至能把 DLL 序号导出直接翻译成两侧地址。一个典型的闭环工作流Ghidra 里静态分析发现可疑函数地址0x6FD9F450debugger_attach附加到运行中的进程自动完成地址映射同步debugger_set_breakpoint(0x6FD9F450, moduleD2Common.dll)— 自动翻译成运行时地址debugger_continue放行命中后debugger_read_args(convention__stdcall, count4)按调用约定读实参debugger_dynamic_to_static把运行时的栈上地址转回 Ghidra 坐标继续静态深挖五、进阶不停机的函数追踪与内存观察点动态分析里最费时的往往是盯着函数等它被调用。Ghidra MCP 的 debugger_trace_function 提供非侵入式追踪命中断点后约 0.5ms 内自动读取参数并恢复执行——对 25fps 的游戏而言完全无感。可指定调用约定、参数个数与名字、是否捕获返回值EAX再用debugger_trace_log读取带时间戳的调用日志。另一杀手锏是 debugger_watch_memory 硬件观察点对某个 Ghidra 地址设 1/2/4 字节的读/写监视受 x86 调试寄存器限制最多 4 个并发用debugger_watch_log查看每次访问的值与访问者地址——这段数据到底被谁改了这类问题一步到位。六、常见问题排查清单现象原因与解法桥的 22 个debugger_*工具不出现非 Windows 系统且GHIDRA_DEBUGGER_URL指向本地需要 Windows 主机运行调试器服务器后把 URL 指向它或设GHIDRA_DEBUGGER_TOOLS1README 说明No mapping found静态映射未建立/未沉降。GUI 端debugger_launch已自动处理手工附加的场景稍等片刻重试或检查模块是否已加载动态地址转换报not in any loaded module目标地址不在任何已加载模块范围内先用debugger_modules确认模块列表与基址debugger_status报 Debugger not activeGUI 端需在 CodeBrowser 中打开 Window DebuggerTraceRmi 为 GUI 专属工具名带_2后缀如debugger_status_2两套工具族撞名仅一方激活时正常双方都激活时后者加后缀README 命名说明小结Ghidra MCP 的调试器集成把逆向工程中最割裂的环节缝合在了一起静态分析给出的每一个地址都能通过static_to_dynamic变成真实进程里的断点运行时的每一个观测值又能通过dynamic_to_static落回 Ghidra 的坐标体系。配合 AI 自动下发单步、读参、追踪指令静态假设 → 动态验证 → 回到静态沉淀结论的闭环第一次真正跑通了。建议从 TOOL_USAGE_GUIDE.md 的 debugger 章节 开始按平台选对工具家族再对照本文的闭环工作流上手。【免费下载链接】ghidra-mcpGhidra MCP Server — 200 MCP tools for AI-powered reverse engineering. GUI plugin headless server, lazy tool loading, convention enforcement, batch operations, Ghidra Server integration, and Docker deployment.项目地址: https://gitcode.com/gh_mirrors/ghi/ghidra-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
静态动态分析闭环Ghidra MCP 集成调试器的断点、单步与ASLR地址转换详解【免费下载链接】ghidra-mcpGhidra MCP Server — 200 MCP tools for AI-powered reverse engineering. GUI plugin headless server, lazy tool loading, convention enforcement, batch operations, Ghidra Server integration, and Docker deployment.项目地址: https://gitcode.com/gh_mirrors/ghi/ghidra-mcpGhidra MCP 是一款为 AI 驱动的逆向工程打造的 MCP 服务器它最大的亮点之一就是把 Ghidra 的静态分析和调试器动态分析接入了同一个工作流。通过debugger_*系列工具AI 可以直接在真实进程中打断点、单步执行、读寄存器与内存并利用 ASLR 感知的静态↔动态地址转换把 Ghidra 里看到的地址和运行时的地址互相翻译——真正做到静态动态分析闭环。 核心关键词速览Ghidra MCP 调试器、断点breakpoint、单步执行step into/over/out、ASLR 地址转换static_to_dynamic / dynamic_to_static、非侵入式函数追踪一、两条调试器工具链按需选择Ghidra MCP 实际上提供了两套独立的调试器工具家族后端不同、平台不同选错会白忙一场工具家族后端适用平台典型工具Java 端 17 个/debugger/*端点Ghidra 原生 TraceRmiWindows 用 dbgeng其他系统用 gdb/lldb需要 GUICodeBrowser 中打开 Window Debuggerdebugger_launch、debugger_step_intoPython 桥 22 个 WinDbg 代理工具独立调试器服务器pybag 封装 dbgeng仅 Windows 可本地运行非 Windows 需指向远程 Windows 主机debugger_attach、debugger_trace_function关键源码位置Java 端点定义DebuggerService.javaMcpToolGroup(value debugger, ...)Python 桥代理层debugger.py两套工具族的使用说明TOOL_USAGE_GUIDE.md平台门控机制Python 桥会根据当前系统决定是否注册这 22 个工具。非 Windows 系统上本地调试器服务器根本跑不起来注册它们只会污染工具列表可用环境变量GHIDRA_DEBUGGER_TOOLS1/0强制开关默认地址在 config.pyGHIDRA_DEBUGGER_URL默认http://127.0.0.1:8099且只允许回环地址防止调试流量被重定向到外部主机。门控逻辑见 _debugger_enabled。二、从静态地址到断点最快配置方法2.1 启动目标进程launchGUI 端推荐流程先debugger_launch_offers列出可用启动器Windows 上通常是 dbgeng其他系统有 gdb local/remote/ssh再debugger_launch(executable_path...)启动目标。值得注意的工程细节debugger_launch返回启动成功并不等于可以查询。实现里会做三层等待直到状态真正就绪launch 方法等待当前 PC 落入目标镜像范围而不是停在 ntdll 等系统 DLL 里主动建立静态↔动态恒等映射addIdentityMapping否则后续static_to_dynamic会报No mapping found轮询模块列表与线程就绪。2.2 打断点支持软件/硬件/一次性Python 桥的debugger_set_breakpoint接受的是Ghidra 静态地址如0x6FD9F450自动翻译成运行时地址再下发支持三种参数组合源码bp_typesoftwareINT3 软断点默认bp_typehardware调试寄存器硬断点不破坏代码oneshottrue命中一次后自动移除配合debugger_list_breakpoints查看、debugger_remove_breakpoint(bp_id)按 ID 删除。Java 端对应debugger_set_breakpoint/debugger_remove_breakpoint/debugger_list_breakpoints源码断点是SW_EXECUTE软件执行断点。三、单步执行step_into / step_over / step_out 怎么选三个单步工具语义与经典调试器一致源码工具行为典型场景debugger_step_into进入函数体想看被调函数内部逻辑debugger_step_over跨过函数体只关心返回值不关心实现debugger_step_out运行到当前函数返回已经钻得太深想快速回到调用者Python 桥版本还支持count参数一次跳多步。⚠️ 新手常见坑连续两次单步偶发报DebuggeeRunningException。这不是 bug而是 Ghidra 的执行状态模型在异步追赶——step_into的 RMI 命令被接受后trace 的 STOPPED 状态还要几毫秒才落地。Ghidra MCP 的实现内置了等待重试机制STEP_SETTLE 常量说明AI 连续下发单步指令时不需要手动 sleep。其他常用控制工具debugger_resume继续、debugger_interrupt中断运行中的目标、debugger_registers读 EAX-EDI/EIP 等寄存器、debugger_read_memory读内存返回 hex dump 32 位 DWORD 解释、debugger_stack_trace调用栈返回地址自动映射为模块偏移。四、ASLR 地址转换详解静态↔动态闭环的核心这是整套调试集成里最有价值的部分。开启 ASLR 后每次运行Game.exe的加载基址都不同Ghidra 里反编译看到的0x6FD9F450和运行时进程里的地址完全对不上。Ghidra MCP 提供双向转换debugger_static_to_dynamic静态地址 → 运行时地址。基于DebuggerStaticMappingService并带最长 10 秒的映射沉降轮询重试源码debugger_dynamic_to_static运行时地址 → 模块偏移。先找到包含该动态地址的模块再算出偏移 动态地址 − 模块基址拿模块名和偏移回 Ghidra 查表即可源码Python 桥这边更进一步debugger_attach附加成功后会自动同步地址映射——它拉取 Ghidra 所有已打开程序的image_base一次性推送给调试器服务器自动同步逻辑。之后debugger_modules就能同时显示每个 DLL 的运行时基址、Ghidra 基址和两者偏移debugger_resolve_ordinal(dll, ordinal)甚至能把 DLL 序号导出直接翻译成两侧地址。一个典型的闭环工作流Ghidra 里静态分析发现可疑函数地址0x6FD9F450debugger_attach附加到运行中的进程自动完成地址映射同步debugger_set_breakpoint(0x6FD9F450, moduleD2Common.dll)— 自动翻译成运行时地址debugger_continue放行命中后debugger_read_args(convention__stdcall, count4)按调用约定读实参debugger_dynamic_to_static把运行时的栈上地址转回 Ghidra 坐标继续静态深挖五、进阶不停机的函数追踪与内存观察点动态分析里最费时的往往是盯着函数等它被调用。Ghidra MCP 的 debugger_trace_function 提供非侵入式追踪命中断点后约 0.5ms 内自动读取参数并恢复执行——对 25fps 的游戏而言完全无感。可指定调用约定、参数个数与名字、是否捕获返回值EAX再用debugger_trace_log读取带时间戳的调用日志。另一杀手锏是 debugger_watch_memory 硬件观察点对某个 Ghidra 地址设 1/2/4 字节的读/写监视受 x86 调试寄存器限制最多 4 个并发用debugger_watch_log查看每次访问的值与访问者地址——这段数据到底被谁改了这类问题一步到位。六、常见问题排查清单现象原因与解法桥的 22 个debugger_*工具不出现非 Windows 系统且GHIDRA_DEBUGGER_URL指向本地需要 Windows 主机运行调试器服务器后把 URL 指向它或设GHIDRA_DEBUGGER_TOOLS1README 说明No mapping found静态映射未建立/未沉降。GUI 端debugger_launch已自动处理手工附加的场景稍等片刻重试或检查模块是否已加载动态地址转换报not in any loaded module目标地址不在任何已加载模块范围内先用debugger_modules确认模块列表与基址debugger_status报 Debugger not activeGUI 端需在 CodeBrowser 中打开 Window DebuggerTraceRmi 为 GUI 专属工具名带_2后缀如debugger_status_2两套工具族撞名仅一方激活时正常双方都激活时后者加后缀README 命名说明小结Ghidra MCP 的调试器集成把逆向工程中最割裂的环节缝合在了一起静态分析给出的每一个地址都能通过static_to_dynamic变成真实进程里的断点运行时的每一个观测值又能通过dynamic_to_static落回 Ghidra 的坐标体系。配合 AI 自动下发单步、读参、追踪指令静态假设 → 动态验证 → 回到静态沉淀结论的闭环第一次真正跑通了。建议从 TOOL_USAGE_GUIDE.md 的 debugger 章节 开始按平台选对工具家族再对照本文的闭环工作流上手。【免费下载链接】ghidra-mcpGhidra MCP Server — 200 MCP tools for AI-powered reverse engineering. GUI plugin headless server, lazy tool loading, convention enforcement, batch operations, Ghidra Server integration, and Docker deployment.项目地址: https://gitcode.com/gh_mirrors/ghi/ghidra-mcp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
