The product managers who were still at each other's throats yesterday have all been forced by REA to become comrades in arms today.
Product managers of various apps are always at daggers drawn, with remarks like "Your UI is garbage", "Is this interaction even designed for humans?", "You're adopting a pseudo-user perspective, taking a tiny number of individual user cases to represent the entire user base".
However, after REA went viral, these product managers instantly unified their front and stood together against REA.
Products are the lifeblood of these product managers. With REA around, the moats of these products are almost completely gone.
French tech blogger Korben conducted a practical test on REA using Opus 5.5.
He asked the Agent to read the pseudocode of a self-written crackme program. In about 2 minutes, the Agent wrote a Python keygen that could pass the verification, with the total API cost being only around $0.5. He then verified it with 479 random usernames, and all of them passed.
A single feature usually takes weeks or even months from requirement submission, schedule arrangement, development, testing to launch. But REA can decompile it in just a few minutes, which is unacceptable for anyone.
How exactly are people fighting against REA?
Since REA integrates all reverse engineering tools on the market and is empowered by AI, no product design can guarantee 100% immunity to decompilation.
Since it is impossible to block REA completely, product managers started to team up to figure out countermeasures.
The most straightforward and effective approach is to avoid storing keys and hidden interfaces on the client side.
In the past, many products would embed content that "users won't see anyway" into installation packages, including hardcoded keys, internal interfaces, permission verification that only runs on the client side, and membership status judged solely by the frontend. All these assets are completely exposed under REA, just like "running naked".
Elias Bachaalany, one of the authors of the reverse engineering textbook Practical Reverse Engineering, stated that the only reliable solution is to move core logic to the server side.
Therefore, these product managers followed Elias's method and moved all high-value assets out of the client side.
In particular, they moved trust-related decisions back to the server side. Whether a user has paid, can access a certain feature, or whether a request is legitimate is no longer determined by the client, but checked with the server every single time.
After that, product managers migrated core logic to the cloud. Recommendation algorithms, pricing strategies, risk control rules and critical data processing only return results to the client, without exposing the underlying execution process.
With these three steps combined, the client gradually becomes a "shell with only an interface". The shell can be disassembled and replicated, but there is no valuable content inside.
However, some scenarios cannot be migrated to the cloud, such as embedded devices and games, which can only run locally.
So product managers came up with the second set of countermeasures: adding packing, obfuscation, virtualization protection and anti-debugging to the code, so that the first thing REA reverses out is a "fake" result.
Although REA can still reverse the complete product eventually, this process will make the entire reverse engineering process much more difficult.
Some vendors have also targeted this business. After REA went viral, Thales released Sentinel Envelope Plus, which is officially described as a protection solution specifically designed for AI-assisted reverse engineering. It can add multi-layer anti-decompilation, anti-tampering and anti-runtime inspection to designated parts of applications without modifying the source code.
Thales also published a set of controlled tests: for unprotected applications, the AI Agent found 8 out of 10 vulnerabilities; after adding protection, the Agent found none of them, the token consumption was 970 times of the original level, and finally the Agent itself suggested abandoning the analysis.
While strengthening product protection, product managers also shared countermeasures with each other, and created an anti-REA channel on Discord to teach methods to product managers who do not know how to deal with REA.
The most frequently cited material is the article Defeating AI-Assisted Reverse Engineering (or at Least Trying To) published by security company Quarkslab in August.
The core finding of this article is that modern obfuscation can make decompiled results look structurally reasonable, but do not actually reflect the real behavior of the program, thus leading AI away from the "easy path" and making it draw seemingly reasonable but incorrect conclusions.
The most interesting part of this idea is that in the past, obfuscation was designed to make humans "unable to understand", but now the more important goal is to make AI "misjudge".
Faced with a completely incomprehensible program, the Agent will honestly admit that it cannot understand it. However, a seemingly logically consistent wrong answer is the best way to fight against AI, because the Agent will not stop to question it.
The "united front" of product managers is actually more of a helpless move. In the final analysis, no one can make their client completely non-reversible, they can only slow down the reverse engineering process and increase the cost of reversing the product.
Doubts and Abuses Followed One After Another
After the REA carnival, what is left is total mess.
Elias commented on REA after it became a viral hit as nothing more than hype. Evidence from the community shows that the growth rate of REA's GitHub stars far exceeds its download volume, which is the so-called "drive-by stars" — users starred the repository but never actually used it.
Then Elias listed a series of similar tools that have long existed. Elias pointed out that tools such as GhidraMCP and IDA Pro MCP have already realized AI-assisted reverse analysis back in 2025.
Duncan Ogilvie, author of the IDA Pro MCP plugin and developer of the x64dbg debugger, completed all the challenges of this year's Flare-On reverse engineering competition in about one hour only using IDA Pro MCP. That means there were already better reverse engineering plugins on the market before REA.
But the advantage of REA is that it does not do decompilation itself, it is a scheduler. It lets the Agent call reverse engineering tools including Ghidra, IDA and Hopper, gets the results, then writes code and conducts tests. In this process, those established tools plus large language models are still the ones that actually perform reverse analysis on the target.
In terms of practical tests, the evaluations are inconsistent. In Korben's test, both REA and the solution that does not use REA but directly combines Claude with Ghidra completed four tests. REA is faster in some projects, but slower in patch tests.
There is also an easily overlooked detail. A practical test article published on DEV Community on October 19 shows that after recording the environment required for REA reverse analysis, users need to prepare dependencies such as Ghidra and JDK by themselves.
Compared with these calm doubts, there are far more pure abuses in the independent developer community. The R&D efficiency of independent developers is much lower than that of enterprise teams: the development cycle of enterprise products is usually 2-3 months, while many independent developers spend years polishing their projects.
If REA can replicate their work in just a few minutes, it is easy for them to break down emotionally.
On October 10, a viral post appeared in the independent developer section of an overseas forum, titled Fxxking Hate the whole new trends of “Reverse Engineer Anything”, which roughly means "I XXX hate this new REA trend".
The post contains no rational discussion, only pure abuse. The replies under the post are also full of abusive language, and independent developers took the section as an outlet to vent their emotions.
Later, as the post almost became a collection of English swear words, it was eventually completely deleted.
Angry independent developers do not have the legal and security teams of large companies, nor the budget to buy protection solutions like Thales. Once their works are reverse analyzed, months or even years of hard work will be wasted.
Experts say REA has nothing new and is just hype, while ordinary people feel that it has changed everything.
In the middle of these contradictions, something even more terrible happened.
Trojans Pretending to Be REA Have Already Appeared
Almost every viral open source project will attract impersonators. For example, after OpenClaw went viral, there were at least hundreds of people on GitHub impersonating the OpenClaw repository, tricking people into clicking in, and implanting viruses into users who downloaded the fake OpenClaw.
REA is no exception.
On October 10, a GitHub organization named rea-tools appeared. The name deliberately imitates REA's official website rea.tools, making people think it is another official entrance at first glance.
The impersonator copied the entire official README, only adding a download note for "Windows standalone .exe/GUI" that points to a Release named "rea-agents: v6.3.0".
However, there is no installation package at all in REA's official README. Although Issue 2136 in the official repository discussed whether to make a one-click installation version, that was only a plan of REA's author and has never been actually released.
The Release of the fake REA contains an 82.6 MB compressed package named rea-x64.7z. Microsoft Defender marks the compressed package as Trojan:Script/Wacatac.B!ml, and the extracted rea-x64.exe as Trojan:Win32/Wacatac.B!ml. On VirusTotal, 8 out of 45 engines detected it as malicious.
When the report was submitted, this file had been downloaded 172 times. Do not forget that this virus can spread secondarily, so the damage caused by the impersonator is far more than the 172 times of downloads that have been exposed.
On October 13, REA maintainers merged a README warning via PR 2429, clarifying that there are only three official entrances: github.com/morluto/rea, rea.tools and the npm package rea-agents, and emphasizing that "similar repository names or copied READMEs do not prove that the download is official".
Law is one step behind the evil, and fake REA GitHub repositories are still common up to now.
It is not surprising that impersonators targeted REA.
First, the routine is already ready-made. As mentioned earlier, similar tricks were played when OpenClaw went viral, so it is not strange at all that similar tricks appear again after REA becomes popular.
Second, the timing is perfect. REA's popularity gained 100,000 new stars in just a few days. Even without the exact name "REA", repositories with names close to it can attract traffic.
Third, impersonators provide the "convenience" that the official version does not have. Many users come for the reputation of REA, but do not want to configure Ghidra and JDK by themselves. The wording "Windows version installation package" perfectly hits their demand.
Fourth, the most fatal point is that REA's user group is exactly people who know how to use Agents. They use MCP, run npx, and grant authorization to Agents. During the REA installation process, it will register itself into the Agent's configuration, and the Agent itself has shell, file and network permissions.
As a result, the virus carried by fake REA has far greater destructive power than ordinary viruses on the Internet.
This article is from the WeChat official account "Letter AI", written by Miao Zheng, and authorized for release by 36Kr.