我用 REA 逆向了付费颜色 APP,结果很哇塞

大家好，我是你们的朋友架构君，一个会写代码吟诗的架构师。

REA逆向之后：看懂客户端，才刚开始

大家好，我是架构君。

REA 把“软件已死”的讨论带到了程序员面前：拿到安装包，AI 就能看懂实现，付费软件还有多少门槛？

先给判断：REA 降低了调用逆向工具的门槛，但读懂客户端，离重建一个产品还有距离。看游戏加角色和 Flutter 应用分析这两个案例，差别尤其明显。

公开讨论中的软件已死观点

分析结果界面，计数对应具体任务

空调控制搬到电脑菜单栏、智能设备换个操作入口，这类尝试展示了客户端分析的用途。至于“一句话复制软件”，还得看目标、权限和最终验收。

空调控制入口案例

智能设备菜单栏控制案例

REA项目页面截图，页面计数会变化

REA 把哪些活接了起来？

逆向工程，就是从编译后的程序反推结构与行为。能看到伪代码，不代表能拿回逐字一致的源码。

从成品反推实现的示意

REA 本身是一套 CLI 和 MCP 服务。它让 AI 编程助手调用已有分析工具：JADX 看 Android 层，Ghidra、IDA 等分析原生程序。

AI助手通过REA调用分析工具

大白话讲，它像一个调度台：把工具结果整理成证据，再围绕函数、字符串、引用继续追问。真正执行分析的，仍是这些成熟工具。

REA 项目提供的入口是npx rea-agents setup，使用前需要 Node.js、npm，以及对应分析引擎的依赖。完成配置，不代表所有能力自动到位。

游戏加角色，卡在“接得上”

《火影战记》的角色扩展案例里，目标是加入迈特凯。困难很具体：资源怎么读、角色在哪里注册、动画与技能如何关联？

游戏起始选人界面

第一轮角色扩展对话

继续分析游戏结构的对话

第一次流程给出了成功提示，游戏却卡住。后续分析把资源与原生库里的角色注册关系串起来，才有了继续修改的依据。

角色注册关系分析

角色像素动作素材

然后才是选人、进场、释放技能。这条链子，做后端的朋友应该很熟：接口返回成功，不能代替业务真正跑通。

新增角色出现在选人页

角色进入战斗场景

战斗中的技能效果

素材存在、角色可选、战斗可用，是三件需要分别验证的事。画面能跑，也还没回答平衡性与维护成本。

“颜色 APP”拆开后，先看分层

应用案例中，对话出现过模型切换提示。这张界面只能说明当次流程的状态，不能据此判断模型的通用策略或能力排名。

当次对话中的模型切换提示

更有用的是结构分析：这个应用使用 Flutter。只看 Java 层，会漏掉libapp.so中的 Dart AOT 相关信息。REA 的 Flutter 分析提供的也只是有限投影，不能等同于完整工程。

安装包与Flutter结构分析

应用功能与业务信号示意

多币种、外部客服、邀请机制，可以作为进一步检查的线索，不能单凭它们给业务定性。

进一步分析应用的任务对话

工程结构整理结果

把播放器、资源、存储和网络分开，再看日夜主题如何组织，比一句“整个 App 都还原了”更有工程价值。

应用各层结构示意

日夜主题资源示意

案例随后展示了编程学习应用：课程入口、内容页与练习串了起来。这样的重构成果，仍需要检查接口、内容完整性和运行表现。

学习应用工程交付界面

编程学习应用页面

工具越强，越要缩小问题

工具目录、分析输出和反复追问都会占上下文。图中的数量对应特定展示，实际成本取决于版本、目标和调用方式。

逆向工具类别与上下文成本示意

架构君建议按这条链推进：

TEXT明确问题 → 识别目标 → 选择引擎→ 追踪关键证据 → 修改或重建 → 运行验收

先问“角色注册在哪里”，再追相关证据；不要把全部反编译输出一次塞给模型。

客户端能拆，后端还得建

客户端与服务端的信任边界

对 Java 后端团队，更值得关心的是信任边界。Flutter 官方也提醒：混淆只是改名，不会加密资源，更不能保证阻止逆向。

因此，长期密钥、权限裁决和关键业务校验要留在服务端；客户端拿到的凭证应有范围与有效期。

界面与局部实现更容易被理解，服务端能力、生产数据和持续运营仍要积累。

REA 让工具更容易进入 AI 工作流，也让工程师更需要判断证据、控制范围、完成验收。先选一个内部测试包，把结构识别、证据追踪、运行验收跑完整，再决定要不要纳入团队工作流。

技术追风，系统站稳。