聊聊 REA及相关项目—Agent 正在重写逆向工程工作流

REVERSE ENGINEERING · 工程观察

解释一个行为之前，先保留能被核对的观察。

山行 AI

看到一个软件功能，以前的第一步通常是打开反汇编器、搜字符串、找引用，然后在函数和运行结果之间来回确认。现在，你可以先把问题交给 Agent：这个剪贴板接口怎样传递数据？音效为什么会随位置变化？一个旧程序要在新系统上运行，还缺哪些接口？

这里容易混淆两件事：Agent 能解释一段伪代码，是否就理解了实际行为？工具成功执行，是否就验证了结论？REA、Ghidra、RAD Debugger 与 AnyPS5，能帮助我们把调查、分析、调试和兼容实现逐项拆开。

读完这四个项目，可以带走一套具体的检查顺序：谁在提供观察，谁在做推断，哪些结论需要运行对照，以及怎样保存下一位研究者能继续使用的记录。

本文依据 2026 年 10 月 12 日 14:27，北京时间 的仓库快照、项目文档与发布记录整理，区分发布版和开发分支。案例数字来自项目公开报告；本文没有运行商业应用逆向实验，也没有实测游戏兼容性。

本文三个看点

先看它们的位置，再讨论怎样组合。把它们放在同一张榜单里评“谁更强”，容易忽略任务本身。

Star 是当时的关注度快照，不代表分析准确率、兼容率或性能排名。RAD Debugger 即使在 GitHub 中没有标为 prerelease，版本名称和项目说明仍明确属于 alpha。

REA 与 Ghidra 之间有已实现的适配关系。RAD Debugger、AnyPS5 则展示动态验证和兼容实现的另外两种工作：本次核对的资料没有证明四个项目已组成开箱即用的共同系统，也没有证明 AnyPS5 本身依靠 REA 开发。

REA（https://github.com/morluto/rea） 的完整名称是 Reverse Engineer Anything。它提供 MCP 服务和 CLI，连接本地分析工具，把一次模糊提问拆成可继续追问的调查。

它的原生二进制深度分析可以接已有的 Hopper、Ghidra 或 IDA。JavaScript／Electron 的静态分析则能直接读取目录、ASAR、模块导入、源码映射与 IPC 关系；.NET 路线读取元数据和 CIL 指令。它还为网页、HAR 网络记录、Android、固件、WASM、Go 构建信息和 Linux 崩溃记录提供不同的分析入口，部分能力需要额外工具与特定宿主系统。

REA 在 Hopper 中启动分析桥接、检查原生二进制的公开演示

MCP 接口之外，还有调查和证据层

CLI 与 MCP 共用应用层调查流程。二进制会话先选择分析引擎，再绑定目标；证据账本保留每次观察，快照缓存复用满足身份条件的分析结果。网页、JS 和其他辅助分析按自身能力路由，不强行伪装成原生反编译。

这会影响 Agent 的行为。工具可用性要按当前目标、引擎、宿主和客户端查询，不能因为工具目录里列出了一个名称，就假定当前能调用。多个引擎都能分析时，需要明确选择；运行中失败不会自动换另一个引擎，避免把不同分析口径混进同一次调查。

REA 调查流程：提出问题，检查与追踪本地目标，返回证据，再解释、实现和测试

在当前 MCP 结果契约中，normalized_result 放规范化结果，evidence_id 标识证据，raw_result 区分供应商原始表示，analysis_profile 记录分析口径。调用图还保留 limitations，路径追踪记录 residual_unknowns 和截断状态。

这不是给回答加一个“高置信度”标签。它要求保留具体限制：只识别到部分调用时，空列表不能证明函数没有调用；Ghidra 没定义出的字符串，也可能不在搜索结果中。Agent 应据此继续查字节和引用，而不是把“没搜到”写成“不存在”。

最小上手：先接工具，再问一个窄问题

REA 当前支持 Node.js 22.x 的 22.19 及以上、24.x 的 24.11 及以上，或 26+；不要只看“Node 版本越高越好”，23、25 和预发布版本不在支持范围中。

安装引导会让你选择 Agent，查看拟修改的 MCP 配置与工作流指令，并备份现有配置。确认后重启客户端。只装 Skill 指令，还没有注册实际 MCP 服务。

若使用全局安装的 CLI，可以先检查能力，再分析自己拥有且允许分析的样例：

这里的路径和关键词是示例，需要换成实际目标。原生分析还需要正确配置对应引擎；静态 JS 或 .NET 分析可以从更少依赖的路线开始。

一次合适的请求可以是：

“本地分析”也有具体含义：文件检查在本机完成，但 Agent 会收到工具结果，其模型服务商有自己的数据政策。运行时捕获还会按当前用户权限启动或交互目标；静态读取和执行观察需要分别选择。

三个案例，体现了什么变化

REA 的公开案例包括 DX-Ball 音效声像、Notion Electron 剪贴板桥接，以及 TH04 的 16 位弹幕角度计算。

REA 的 DX-Ball、Notion 和 TH04 公开案例示意

DX-Ball 案例沿声音调用找到位置到声像的计算，再将不完整伪代码还原为 C。作者报告通过 3,205 个原始 x86 对照案例，并复现该函数全部 63 个编译字节。Notion 案例则追踪 renderer、preload、IPC 与主进程之间的剪贴板接口。TH04 将指令观察、角度计算和历史编译器输出放在一起核对。

值得借鉴的是验证路径：找到行为对应代码，提出解释，再与原始执行或编译结果对照。这些数字只属于对应案例，不能推导出 REA 对任意程序的普遍准确率。

Ghidra（https://github.com/NationalSecurityAgency/ghidra） 是 NSA 维护的软件逆向分析框架，支持 Windows、macOS、Linux，涵盖反汇编、反编译、图结构分析、脚本和扩展，支持多种处理器指令集与可执行格式。

Ghidra 项目标识

一个典型的静态分析过程是导入程序，识别格式与处理器，执行自动分析，再检查函数、符号、字符串、引用和反编译结果。脚本接口与无界面入口使这些动作可以批量执行；PyGhidra 提供 CPython 3 的接入路径。

Ghidra 本身也有 Debugger 模块，并不是只有静态分析。本文把它放在“分析底座”的位置，是为了讨论 REA 当前实现的接口范围，不能把这种分工写成 Ghidra 的全部功能边界。

REA 怎样接入 Ghidra

REA 使用打包的 Java HeadlessScript 桥接，而不是让模型凭截图猜界面。它把目标副本导入临时 Ghidra 项目，在自动分析完成后提供程序清单、指令、反编译、交叉引用和函数内控制流等能力。

函数资料还能包含 high P-code 的定义—使用关系。P-code 是 Ghidra 的中间表示，便于描述指令的数据操作；REA 可据此整理函数内数据流，并跨已解析的调用组合参数与返回值依赖。但这不等于解决所有内存别名、调用副作用、持久状态和业务语义，较大结果也会明确报告截断。

当前 Linux／macOS 路径支持只读分析及临时项目中的函数命名、入口注释编辑，Windows P0 则限定只读分析。GUI 控制和持久 Ghidra 数据库修改不在该适配器范围中。可执行文件字节保持不变，分析项目里的标注与修改二进制是两件事。

Windows 的 P0 文档还限定本地 NTFS、x64 宿主、符合要求的原生 PE 应用或 DLL，以及 25 个只读分析操作。它不是全部格式、所有架构和 GUI 操作的统一承诺。

安装和等待，都要看所用版本

本次最新正式发布是 Ghidra 12.1.4，其随版本提供的安装指南要求 64 位 JDK 21。开发分支的安装说明已经改为 JDK 25，源码构建还要求 Gradle 9.1.0+。下载发布包和构建开发版，依赖不能混用。

普通使用者可先下载正式发行 ZIP，解压到新的目录，通过 ghidraRun 或 Windows 的 ghidraRun.bat 启动，导入自己编写的小程序。先理解一个函数的指令和伪代码，再接入自动调查，比一开始丢进复杂大程序更容易定位问题。

第一次无界面导入可能超过 MCP 客户端的默认等待时间。REA 文档明确区分客户端请求截止时间和分析引擎启动截止时间；进度通知也不自动延长超时。请求超时后应检查会话和清理结果，而不是不断重开进程或假定分析已经完成。

RAD Debugger（https://github.com/EpicGames/raddebugger） 是原生、用户态、多进程图形调试器。它适合回答运行时的问题：某个分支有没有命中？参数是什么？线程停在哪里？内存何时发生变化？

项目当前说明的主要调试支持是本机 Windows x64 与 PDB，仍处于 alpha。仓库有 Linux 开发构建说明和多个跨平台抽象层，但其路线图仍把完整本地 Linux 调试、DWARF 等列为扩展工作。不能据此推荐它作为已经成熟的跨平台调试替代。

RDI 与异步控制，是它的架构重点

它将原生 PDB 按需转换为自有的 RAD Debug Info（RDI）格式，再用于查询。dbg_info 负责异步转换、加载和缓存；demon 封装低层进程控制；ctrl 处理步进和断点；dbg_engine 提供无图形的调试逻辑；eval 求值变量、寄存器和类型；前端负责显示与交互。

这些层有依赖方向，部分 RDI 库可以单独复用。前端和被调试进程的控制工作也分开，目的是让庞大的调试信息和运行控制不会全部挤在界面线程中。

项目还包含 RAD Linker 和 radbin。Linker 面向大型 x64 PE／COFF 链接任务，可以生成 PDB 或 RDI；作者的测试报告给出大工程链接提速，但这属于链接阶段，不能写成 Agent 推理或所有调试操作的性能提升。

RAD Linker 的作者基准图：AMD Ryzen Threadripper PRO 3995WX、64 核、256 GiB RAM、Windows x64；衡量链接任务，不是 Agent 或调试器通用性能

它有自动化入口，但还需要接入层

源码中的启动帮助明确支持 --ipc <command>：一个短生命周期进程将命令发送给已运行的调试器。编辑器或其他程序可以使用它控制调试器。这是扩展自动化的入口，不等同于现成 MCP 服务，也不证明 REA 已内置 RAD Debugger 适配。

上手时建议先下载 alpha 发布包，用自己编译、带 PDB 的小型 C／C++ 程序练习断点、单步、监视和调用栈；使用说明在发行包内。若从 Windows 源码构建，项目要求 MSVC／Windows SDK，并提供 build.bat 与发布模式参数。

把它接入 Agent 时，额外工作包括限定可调用命令、明确当前进程和停机状态、将观察结果整理成结构化记录。这些属于接入方案，本文不把它们说成项目已经交付的功能。

AnyPS5（https://github.com/boykopovar/AnyPS5） 关注可执行文件移植。它的路线是把输入程序转换为宿主的原生文件格式，并提供可以动态链接的系统接口实现。项目明确采用这种方式，而不是用单独的 CPU 仿真运行时解释整套指令。

这也不表示它完全不需要运行时组件：输出程序仍依赖 AnyPS5 构建的共享系统库、图形转换和宿主系统能力。自动重链接只是完整兼容链路的一部分。

CPU、系统接口、GPU 要分别解决

重链接器解析 ELF 与导入符号，通过 NID（接口标识）识别依赖，检查系统调用，处理随程序附带的模块，再输出 Linux ELF 或 Windows PE。按需转换受支持的 AMD 专有指令；不支持的转换要报告错误。

系统库位于 core/libs/prx，构建后通过 nid_patcher 将导出名映射为 NID，交给宿主加载器绑定。原程序附带的模块需要单独转换，不能随手把原始 PS5 的 .prx 当 Windows DLL 放进库目录。

GPU 路线则处理命令缓冲与状态，并经过 RDNA 解码、控制流结构化、内部表示转换、SSA 与资源优化，最终输出 SPIR-V，再建立 Vulkan 管线。项目提供内存和磁盘缓存；启用 SPIRV-Tools 时可以进行验证和优化。

因此，“CPU 指令能执行”“符号能链接”“着色器能生成”“游戏画面正确”，分别需要证据。SPIR-V 验证通过，只能覆盖对应表示的检查，不能保证场景、同步和每个像素都与原平台相同。

AnyPS5 系统库与着色器进度图，2026 年 10 月 12 日快照；分母是项目已声明的接口与当前统计样本

兼容性要按程序、平台和提交核对

公开兼容列表包含 Dreaming Sarah 与 DOOM Shareware 自制程序。Dreaming Sarah 的 60 FPS 来自指定 GTX 1050 Ti、i5-7500 配置，列表中它的 Linux 状态仍未确认。DOOM 记录区分 Windows、Linux、硬件、提交和是否叠加未合并 PR，一些记录只验证首关或部分输入、声音、存档行为。

进度图中的系统库百分比，是“项目目前声明的已知函数”口径，新增声明还会扩大分母。它既不是全部 PS5 系统函数的完成率，也不是游戏兼容率。

项目倾向于在不支持的状态抛出异常、打印错误并终止；技术债文档又明确列出静默桩和未经验证的接口语义。即使某次调用返回成功，仍要检查对话框、音频或设备行为是否真正实现。

从小型转换测试开始

研究重链接器可以先用只构建转换器的模式，减少 SDL、Vulkan、FFmpeg 等完整依赖：

这条路径构建转换器与测试，并不提供运行游戏所需的系统库。完整构建要初始化子模块，并显式构建 libs；默认关闭测试时，普通构建不一定生成这些库。

对合法取得、允许研究的输入样例，转换方式为：

需要完整的模块与资源布局，输出名为 .exe 本身也不会选择 Windows。不要把“生成了文件”当成“已经可玩”。

当前使用文档和源码新增了 --macos、--to-rosetta 等路径，但架构和构建说明仍有只描述 Linux／Windows 的段落，兼容列表也未建立 macOS 的同等验证。阅读开发分支时，应将这些路径单独检查，不将它们归到 0.1.1 发布版的已验证能力中。

AnyPS5 采用 GPL-2.0-only，不提供游戏、固件、密钥或专有库。REA、RAD Debugger 是 MIT，Ghidra 是 Apache-2.0；把分析结果用于自己的实现时，还需分别处理代码、素材和目标程序的授权。

真正可以直接成立的一条路线是：Agent 通过 REA 的 MCP 提问，REA 选择 Ghidra，桥接执行分析，结果以证据返回。Ghidra 的临时项目、输入身份、缓存与进程生命周期由适配层管理。

功能架构：Agent—REA—Ghidra 为已有接口；RAD Debugger 和 AnyPS5 用于说明调试与兼容实现，协作仍需单独接入

从那里延伸，可以设计两种工作流。

第一种是功能理解与独立重实现。先用静态分析找到接口和计算，再通过允许的运行观察确认输入、输出与边界；最后编写独立实现，用同一批样例比较。没有原始源代码时，更要保留推断与未解问题。

第二种是兼容性修复。先定位宿主不支持的指令、导入接口或着色器阶段，再为一个窄行为补实现和回归测试。AnyPS5 展示的是这种工程的具体载体；Agent 可以辅助整理证据和补测试，兼容性仍由可运行结果决定。

Windows 宿主上的独立原生测试程序可以用 RAD Debugger 检查；AnyPS5 的具体输出及调试符号是否适合它，则需要另行验证。Linux 目标应选择实际支持该宿主的调试器，不强行把 RAD Debugger 放进每条路径。

先把问题缩小到一个可以观察的行为。例如“剪贴板怎样传递富文本”，比“完整还原这个软件”更容易得到可验收的结果。

建议流程：固定目标，静态取证，明确假设，运行验证，独立实现，再做回归对照

不一定每项任务都走完六步。解释一个静态导入表可能无需运行程序；声称“功能等价”或“移植成功”则需要更完整的对照。验收标准应随结论一起提高。

如果你想让 Codex、Claude Code 等客户端连续调查应用行为，REA 是接入入口。能否完成任务取决于后端引擎、依赖与目标类型，MCP 本身不会补上这些能力。

如果主要工作是多架构函数分析、反编译、标注和脚本，先熟悉 Ghidra。它提供的指令、引用与类型信息，是判断 Agent 解释是否可靠的重要依据。

如果你在 Windows 上开发或研究带 PDB 的原生程序，需要反复观察线程、参数和内存，RAD Debugger 更接近任务；它也能为自动化提供 IPC 入口，但接入层需要自己明确。

如果研究目标是二进制跨系统兼容，AnyPS5 更适合作为案例阅读。它把重链接、ABI（应用二进制接口）、系统库、图形转换和测试放在同一条链上，门槛也比一句自然语言命令高得多。

评估 Agent 是否帮上忙，可以记录同一个问题定位了多久、多少结论能指回证据、哪些测试区分了错误假设，以及别人能否按记录重现结果。四个仓库没有提供统一的横向 Agent 准确率评测，不能靠 Star 或漂亮演示替代比较。

逆向工程里最耗时间的工作，常常是反复切换工具、找上下文和核对猜想。Agent 可以帮忙组织这些动作，但最终解释还要回到具体观察。

从一个小函数或一条 IPC 链开始，保存地址、原始结果、限制和对照样例。等这套记录能被复核，再扩大范围。软件行为理解得越清楚，后续重实现和兼容修复才越有依据。

我是山行 AI，持续分享 AI 工具与开源项目观察。

资料与声明

主要资料：REA 安装与发布边界（https://github.com/morluto/rea/blob/main/docs/installation.md）、MCP 结果契约（https://github.com/morluto/rea/blob/main/docs/mcp-contracts.md）、Ghidra provider 语义（https://github.com/morluto/rea/blob/main/docs/ghidra-provider.md）、REA 公开案例（https://rea.tools/showcase/）、Ghidra 12.1.4 安装指南（https://github.com/NationalSecurityAgency/ghidra/blob/Ghidra_12.1.4_build/GhidraDocs/GettingStarted.md）、RAD Debugger（https://github.com/EpicGames/raddebugger）、AnyPS5 架构（https://github.com/boykopovar/AnyPS5/blob/main/docs/dev/ARCHITECTURE.md）、AnyPS5 使用说明（https://github.com/boykopovar/AnyPS5/blob/main/docs/user/USAGE.md）、AnyPS5 兼容记录（https://github.com/boykopovar/AnyPS5/blob/main/docs/user/COMPATIBILITY.md）、AnyPS5 技术债（https://github.com/boykopovar/AnyPS5/blob/main/docs/dev/TechnicalDebt.md）。

本文由山行整理自：REA（https://github.com/morluto/rea）、Ghidra（https://github.com/NationalSecurityAgency/ghidra）、RAD Debugger（https://github.com/EpicGames/raddebugger）、AnyPS5（https://github.com/boykopovar/AnyPS5）及文中项目文档与公开案例，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～