各个App的产品经理们总是水火不容，“你的UI是垃圾”、“这交互是给人用的？”、“你是伪用户视角，拿少数用户个案代表全量”。
可当REA爆火之后，这群产品经理们一瞬间就完成了战线统一，一致对抗REA。
产品是这群产品经理们的命脉，有了REA，这些产品的护城河几乎荡然无存。
法国技术博主Korben用Opus 5.5对REA进行实测。
他让Agent读取自己写的一个crackme程序的伪代码，大约2分钟，Agent就写出了能通过验证的Python keygen，API成本仅为大约0.5美元。他随后用479个随机用户名做了验证，全部通过。
一个功能从提需求、排期、开发、测试到上线，动辄几个礼拜甚至几个月。可REA只要几分钟就给反编译了，这搁谁谁也受不了。
具体是怎么反 REA 的？
由于REA包含了市面上所有的逆向软件，再加上AI，因此怎么设计产品都不能保证100%不会被反编译。
既然挡不住，产品经理们就开始了抱团想对策。
最朴素也最有效的做法，是不在客户端放密钥和隐藏接口。
过去很多产品会把一些“反正用户看不到”的东西塞进安装包。这其中就包括写死的密钥、内部接口、只在客户端做的权限校验、靠前端判断的会员状态。而这些东西在REA面前，就等于是“裸奔”。
逆向教材《Practical Reverse Engineering》作者之一的埃利亚斯·巴沙拉尼（Elias Bachaalany）就表示，唯 一稳妥的办法，是把关键逻辑放到服务器上。
所以这群产品经理按照埃利亚斯的方法，把值钱的东西搬出客户端。
尤其是把信任决策放回服务端。用户有没有付费、能不能访问某个功能、这次请求合不合法，都不再由客户端说了算，而是每次都去问服务器。
随后，产品经理们将核心逻辑上云。推荐算法、定价策略、风控规则、关键的数据处理，只让客户端拿到结果，拿不到过程。
这三步合在一起，客户端慢慢变成了一个“只有界面的外壳”。外壳可以被拆，被复刻，但里面没有东西。
但是有些场景是没法搬到云端的，比如嵌入式设备和游戏，这些都只能在本地运行。
于是产品经理们开始商量第二套办法，他们对代码加壳、混淆、虚拟化保护和反调试，让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不会停下来质疑它。
产品经理们“统一战线”，其实更像一种无奈。归根结底，谁也没法让自己的客户端变得不可逆向，只能减缓逆向它的过程，增加逆向它的成本。
质疑与谩骂接踵而至
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那样的保护方案，作品一旦被逆向分析，几个月甚至几年心血就都没了。
专家说它没什么新东西，是炒作，而普通人却觉得它让一切都变了。
就在矛盾之中，更可怕的事情发生了。
已经有木马冒充 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次。
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上携带的病毒，其破坏力要比那些网络上的病毒更大。