REA Hits 200K Stars: Software Isn't Dead, but I Reverse-Engineered Two Apps Without Knowing Assembly

目录

These past two days, a project called REA has been making the rounds on WeChat public accounts, with clickbait headlines like: “Is Software Dead? REA Racks Up 120K Stars in Three Days: No Source Code Needed, Agents Can Clone Any Software.”

I didn’t share it. Instead, I read through the repository properly—README, repository guidelines, CLI contract, MCP contract, testing docs—and then pulled up two apps I’d actually reverse-engineered with Agents over the past few months and compared.

Two-sentence conclusion: “Software is dead” is the headline; the barrier to “understanding someone else’s binary” has genuinely collapsed by a large chunk.

First, About Those Stars

The article was published on October 12, claiming 120K stars on the repo page. Today (October 14), I checked the GitHub API directly: 206,527; the star-count badge in their own README still says 180,000.

Stars aren’t a quality metric—I’ve written that more than once. But there’s one judgment I need to reverse on the spot: REA doesn’t look like “a shell thrown together in three days.”

I dug into its repository structure:

• 3,974 files, of which 2,677 are .ts and 1,558 are test files;
• 26 GitHub Actions workflows, more than half prefixed with real-—real Ghidra (including Windows), real Hopper, real browser, real APK, real firmware, real pcap, running on Termux… all in CI;
• The testing doc docs/testing.md is 1,359 lines long, with a dedicated section called “Real-toolchain verification lanes”;
• The npm package rea-agents was first published on July 12, already at 6.4.0 by October 11—31 versions in three months.

This is a project with engineering discipline, not a demo hastily assembled to ride a wave.

What REA Actually Is

Strip away the hype, one sentence: It’s a locally-running CLI + MCP server that connects your coding Agent to reverse-engineering tools.

It supports Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Kimi Code, Qwen Code, VS Code, Trae, ZCode, and a dozen other clients. Installation is a single command:

npx rea-agents setup

Setup first shows you “which files will be modified, what will be installed, where backups go,” and only proceeds after you approve.

A few points I think are worth highlighting:

• It is not a decompiler itself. Ghidra was open-sourced in 2019, Hopper dates back to 2011, IDA has been around since the ‘90s—none of these are new. What REA does is orchestration: turning the steps where “a human manually shuffles between tools” into workflows that Agents can invoke, complete with evidence.
• Local analysis, no target uploaded. But the README is also straightforward: the model side has its own data policy. So “analysis doesn’t leave your machine” doesn’t equal “data doesn’t leave your machine”—these are two separate things.
• Tools are yours, not installed for you. Ghidra and IDA use your existing installations; only Hopper will be offered for installation after your explicit approval. The repository guidelines explicitly state: the installer must not install or upgrade Node, npm, Java, Homebrew, Ghidra, IDA, JADX, or Binwalk on the side.
• License is MIT.

That last point matters a lot to me. After being burned a few times by scripts that “install the world with one command and trash your environment along the way,” an installer that explicitly promises not to touch your other software is worth more than supporting two extra formats.

What It Can Tear Apart—More Than the Article Lists

The article says it “covers native binaries, app bundles, Electron, websites, .NET, and version diffs”—those are just the ones that fit in a headline. The actual list from the docs looks like this:

Target	What You Get Back	Prerequisites
Native binaries (Mach-O / ELF / PE / .app)	Pseudocode, assembly, strings, symbols, calls and references	Ghidra / Hopper / IDA
JS / Electron (directory or ASAR)	Modules, imports, source maps, routes, IPC, preload boundaries	No engine needed, purely static, does not run the app
.NET managed assemblies	Metadata, CIL, declared native dependencies, build comparisons	No engine needed, purely static
Android APK	Manifest, classes, decompiled methods, references	Headless JADX + full JDK
Android real device	Device, packages, processes, logs, dumpsys, screenshots, file push/pull	Your own adb
Firmware	Partitions, unpacking results, handed off to native analysis	binwalk / unblob
Websites	Page structure, scripts, network observations, screenshots you request	Local Chrome-based browser
Packet captures (HAR / SAZ / mitmproxy)	Requests, responses, exposed payloads, source locations	—
pcap / logic signal recordings	Endpoints, DNS, TLS SNI, protocol distribution / decoded annotations	tshark / sigrok-cli
Crash scenes, Go / Rust binaries, WASM, EVM bytecode, SQLite	Registers and signals, compiler versions and dependencies, imports/exports, dispatch selectors and inferred parameters, table schemas	See respective docs

Let me also explain that line from the article—“I tried it on CapCut and saw everything”: tearing apart an Electron app doesn’t require a reverse-engineering engine at all. You statically unpack the ASAR, follow the IPC and preload paths, and you’re at the implementation—it’s the lowest-barrier category here. What’s actually hard is mobile apps with packing and anti-debugging.

The Design I Find Most Valuable: Evidence Contracts

If REA were just “hooking a decompiler up to an Agent,” I wouldn’t be writing this post. Its real innovation lies in the shape of results: every output comes with three things—coverage, limitations, and unknowns.

Here are some hard rules from its documentation:

• When comparing two versions, graph membership must be complete and traversal coverage must be complete before you’re allowed to conclude “equal”; otherwise the only valid conclusions are “truncated” or “unknown”;
• An empty call list with partial or unknown coverage is not proof that the function has no calls (verbatim from docs: An empty call list with partial or unknown coverage is not proof that the function has no calls.);
• Static artifacts being equal cannot imply runtime behavior hasn’t changed;
• You must distinguish between “I observed it to be empty” and “I didn’t observe at all”—both are empty sets, but they mean completely different things;
• The first rule in its repository guidelines: clearly distinguish observation, derivation, inference, and unknown—don’t mix them together.

The most annoying thing about LLMs doing reverse engineering isn’t insufficient capability—it’s confidently bullshitting while looking like it knows what it’s talking about. REA turns “I don’t know” into a field in the interface. That matters far more than supporting one more file format.

What I Actually Did With It

Let me be upfront about two things: I don’t read assembly. The conclusion of my earlier unidbg notes was literally “don’t read assembly, just run the native startup protocol and show it the result.” So by the old rules—looking up tools, grinding through APIs, digging in symbol tables, hand-drawing call graphs—that kind of work is basically “don’t even think about it” for me.

1. Tearing Apart OnePlus’s “Zen Space” and Building My Own

My requirement was specific: from 10 PM to 6 AM the next day, the phone only allows incoming calls—everything else is blocked, even after a reboot, and the screen should show how much time remains.

OnePlus (OPPO family) happens to have a built-in feature called “Zen Space.” I threw its APK directly at the Agent and told it to tear it apart—com.oneplus.brickmode 16.7.3, the 55 MB one.

What I got back wasn’t source code—it was a skeleton. The key to these “space” features was never in the card UI; it’s in three things: which apps get blocked, how they’re released as time progresses, and where session state is stored (their values are placed somewhere the framework can read, so when time’s up it really can “release” apps).

Then I followed that skeleton and rebuilt it using AOSP’s own mechanisms:

• The interception point goes in the framework’s ActivityStarter.startActivityInner(), only allowing whitelisted apps through. Why here—because it’s the single convergence point for all launch paths. My first version hooked ATMS.startActivityAsUser, but notification taps and recent tasks bypassed it through a different route, effectively leaving a “one tap to open WeChat” loophole;
• The Zen page is a kiosk (lock task) in /product/priv-app, with home, recents, and status bar all disabled;
• Added a 30-second watchdog: if during the time window the top activity is neither the Zen page nor on the whitelist, push the Zen page back to front (don’t modify the call screen—during an incoming call the top activity is the dialer, blindly overlaying would create a “can answer but can’t hang up” situation);
• Session state is written to Settings.Global, and the framework side reads the same keys.

My version now has two modes: Ultra Zen (empty whitelist, can’t exit) and Light Zen (whitelist usable, can exit anytime), automatically starting at 10 PM every night.

One honest detail: when I tore apart this APK on October 11, REA was not yet installed on my machine (its skills were installed on October 13). That time it was just JADX plus Agent brute force. REA’s value is turning this into a repeatable process: APK goes through headless JADX, resources through apktool, and reports come with coverage and unknowns built in.

2. Figuring Out the GPS Track Data from a Fitness App

In the first half of the year I wrote myself a fitness app (RUNNINGGO), with the goal of collecting workout data from my Huawei watch—including heart rate and GPS tracks—into my own database.

The packet capture route was a dead end: Huawei Health does certificate pinning on its domains, and even with a CA installed system-wide the handshake still fails—I documented this pitfall in my phone-tools notes. What ultimately worked was figuring out the track data protocol between the watch and the app: how track points are organized, how to decode them, and how to construct them back in the same format.

By the old approach, this would require a three-in-one skillset: “know assembly, know reverse engineering, know protocols.” I know none of them. What it actually looked like: let the Agent read, try, and compare; when stuck, rephrase and try another round.

From “I want to know how this thing is organized” to “my own pipeline is running,” this kind of problem takes about an hour per round. Before, this wasn’t “I could do it if I spent more time”—it was “I wouldn’t even know where to start.”

But “Software Is Dead” Is the Headline

The genuinely sober part of that article isn’t the opening—it’s the ending. The two practitioners it quotes both had judgments I agree with:

Tech expert Xu Hao: What cloning can take is the code; what it can’t take is the knowledge… “Software itself isn’t the product; the knowledge in the software is.”

QuickCreator co-founder Yan Zhitao: REA will indeed further impact the business model of the software industry, but to call this the apocalypse of software—I disagree.

I also agree with the article’s own reasoning: if software businesses became impossible the moment source code was obtainable, then open-source software business models should have died long ago.

The answer to this reasoning is Red Hat: everyone can download the code, yet enterprises still buy subscriptions year after year—paying for “production-ready software, lifecycle management, compatibility, patches, and experts when things go wrong.” These things don’t happen automatically just because the code is public.

What I want to add is the other side: being able to read someone else’s implementation and having your own product are two different things. What REA gives you is pseudocode and evidence, not a business. Conversely, the article says “the cloning wave has arrived,” but the companies that will actually die were never those whose “code got seen by others”—they’re the companies whose products have nothing worth keeping in the first place.

What’s truly being rewritten is the cost curve. Before, “understanding a binary” was a craft requiring years of practice; now it’s a task you can order from an Agent, with you responsible for verifying the results. What’s saved is the grunt work; what remains is all judgment.

Let me also note the bill, because tokens are the real cost: REA’s skill metadata lists 170 tools, and a single analysis result can be hundreds of MB (official example: a 334 MB Obsidian evidence file compressed into a ~10 KB summary view). The security researcher in the article who tore apart a Unity game burned 40 million tokens, about $27. So the official docs list “saving Agent tokens and context” as the first optimization goal—ask for summary first, then details (detail: "summary", then use inspect_analysis_view to browse module pages).

How I Plan to Use It Going Forward

1. Legacy software, old libraries: Get the summary first, then targeted decompilation—don’t go full dump from the start;
2. Interoperability: The car head unit setup (the broadcast protocol for steering-wheel voice song requests was something I reverse-engineered bit by bit through black-box testing), the watch setup;
3. Stay within bounds: Only tear apart targets I own or have explicit authorization for; commercial tools (IDA / Hopper / JEB) must be legitimately owned—don’t touch cracked versions—their README and DISCLAIMER say the same;
4. Ask “is this worth reverse-engineering” first: This is a lesson I paid two days for in that unidbg post—measure the pipeline first, don’t assume you’re being risk-controlled. The better the tools get, the easier it is to dive headfirst into targets that aren’t worth reversing.

200K stars will drop, and REA will be replaced by something newer. But over these past few months I’ve genuinely experienced one thing:

The gap between someone who can interrogate a binary in natural language and someone who can’t is no longer about “knowing assembly”—it’s about “knowing what to ask and being able to judge whether the answers are true.”

文章作者：阿文

文章链接： https://www.awen.me/post/63c3df7d.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！