各个 App 的产品经理们总是水火不容，” 你的 UI 是垃圾 “、” 这交互是给人用的？”、” 你是伪用户视角，拿少数用户个案代表全量 “。
可当 REA 爆火之后，这群产品经理们一瞬间就完成了战线统一，一致对抗 REA。
产品是这群产品经理们的命脉，有了 REA，这些产品的护城河几乎荡然无存。
法国技术博主 Korben 用 Opus 5.5 对 REA 进行实测。
他让 Agent 读取自己写的一个 crackme 程序的伪代码，大约 2 分钟，Agent 就写出了能通过验证的 Python keygen，API 成本仅为大约 0.5 美元。他随后用 479 个随机用户名做了验证，全部通过。
一个功能从提需求、排期、开发、测试到上线，动辄几个礼拜甚至几个月。可 REA 只要几分钟就给反编译了，这搁谁谁也受不了。
01
具体是怎么反 REA 的？
由于 REA 包含了市面上所有的逆向软件，再加上 AI，因此怎么设计产品都不能保证 100% 不会被反编译。
既然挡不住，产品经理们就开始了抱团想对策。
最朴素也最有效的做法，是不在客户端放密钥和隐藏接口。
过去很多产品会把一些 ” 反正用户看不到 ” 的东西塞进安装包。这其中就包括写死的密钥、内部接口、只在客户端做的权限校验、靠前端判断的会员状态。而这些东西在 REA 面前，就等于是 ” 裸奔 “。
逆向教材《Practical Reverse Engineering》作者之一的埃利亚斯 · 巴沙拉尼（Elias Bachaalany）就表示，唯一稳妥的办法，是把关键逻辑放到服务器上。
所以这群产品经理按照埃利亚斯的方法，把值钱的东西搬出客户端。
尤其是把信任决策放回服务端。用户有没有付费、能不能访问某个功能、这次请求合不合法，都不再由客户端说了算，而是每次都去问服务器。
随后，产品经理们将核心逻辑上云。推荐算法、定价策略、风控规则、关键的数据处理，只让客户端拿到结果，拿不到过程。
这三步合在一起，客户端慢慢变成了一个 ” 只有界面的外壳 “。外壳可以被拆，被复刻，但里面没有东西。
作者声明：该图片由 AI 生成
但是有些场景是没法搬到云端的，比如嵌入式设备和游戏，这些都只能在本地运行。
于是产品经理们开始商量第二套办法，他们对代码加壳、混淆、虚拟化保护和反调试，让 REA 最先逆向出来的玩意是 ” 假的 “。
虽然到最后 REA 还是能逆向完整的产品，但是这会让整个逆向过程变得费劲。
一些厂商也盯上了这门生意。REA 爆火后，Thales 发布 Sentinel Envelope Plus，官方称之为专门针对 AI 逆向的保护方案，可以在不改源码的情况下，对应用的指定部分做多层的反反编译、防篡改和防运行时检查。
Thales 还公布了一组受控测试：对于未保护的应用，AI Agent 找出了 10 个漏洞中的 8 个；加上保护之后 Agent 一个都没找到，token 消耗是之前的 970 倍，最后 Agent 自己建议放弃分析。
对产品加强防护之余，产品经理们还互相分享方法，在 Discord 上创建了反 REA 频道，专门给那些不知道怎么对付 REA 的产品经理传授方法。
其中最常被引用的，是安全公司 Quarkslab 在 8 月发表的文章《Defeating AI-Assisted Reverse Engineering ( or at Least Trying To ) 》。
这篇文章的核心发现是：现代混淆可以让反编译结果在结构上看起来合理，实际上却不反映程序的真实行为，从而把 AI 带离 ” 容易的路径 “，让它得出看似合理但并不正确的判断。
这个思路最有意思的地方在于，过去混淆是为了让人 ” 看不懂 “，现在更重要的是让 AI” 看错 “。
面对一个完全看不懂的程序，Agent 会老实承认他看不懂。可一个看起来逻辑通顺的错误答案，才是对付 AI 的最好办法，因为 Agent 不会停下来质疑它。
产品经理们 ” 统一战线 “，其实更像一种无奈。归根结底，谁也没法让自己的客户端变得不可逆向，只能减缓逆向它的过程，增加逆向它的成本。
02
质疑与谩骂接踵而至
REA 狂欢过后，留下的是一地鸡毛。
埃利亚斯在 REA 刷屏后对其评价为：hype（炒作）。社区给出的证据是，REA 的星标增速远超过它的下载量，也就是所谓的 “drive-by stars”，点了星标但没真正用。
随后埃利亚斯列出了一串早就存在的同类工具。埃利亚斯表示，诸如 GhidraMCP、IDA Pro MCP 这类工具，在 2025 年就已经实现了用 AI 进行逆向分析。
IDA Pro MCP 插件的作者、x64dbg 调试器的开发者邓昆 · 奥格尔维（Duncan Ogilvie），在只使用 IDA Pro MCP 的前提下，大约一小时就解完了今年 Flare-On 逆向挑战赛的题目。也就是说，此前市面上就有比 REA 更好的逆向插件。
但 REA 的优势在于，它自己不做反编译，它做的是调度。让 Agent 去调用 Ghidra、IDA 和 Hopper 这些逆向工具，REA 自己拿到结果，再去写代码、做测试。在这之中，真正对目标进行逆向分析的，仍然是那些老牌工具加上大模型。
实测方面，评价也不一致。Korben 的测试里，REA 与不使用 REA、直接让 Claude 配合 Ghidra 的方案，都完成了四项测试，REA 在一些项目上更快，但在 patch 测试上反而更慢。
还有一个容易被忽略的细节。10 月 19 日的一篇 DEV Community 实测文章表示，通过记录 REA 逆向分析所需的环境后发现，Ghidra、JDK 等依赖需要用户自己准备。
和上面这些冷静的质疑相比，在独立开发者社区更多的是纯粹的谩骂。独立开发者的研发效率远低于企业团队：企业端产品的开发周期通常在 2-3 个月，而不少独立开发者的项目往往要打磨数年。
这要是让 REA 几分钟复制走，那他们心态确实容易崩溃。
10 月 10 日，外网论坛的独立开发者版块就出现了一个爆火的帖子，标题是《Fxxking Hate the whole new trends of “Reverse Engineer Anything”》，大意是 ” 我 XXX 讨厌这股‘ REA ’新潮流 “。
帖子里没有论述，只有纯粹的谩骂。帖子下面的回复里也充斥着谩骂，独立开发者们把这里当成了情绪的宣泄口。
随后，由于这篇帖子几乎变成了英语脏话宝典，最终导致帖子被整个删除。
愤怒的独立开发者们没有大公司的法务和安全团队，没有预算买 Thales 那样的保护方案，作品一旦被逆向分析，几个月甚至几年心血就都没了。
专家说它没什么新东西，是炒作，而普通人却觉得它让一切都变了。
就在矛盾之中，更可怕的事情发生了。
03
已经有木马冒充 REA
任何一个爆火的开源项目，几乎都会引来仿冒者。比如 OpenClaw 爆火之后，GitHub 上面至少有几百个人冒充 OpenClaw 仓库，骗人点进来，然后给下载这个假 OpenClaw 仓库的人植入病毒。
REA 也不例外。
10 月 10 日，一个名为 rea-tools 的 GitHub 组织出现。这个名字，刻意模仿了 REA 的官方网站 rea.tools，让人看一眼就以为这是官方的另一个入口。
仿冒者整份复制官方 README，只在里面加了一段 “Windows 独立版 .exe/GUI” 的下载说明，指向一个名为 “rea-agents: v6.3.0” 的 Release。
而 REA 官方的 README 里根本没有任何安装包，虽然官方仓库的 Issue 2136 里讨论过是否要做一个一键安装版，然而那只是 REA 作者的计划，并没有真正发布出来。
REA 仿冒者的 Release 里是一个 82.6 MB 的压缩包，名为 rea-x64.7z。Microsoft Defender 把压缩包判为 Trojan:Script/Wacatac.B!ml，解压出的 rea-x64.exe 判为 Trojan:Win32/Wacatac.B!ml。VirusTotal 上，45 个引擎中有 8 个报毒。
被举报时，这个文件已经被下载了 172 次。不要忘了，这个病毒是可以二次传播的，所以仿冒者造成的破坏要远远超过已经被曝光的 172 次。
作者声明：该图片由 AI 生成
10 月 13 日，REA 的维护者通过 PR 2429 合并了 README 警示，明确只认三个入口：github.com/morluto/rea、rea.tools 和 npm 包 rea-agents，并强调 ” 相似的仓库名或复制的 README，不能证明下载是官方的 “。
道高一尺魔高一丈，仿冒 REA 的 GitHub 仓库至今仍屡见不鲜。
仿冒者选中 REA，并不奇怪。
第一，套路是现成的。毕竟前面也说了，OpenClaw 爆火那时候早就玩过类似的套路了，如今 REA 爆火，再出现相似的套路一点也不稀奇。
第二，时机。REA 的热度在几天内涨了 10 万星，甚至都不需要 REA 这三个字，只要靠近这个名字，就能分到流量。
第三，仿冒者递出了官方没有的 ” 方便 “。很多用户慕名而来，却并不想自己配 Ghidra 和 JDK，”Windows 版安装包 ” 的字眼正好戳中了他们。
第四，也是最要命的一点，那就是 REA 的用户群，本来就是一群会用 Agent 的人。他们有 MCP、会运行 npx，还会给 Agent 授权。REA 在安装过程中，会把它自己注册进 Agent 的配置，Agent 本身又有 shell、文件和网络权限。
这就导致 REA 上携带的病毒，其破坏力要比那些网络上的病毒更大。
文章来源于网络。发布者：帝国财经，转转请注明出处：https://www.shuixiaomi.com/2026/10/20/4688.html
