企业官网建设流程全解析

REA 接入 Ghidra 完整配置指南：从环境变量到第一次二进制分析跑通

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea

拿到一个陌生二进制，想让 AI 把函数逻辑拆明白，REA 能把 Ghidra 这类逆向引擎接到 AI Agent 上替你查证。新手几乎都卡在 Ghidra 配置这一环：版本不对、JDK 装错、首次查询超时。本文按"钉版本、指路径、体检、注册、首查"五步带你跑通。

REA 到底怎么驱动 Ghidra，边界在哪

REA 从不替你下载、安装或升级 Ghidra 和 Java，它只连接并校验你本地已有的安装。分析时，它通过analyzeHeadless（Ghidra 的命令行批处理分析器，不开图形界面就能跑）把目标副本导入一个临时私有工程，挂上自带的 Java 桥取回结果，用完即删。它能做的：26 个只读操作，覆盖清单、搜索、反编译、调用解析。它明确不做的：不碰你原始二进制的字节，不持久化分析数据库，也不替你补齐缺失的环境。

开跑前要钉死哪些版本约束

• Ghidra 只认 12.1.x 系列（官方验证过 12.1.4）。版本号以安装目录里application.properties的声明为准，装别的系列会被直接拒绝。
• JDK 要 21 或更高，没有上限，⚠️ 且必须是 64 位完整版、带javac，精简 JRE 不接受。判断区间以安装目录声明的application.java.min/application.java.max为准。
• 安装目录必须有support/analyzeHeadless（Windows 上是analyzeHeadless.bat），这是 REA 触发无头分析的唯一入口。
• 平台边界：Linux x64、macOS x64/arm64 正式支持，Windows x64 是实验性 P0；macOS 安装必须自带与本机架构匹配的原生反编译器，REA 不会替你构建。
• REA 从不代装任何软件；Linux 上还需 PATH 里有 procps 兼容的ps，供它做进程归属检查。

装好后用两个环境变量告诉 REA 去哪找：

export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.4_PUBLIC export JAVA_HOME=/opt/jdk-21 # java/javac 已在 PATH 时可省略

Windows PowerShell 换成$env:GHIDRA_INSTALL_DIR = "C:\tools\ghidra_12.1.4_PUBLIC"写法即可。指错路径的后果是 doctor 体检全红，不如现在一步到位。

按这个顺序把命令跑完

rea doctor --json

纯只读体检，不改系统任何状态。它逐项核对：平台架构是否支持、Ghidra 应用版本是否 12.1.x、analyzeHeadless是否存在、Java 大版本是否落在声明区间、JDK 是否 64 位、javac是否齐全。

rea setup

把 REA 注册进你选中的 Agent（Claude Code、Codex、Cursor、VS Code 等）并写入 MCP（AI 客户端与工具间通信的协议）配置。动手前它先列完整计划，每条变更逐一审批；写入是原子替换并自动备份，Ctrl-C 随时取消且零改动；验证过的 Ghidra/JDK 路径会保留进客户端配置。

rea providers --json

确认 Ghidra 出现在可用引擎列表里。看不到它，说明前面的路径或版本问题还没解决，先回头跑 doctor。

rea analyze /path/to/binary --provider ghidra --json

发起第一次分析。引擎并存时必须显式带--provider ghidra，否则 REA 不猜，直接报 ambiguous。

怎么判断 Ghidra 配置真正通了

排障单个引擎时用缩小范围的报告更干净：

rea doctor --provider ghidra --json

通过标准四条：版本项显示 12.1.x、analyzeHeadless存在、JDK 位数与大版本过关、javac齐备，全部 healthy 才算对接完成。✅ 之后rea providers --json里有 ghidra、首条rea analyze返回的是 JSON 概览而不是超时错误，整条链路就算跑通了。

首次查询超时怎么恢复，还有哪两个高频坑

坑一：第一次分析客户端先超时。现象：AI 客户端报请求超时，而引擎侧其实还在干活。 原因：冷启动包含导入、自动分析、桥接就绪三段，REA 给引擎启动的上限是 330 秒，但客户端 SDK 默认请求超时往往只有 60 秒，先于引擎截止线断掉。 恢复：SDK 调用里把callTool的请求超时调大（例如 240000 毫秒）；已经超时也没关系，先close_binary关会话，再对同一路径open_binary（带provider_id: "ghidra"）重开，然后重试首查——不先关只重发open_binary不算恢复路径。大目标还可调REA_GHIDRA_STARTUP_TIMEOUT_MS抬高引擎侧上限。

坑二：多引擎并存报 ambiguous。现象：capability_unavailable，selection_reason为ambiguous。 原因：Hopper 和 Ghidra 都支持该目标，你又没指定用哪个。 恢复：三选一——命令行加--provider ghidra、open_binary传provider_id、或设环境变量REA_ANALYSIS_PROVIDER=ghidra钉死。

坑三：doctor 的 Java 项不过。现象：doctor 报 JDK 相关检查 unhealthy。 原因：多为装的是没有javac的 JRE、32 位版本、大版本越界，或 macOS 上 JDK 跑在 Rosetta 模拟下与主机架构不匹配。 恢复：按 Ghidra 声明的区间选 JDK，而不是想装什么装什么，换成匹配的 64 位完整版 JDK，重新指向JAVA_HOME后再跑一次rea doctor --provider ghidra --json。

跑通之后，26 个只读 Ghidra 操作就都在手上了：14 项清单/名称/搜索，12 项函数分析，覆盖反编译、汇编、调用解析、xref（交叉引用：某地址被哪些位置访问的索引）和恢复的数据类型，从"反编译某个函数"到"追一条调用链"直接对话完成。想深入时，setup 变更审阅的完整说明见 docs/installation.md，验证通道与能力边界见 docs/ghidra-provider.md。

【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea