REA 的 Ghidra 一致性语料：用源码托管的 C 夹具验证 ELF、PE 与 Mach-O 语义事实

逆向工程MCP 服务AI 技能【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址https://gitcode.com/GitHub_Trending/rea2/rea点击查看免费下载本文以tests/conformance/ghidra/README.md为核心讲解 REAReverse Engineer Anything仓库中 Ghidra 一致性语料的设计与运行方式inventory.c与cross-format.c两个源码夹具如何覆盖导入、回调、字符串、CFG 等语义面验证器scripts/verify-real-ghidra.mjs如何在“自带 Ghidra 12.1.4”BYO Ghidra环境下逐目标比对语义事实并保证零残留清理。读完本文你可以完整复现该一致性验证泳道lane并理解 REA 为何用“语义事实比对”而非“反编译文本比对”来衡量反汇编/反编译 Provider 的正确性。一、语料定位源码即 Oracle二进制永不入库tests/conformance/ghidra/README.md 开篇即给出 Ghidra 一致性语料的总原则These source-owned fixtures are compiled at verification time; generated binaries and Ghidra projects are never committed.这些源码托管的夹具在验证时刻编译生成的二进制与 Ghidra 工程永不提交。这句话是整个语料的灵魂包含三层含义夹具是“语义 Oracle”。期望值哪些函数、哪些调用边、哪些字符串由 C 源码本身决定而不是由 REA 或 Ghidra 的历史运行结果反推。这样即使 Provider 行为漂移夹具也不会跟着漂移。编译发生在验证时刻。仓库只版本化.c源文件ELF/PE/Mach-O 产物、Ghidra 工程目录全部在验证时生成于临时目录验证结束即删除。这保证了跨平台 CI 与本地验证看到的是同一份语义而不是某台机器上冻结的二进制。验证是“只读分析”契约的证明。Ghidra 会话以只读方式打开夹具不导入修改数据库一致性比对的是分析产物函数、调用、引用、字符串、CFG而非可执行行为。上层 tests/conformance/README.md 进一步说明了这批夹具在整体测试体系中的位置npm run verify:fixtures在 macOS/Linux 上把可移植夹具编译到被忽略的build/conformance/目录并生成哈希与工具链清单而ghidra/inventory.c会被npm run verify:ghidra额外编译为临时的 debug 与 stripped 变体用来固定“本地函数、外部puts链接、已定义字符串”为只读的 Ghidra 清单inventory契约提供证明基础。对应到 package.json 中的脚本入口verify:ghidra: npm run build:cached node scripts/verify-real-ghidra.mjs, verify:ghidra:cross-format: npm run build:cached node scripts/verify-real-ghidra.mjs --cross-format, verify:ghidra:aarch64-jump-table: npm run build:cached node scripts/verify-real-ghidra.mjs --aarch64-jump-table即同一条验证泳道有三个变体宿主原生host-native、跨格式cross-format、AArch64 跳转表专项。二、inventory.c单个二进制要覆盖的语义面清单inventory.c的职责由 README 明确列出它产生分离的 x86-64 debug 与 stripped ELF 可执行文件覆盖导入imports、外部puts函数、链接器 thunk、源码符号、直接调用、无目标的回调调用targetless callback call、两个被引用字符串、以及多块分支multi-block branch。对照 tests/conformance/ghidra/inventory.c 源码这些语义面是这样被精确“埋”进去的外部puts与导入/thunkL15-L18 的lea_ghidra_inventory_leaf调用puts(REA_GHIDRA_LEAF_VALUE)L103-L108 的lea_ghidra_inventory_entry再调puts(REA_GHIDRA_INVENTORY_ENTRY)。在 Linux x86-64 上这产生两个字符串引用README 所说“two referenced strings”、puts的 PLT 导入以及调用点经 PLT thunk 跳转的链路——正是清单类分析list_procedures、list_names、调用边解析需要正确呈现的形态。源码符号与类型布局文件头部的volatile int lea_ghidra_inventory_global、枚举/联合/结构体布局L3-L13为符号表与类型信息提供断言目标。验证器还会把同一源文件单独编译为-gdwarf-4的目标文件lea-ghidra-layout.o作为type-layout变体专门校验类型/名称类事实见 scripts/verify-real-ghidra.mjs 中的layoutPath编译步骤。直接调用与多块分支lea_ghidra_inventory_branchL20-L25是一个if (value 10)双分支函数两条路径都落在同一叶函数上构成“多块 CFG”lea_ghidra_inventory_entry则串联branch、indirect、dense_switch形成已知调用链可被逐边比对。无目标回调targetless callbacklea_ghidra_inventory_indirect(int (*callback)(int), int value)L27-L30对函数指针参数直接callback(value)。在静态分析视角下这条调用边没有可解析目标——这正是 README 强调的关键契约“callback fixture 同时证明一个未解析的、无目标的流不会被静默提升为直接被调者callee”。即正确行为是保留为“间接/未知目标”而不是臆造一个 callee。稠密 switch 与跳转表lea_ghidra_inventory_dense_switchL56-L101含 0–39 共 40 个 case足以让编译器生成绝对 8 字节项的跳转表验证脚本会再调用仓库自带的inspect-native-apiCLI 对该函数做跳转表边界断言40 个 case 映射、default 目标、置信度high、residual_unknowns为空见 scripts/verify-real-ghidra.mjs 的verifyNativeApiCli。可执行自检main返回lea_ghidra_inventory_entry() 49 ? 0 : 1L110保证夹具自身语义自洽35 分支 间接 default 分支 1 49任何编译器行为漂移都会让夹具本身失效验证随之失败。debug 与 stripped 双变体的意义debug 变体带符号与调试信息stripped 变体编译参数追加-sMach-O 宿主再加-fvisibilityhidden见 scripts/verify-real-ghidra.mjs逼迫分析器仅凭反汇编推断函数划分与调用结构。同一语义在“有符号”与“无符号”两种条件下都应给出一致的事实函数分类、调用边、字符串/xref这就是assertDebugFixture/assertStrippedFixture分别断言的原因。三、cross-format.c同一语义跨越三种加载器cross-format.c的 README 描述是freestanding无标准库设计使验证器能从同一语义产出 AArch64 ELF、x86-64 PE、x86-64 Mach-O 三种目标并在不同加载器loader之间保持导出入口、直接/间接调用、易变volatile字符串引用与多块分支。源码 tests/conformance/ghidra/cross-format.c 的关键设计freestanding 与导出入口lea_cross_entry用__attribute__((used, visibility(default)))L76-L78保证跨格式导出lea_cross_startL80-L85作为程序入口执行一次入口调用后进入for(;;){}为无 libc 环境提供终止语义。易变字符串引用const volatile char lea_cross_message[] REA_GHIDRA_CROSS_FORMATL4被lea_cross_leaf以lea_cross_message[0] - R方式引用L7。volatile防止编译器在-O2AArch64 目标用-O2下把字符串访问常量折叠掉保证字符串/xref 事实在三种格式中都真实存在。直接 间接调用lea_cross_indirect(rea_cross_callback callback, int value)与 inventory 的回调夹具同构继续承担“无目标流不提升为直接 callee”的证明lea_cross_entry同时覆盖直接调用与函数指针调用两条边。宏展开的稠密 switchlea_cross_dense_switch用REA_CROSS_SWITCH_CASE宏展开 0–39 的 caseL22-L72保证跳转表夹具不依赖手写重复代码。验证器在--cross-format泳道下对三个目标的构建命令摘自 scripts/verify-real-ghidra.mjs目标命令要点加载器/格式rea-ghidra-cross-arm64clang --targetaarch64-linux-gnu -O2 -g -fno-inline -fno-pie -nostdlib -static -fuse-ldlld -Wl,-e,lea_cross_startAArch64 ELF静态、入口显式指定rea-ghidra-cross-x86_64.execlang --targetx86_64-pc-windows-msvc -O0 -gcodeview -fno-inline -c后lld-link /entry:lea_cross_start /subsystem:console /nodefaultlib /export:lea_cross_entry /implib:...libx86-64 PE入口与导出双显式rea-ghidra-cross-x86_64.oclang --targetx86_64-apple-darwin -O0 -g -fno-inline -cx86-64 Mach-O 目标文件三个目标随后逐一进入verifyTargetassertCrossFixture对非专项变体断言同一组语义事实从而证明语义比对是与加载器无关的——ELF 的.rodata、PE 的节布局、Mach-O 的段结构不应改变“同一调用边、同一字符串引用、同一分支拓扑”的结论。四、验证器与 Ghidra 环境契约4.1 BYO Ghidra 12.1.4 与版本承诺README 规定验证器“要求通过GHIDRA_INSTALL_DIR指定经过验证的自带 Ghidra 12.1.4 安装”。scripts/verify-real-ghidra.mjs 实现了这条硬性契约GHIDRA_INSTALL_DIR未设置或不是绝对路径时直接抛错Set GHIDRA_INSTALL_DIR to the absolute root of an extracted Ghidra 12.1.4 release.L47-L50通过inspectGhidraInstallation检查安装可用性并定位analyzeHeadless入口JAVA_HOME可选覆盖安装版本不等于SUPPORTED_GHIDRA_VERSION时抛Ghidra provider version commitment driftedL64-L65。这里有一个重要的版本分层README 原文“Provider admission accepts the rest of the 12.1.x line; this lane does not”REA 的 Provider 准入逻辑接受 12.1.x 整条版本线但这条一致性验证泳道只承诺 12.1.4。也就是说用户侧可以用 12.1.x 的其他小版本运行 REA而仓库的一致性结论只对精确版本 12.1.4 负责——版本承诺version commitment与准入范围admission range被刻意分离SUPPORTED_GHIDRA_VERSION定义于 Ghidra 模块并在 src/ghidra/GhidraInstallation.ts 中统一再导出。4.2 工具链选择与预检README 说明验证器默认使用cc、clang、lld-link可用REA_CC、REA_CLANG、REA_LLD_LINK选择替代命令。scripts/verify-real-ghidra.mjs 中对应的读取逻辑还包含REA_LLDLLVM LLD 链接器ld.lldcross-format 泳道静态链接 AArch64 ELF 时使用const compiler process.env.REA_CC ?? cc; const clang process.env.REA_CLANG ?? clang; const lld process.env.REA_LLD ?? ld.lld; const lldLink process.env.REA_LLD_LINK ?? lld-link;每个参与的工具都会先做预检--versionlld-link用/?不可用即报“required is unavailable or failed its preflight” L110-L119。这意味着跨格式泳道对宿主环境的要求是主机编译器cc 带三平台目标的clangld.lldlld-linkLLVM 工具链。4.3 头部分类先于 Provider 启动README 的 “validates header classification before starting the provider” 对应 verifyTarget 的严格顺序parseBinaryTarget(targetPath)先对文件做头部分类解析出格式elf/pe/mach-o与架构并与该变体的期望目标比对漂移即抛Fixture header classification driftedresolveGhidraAnalysisProfile基于解析结果与 Ghidra Provider 身份提交分析档案profile与摘要digest仅在前两步都成功后才构造GhidraClient并启动 headless 进程桥接脚本固定为仓库内的 bridge/ghidra/ReaGhidraBridge.java。另外验证器还会写入一个伪二进制not-a-binary\nlea-ghidra-malformed并断言rejected-before-provider-startL241 与 L283非法目标必须在 Provider 启动之前被头部分类拒绝而不是把错误推给 Ghidra。4.4 每目标独立工程与零残留清理README 最后一条“Every target runs in a separate owned project and must leave no process, socket, project, or runtime root after close.” 在脚本中verifyTarget的finally块保证无论断言成败都会client.close()随后assertCleanup(runtimeCoordinates)核对进程、套接字、Ghidra 工程与运行时根目录均已消失L540-L544整个夹具根目录mkdtemp(join(tmpdir(), rea-ghidra-fixtures-))也在最外层finally中递归删除L292-L294。会话身份profile digest、目标 SHA-256在start与ping两次往返中各校验一遍assertSession确保分析会话始终绑定到“这一个文件 这一个档案”。五、一致性比对了什么语义事实清单README 对“一致性”的定义是本语料的方法论核心Conformance compares semantic facts: provider/profile identity, function classification, resolved call edges, typed references, strings/xrefs, and CFG topology.结合 scripts/verify-real-ghidra.mjs 中对会话的实际操作list_documents、list_segments、list_procedures、list_names、list_strings全量拉取语义事实可归纳为事实类别夹具埋点断言方式Provider/Profile 身份会话启动assertSession校验 profile digest 与目标 SHA-256L462-L475函数分类全部__attribute__((noinline, used))函数debug/stripped/cross 各变体的assertDebugFixture/assertStrippedFixture/assertCrossFixture已解析调用边entry → branch/dense_switch/leaf、indirect(callback)直接调用逐边比对回调边必须保持“无目标”而非被提升为直接 callee带类型引用结构体/联合/枚举布局、回调指针参数type-layout变体的verifyNativeTypeLayout字符串与 xrefREA_GHIDRA_LEAF_VALUE、REA_GHIDRA_INVENTORY_ENTRYinventoryREA_GHIDRA_CROSS_FORMATcross-formatlist_strings与引用点比对CFG 拓扑branch的多块分支、switch 跳转表控制流块与跳转表映射含 40 case 的inspect-native-api断言而反编译伪代码与汇编只要求“非空、有界、携带地址”non-empty, bounded, and address-bearingREADME 明确 “It never compares their text with Hopper”。从设计角度看这是刻意规避把断言耦合到某个反编译器的措辞风格上——Ghidra 与 Hopper 的伪代码文本永远不会逐字相同但函数边界、调用解析、引用完整性这类可判定语义事实应该跨 Provider 一致。这也是 REA 作为多 ProviderGhidra/Hopper/IDA…统一分析层在测试策略上的自洽之处一致性语料验证“事实层”而不验证“表述层”。六、相邻夹具与完整验证泳道tests/conformance/ghidra/目录除 README 与两个 C 夹具外还包含同属 Ghidra 一致性语料的专项成员与 package.json 中的脚本一一对应switch-fixture.mjs以“源码拥有的 case/目标标签”注释原文Source-owned case/target labels; no REA or Ghidra result defines this oracle生成 6 类 switch 夹具稠密、带空洞、非零基址、负值、比较对照、unsigned long long非安全整数并用nm符号表 ELF 段表把每个跳转表槽位与源码块标签逐一核对——对应verify:ghidra:switch泳道relative-switch.S手写 AArch64 汇编构造 1/2 字节表项、相对目标地址的跳转表br x10adr/adrp基址对应--aarch64-jump-table专项dos-mz-fixture.mjs 与 dos-com-fixture.mjs纯字节级构造的 16 位 DOS MZ/COM 夹具源码注释强调“REA never executes this code”对应verify:ghidra:dos/verify:ghidra:comReaSwitchEvidenceProbe.java在 Ghidra 脚本运行时中通过反射驱动生产桥接 bridge/ghidra/ReaGhidraBridge.java 的类型化跳转表证据方法用固定模型对象核对 case 值解析、冲突回撤、unknown 目标保留等私有行为Windows P0 泳道tests/conformance/README.md 说明scripts/create-ghidra-windows-fixture.mjs会生成一个确定性的原生 x86-64 PE生成器与固定 SHA-256 入库.exe永不提交或执行verify:ghidra:windows在自建真机 Ghidra runner 上验证全部 19 个操作、摘要链接、传输与清理。七、如何运行这条泳道前提与限制复现 Ghidra 一致性验证的最小环境解压一份Ghida 12.1.4注意泳道承诺的是 12.1.4非整条 12.1.x 线设置GHIDRA_INSTALL_DIR为其绝对路径根目录如需指定 Java可另设JAVA_HOME。确保cc、clang、ld.lldcross-format 需要、lld-linkPE 目标需要在 PATH 中且通过预检如安装位置不同用REA_CC/REA_CLANG/REA_LLD/REA_LLD_LINK覆盖。运行宿主原生泳道npm run verify:ghidraLinux x64 或 macOS x64/arm64 宿主见 nativeFixtureTarget 的支持矩阵跨格式泳道npm run verify:ghidra:cross-formatAArch64 跳转表专项npm run verify:ghidra:aarch64-jump-table。成功判据脚本输出 JSON 报告含ok: true、每个夹具变体的summary、malformed_target: rejected-before-provider-start、cleanup: complete且全部断言通过任何语义事实漂移、版本承诺漂移或清理残留都会使验证以异常结束。需要注意的适用前提验证器会真实拉起 Ghidra headless 进程并启动 JVM因此它属于重集成验证不是单元测试夹具编译标志固定为-O0 -g -fno-inlineELF 宿主追加-fno-pie -no-pieAArch64 cross 目标用-O2 -nostdlib -static编译器优化行为的变化如跳转表编码改变会直接触发断言失败——这正是夹具“编译器行为假设显式化”的代价与收益假设漂移时立刻可见。八、小结REA 的 Ghidra 一致性语料用一个朴素但严谨的思路解决了“如何验收反汇编 Provider”的问题用两个源码托管的 C 夹具inventory.c单格式、cross-format.c三格式在验证时刻编译出语义已知的 ELF/PE/Mach-O 目标在严格固定的 12.1.4 环境、独立 Ghidra 工程与头部预检之下逐条比对函数分类、调用边、引用、字符串/xref 与 CFG 拓扑对伪代码只要求结构化存在性对会话只要求零残留关闭。所有期望值来自源码而非历史输出所有产物不留存在仓库与磁盘使这条泳道可以长期作为 REA 多 Provider 架构下 Ghidra 侧行为回归的可执行契约。赞分享逆向工程MCP 服务AI 技能【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址https://gitcode.com/GitHub_Trending/rea2/rea点击查看免费下载相关推荐rea 的 Apple 原生清单黄金夹具用 dyld、otool 与 codesign 捕获验证 Mach-O 符号解析rea 的 Apple 原生清单黄金夹具用 dyld、otool 与 codesign 捕获验证 Mach O 符号解析 本篇围绕 Apple 原生清单捕获夹逆向工程MCP 服务AI 技能REA 合规测试夹具体系从源码到二进制的逆向 Provider 语义预言机验证管线REA 合规测试夹具体系从源码到二进制的逆向 Provider 语义预言机验证管线 本文围绕 REAReverse Engineer Anything仓库逆向工程MCP 服务AI 技能rea 的 Mach-O 头回归夹具用真实编译的 arm64 二进制固化 otool 解析行为rea 的 Mach O 头回归夹具用真实编译的 arm64 二进制固化 otool 解析行为 本篇技术指南以仓库中 tests/fixtures/nativ逆向工程MCP 服务AI 技能上一篇如何用MAA明日方舟自动化助手高效管理日常任务技术指南与实战经验下一篇iOS 26.5越狱终极指南5个简单步骤解锁iPhone隐藏功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考