找到Ghidra没发现的代码Ghidra MCP 孤立代码发现与死代码分析实战【免费下载链接】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使用Ghidra MCP Server做 AI 辅助逆向时最让人头疼的问题之一就是自动分析看着很满其实还有函数藏在函数与函数之间的空隙里。这个项目提供了 200 MCP 工具和一批专用 Ghidra 脚本能系统性地发现孤立代码orphaned code并做死代码分析——本文带你走一遍完整流程从扫描代码空隙、识别被漏掉的函数到标记、创建、复查直到确认哪些代码真的是死代码。为什么 Ghidra 会自动漏掉代码Ghidra 的自动分析依赖引用关系xref驱动。以下场景经常让真实函数隐身编译器优化或异常跳转分析器在无条件JMP后停止JMP 之后的合法代码变成未定义区域填充字节padding函数之间插入CCINT3/90NOP对齐后面的函数入口没被任何调用指向冷门函数序言prologue不是PUSH EBP; MOV EBP, ESP的标准开头分析器无法猜测函数边界这些被漏掉的代码块就是本文要抓的孤立代码。第一步用 find_code_gaps 圈出所有可疑空隙Ghidra MCP 的find_code_gaps工具专门干这件事它计算可执行内存 − 所有函数体的差集把每一段未被任何函数覆盖的连续区域都列出来并告诉你空隙的起止地址和大小空隙里是否有未定义字节、是否已有孤立指令已反汇编但没划进任何函数空隙两侧最近的函数方便你判断上下文工具定义见 AnalysisService.java支持min_size过滤对齐填充、offset/limit分页。对固件、嵌入式二进制尤其有用——这类程序里被漏掉的函数比例往往最高。拿到空隙列表后先别急着创建函数用inspect_memory_content或disassemble_bytes预览内容再决定下一步。第二步三遍扫描给每个候选自动定性项目内置的 Analyze_FindOrphanedCode.java 是最核心的孤立代码发现脚本。它对每段空隙执行三遍扫描并按置信度分类遍次检查方式典型命中置信度Pass 1已反汇编但不在任何函数内的指令Ghidra 分析过但没建函数边界的真函数高Pass 2原始字节匹配已知函数序言PUSH EBP、SUB ESP、MOVSX等 20 多种模式未反汇编的标准函数中-高Pass 3兜底非填充字节 存在RET的序列序言未知的代码需人工复核脚本的亮点在于防误报设计数据表过滤如果空隙内 50% 以上的 4 字节对齐值都落在程序映像范围内判定为跳转表/地址表直接跳过填充字节识别CC/90/00组成的纯填充空隙直接过滤MULTI-RET 标记一段空隙里发现多个RET说明可能挤着好几个小函数创建第一个后重新扫描空隙会自动分裂配套的工作流提示词在 ORPHANED_CODE_DISCOVERY_WORKFLOW.md把候选分成 A~G 七类导入跳板、已反汇编真函数、标准序言、被调用者保存序言、异常开头、getter/薄封装、未知序言每类都给出明确的处置策略和优先级。第三步创建函数 自动挂分诊注释确认候选后通过create_function建函数脚本会自动补一条分诊平板注释triage plate comment记录类型、置信度、大小、相邻函数等信息供后续完整文档化流程接手。所有创建操作包在 Ghidra 事务里失败自动回滚不会把工程搞脏。脚本还支持项目级批量处理常用参数--dry-run只扫描不写入先看结果--max-passesN迭代扫描轮数建完函数后边界会变化默认 5 轮--all-programs/--folderPATH扫描整个项目或指定目录--min-sizeN过滤过小候选补充武器填充字节扫描与死代码分析填充字节后的函数是另一类常见漏网之鱼。Analyze_FindFunctionsAfterPadding.java 专门扫描连续 ≥3 个填充字节 后面紧跟合法函数开头的模式并且要求填充前必须有RET指令——确保你确实站在上一个函数的结尾而不是数据区的随机字节。死代码分析则从引用关系入手Analyze_ZeroXrefScanner.java 遍历所有函数列出零交叉引用的函数按大小排序 大小分布统计快速定位没人调用的代码。注意零 xref ≠ 一定无用导出函数、虚函数、动态调用目标都可能看起来没引用需要结合get_xrefs_to人工确认MCP 工具find_dead_codeendpoints.json 中定义用于识别不可达代码块当前为占位实现正式的可达性分析基于控制流图还在路线图上完整实战流程5 步选定范围当前二进制、版本目录还是整个项目扫描先跑find_code_gaps看全局再用Analyze_FindOrphanedCode的--dry-run预览分诊按 A~G 类型逐类处理高置信度Pass 1/Pass 2 标准序言优先REVIEW类必须先反汇编预览批量创建每批 5~10 个创建后抽查 1~2 个反编译结果确认代码连贯迭代复查重新扫描一次——创建函数会移动边界第二轮常能再挖出新候选通常 2 轮即可收敛常见坑位清单 ⚠️共享尾声某些编译器让相邻函数共用POP; RET结尾强行在共享块上建函数会触发重叠错误——脚本遇到此类错误会自动跳过switch 表.text 段里的数据表反汇编后看起来像代码用get_xrefs_to验证只被单个函数的 switch 分发引用就是 case 块非连续函数体函数体若跨两段地址中间空隙可能属于该函数本身建函数前先查 xref00填充的误报00 00开头的空隙极少是真实代码但Analyze_FindFunctionsAfterPadding已默认排除00字节以避免数据区误报总结与资源索引Ghidra MCP 把孤立代码发现 死代码分析做成了可重复、可批量、防误报的流程find_code_gaps圈范围 → 三遍扫描定性 → 自动创建与分诊 → 迭代复查。对大型遗留二进制、多版本对比、固件逆向这套流程能显著减少明明有代码却没人知道的盲区。核心脚本Analyze_FindOrphanedCode.java、Analyze_FindFunctionsAfterPadding.java、Analyze_ZeroXrefScanner.java工作流提示词ORPHANED_CODE_DISCOVERY_WORKFLOW.md服务端实现AnalysisService.java/find_code_gaps、/find_dead_code端点全部工具清单endpoints.json 与 README.md部署方式GUI 插件 / 无头服务器 / Docker见 docker/ 目录更多 Ghidra 脚本用法可参考 ghidra_scripts/README.md。【免费下载链接】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），仅供参考
