I watched this video on YouTube, titled "I Tested The Viral Reverse Engineering Repo" (https://www.youtube.com/watch?v=qFEuYUfauNY). The video has attracted over a million views in a single day. Clearly this is a red-hot topic!

I'm no expert in reverse engineering and I'm still trying to figure out how all this works. To be honest, it feels like every week we're getting yet another must-have "game changer". It's driving me crazy!

Anyway, as I understand it, REA connects AI agents to established reverse-engineering tools, allowing them to analyse existing software and recreate it.

Here's my question: Do we actually need REA, or could a general-purpose agent like OpenClaw achieve much the same thing?

Put differently: Is REA doing something fundamentally different, or is it primarily orchestrating existing tools and techniques into a convenient workflow?

Given how new it is, I imagine there aren't many people who've had a chance to experiment with it yet. But if anyone can shed some light on what's going on here, even at a broad level, that would be really useful.

Thanks!

Hey AJZoidDev, great question and honestly, your skepticism is well-placed. The "game changer of the week" fatigue is real.

My answer: no, REA isn't doing something fundamentally new. It's primarily a well-built orchestration layer. It doesn't ship its own decompiler; it wraps existing tools like Ghidra, IDA, and Hopper via an MCP server, then lets a coding agent (Claude Code, Codex, etc.) drive them iteratively. The REA README itself is pretty modest—it explicitly says it doesn't claim to recover original source code or automatically clone an application.

Where REA does add value over a raw general-purpose agent like OpenClaw is in the structure and evidence model. Every finding REA returns carries provenance—file digests, byte ranges, and an explicit list of what the analysis *could not* establish. It also packages the investigation workflow so the agent can follow call chains, track offsets, and reuse earlier findings without starting from scratch each time. In practice, that means less hallucination and more verifiable results. One hands-on test found REA mapped an Electron app's renderer API perfectly (121/121 members matched source) but missed some security-relevant IPC handlers—so it's useful but not magic.

As for OpenClaw: it's a general-purpose autonomous agent framework, not a reverse-engineering specialist. You could theoretically prompt it to install Ghidra and start poking at a binary, but you'd be building the harness, the evidence tracking, and the tool integration yourself. REA is essentially that harness, pre-built and packaged with an evidence contract.

So: is it a "game changer"? For the specific niche of AI-assisted binary analysis, it lowers the barrier significantly and does the tedious parts well. For the broader claim that "any app can be cloned with one prompt"? That's hype. The Low Level video itself frames REA as a well-built harness around existing tooling, not a new technique. If you're curious, the practical move is to treat it as a force multiplier for specific, scoped tasks—not a magic wand.

Hope that helps cut through some of the noise!
Good Day!

CG

I have not had a chance to watch the full video but I have heard of REA and I too feel a bit frustrated by all these constant blockbuster launches.

Chandresh, it sounds like you know far more about this topic than I do. Have you used it yourself? If so, how did it go? Did you manage to clone any software packages?


Also, (for anybody). Can I just add the following list of questions to the already huge and growing list that I already have:

1). Did the people who recently cloned Adobe use REA?

2). If not then what did they do (to clone Adobe) that was different?

3). How does REA work, broadly speaking? Does it take and analyse screenshots? Does it actually use the software (triggering mouse movements etc). Or, does it somehow analyse the binary software files?

4). If it needs to analyse binary files to produce a clone does that mean it won't work on web software (which probably makes up the vast majority of software these days)?

5). What about the costs? Doesn't this burn huge numbers of tokens?

6). Given the fact that nobody installs anything these days, what's all the fuss about?

And finally, I have my crystal ball out and here's a prediction. I bet you that within the next seven days something else comes along that's yet another game changer! Does anybody want to take that bet? ;)


PS - I feel as if there's no point in taking these questions to AI tools like Chat GPT. The pace is so fast that I assume they won't be able to keep pace with all the new stuff.

Dafa told me about this tool just the other day. It's definitely something that I'd like to look into but I worry about token costs.

Sophie, these are excellent questions, and I have gone to the primary sources rather than repeating the summaries, because this particular story has attracted more second-hand claims than most.

1) Did the people who recently cloned Adobe use REA?

No. The Adobe clones are the ArtCraft "Craft" apps (PhotoCraft, FilmCraft, EffectCraft and their siblings), published as clean-room reimplementations written in pure Rust. Their own contributor rules forbid precisely what REA is built to do: "Never read, disassemble or copy anything inside Adobe application bundles; file names and listings only. Observe behaviour by using the app." So REA was off-limits by their own policy, not merely unused.

2) If not, then what did they do that was different?

A clean-room rebuild from public specifications and observed behaviour. Their own documentation says the codecs are theirs, written from the public standards (ITU-T/ISO, RFCs, SMPTE). Claude was used to run agents in parallel on separate components, with a human stitching, testing and releasing. It is early alpha: the team's own estimate is 25 to 35 percent of what a professional needs day to day. The applications are free; the business is selling AI generation credits. Also worth noting that Adobe's licence forbids reverse engineering, so never opening the binary is the legal defence rather than a shortcoming.

3) How does REA work, broadly speaking?

It is a harness, not a new technique: an MCP server and CLI that your coding agent drives. There are three families of target.

- Native binaries, examined through Ghidra, IDA, Hopper or JEB, returning pseudocode, assembly, strings, symbols and call references.
- JavaScript and Electron, .NET assemblies, Android APKs, WASM, firmware, and Go and Rust binaries, analysed statically with no decompiler required.
- Websites, where it attaches to your own Chrome-family browser over the DevTools Protocol and observes passively: DOM and accessibility structure, script sources with digests, network and console metadata, optional screenshots, and storage key names with the contents redacted.

So, to answer your sub-questions directly: it neither needs nor primarily uses screenshots, and it does not drive the mouse. It does not "use" the software. The documentation is explicit that browser work is "a passive reverse-engineering capability, not a general browser automation or remote-control surface". Results are byte-capped, carry evidence identifiers, and record what the analysis could not establish. Returned target content is flagged as untrusted, which is a sensible prompt-injection defence.

4) If it needs binary files, will it work on web software?

The reverse is true: the web case is well covered, because no binary is needed. The JavaScript bundle is shipped to the browser, and the running page can be observed. The limit is decisive, though: anything server-side is invisible. For a PHP application you can recover the front end, the endpoints and the shape of the payloads; you cannot recover controllers, SQL or business rules. Those can only be inferred from behaviour.

5) What about the costs? Does it burn huge numbers of tokens?

REA itself is MIT-licensed, free, and runs locally with no API account of its own. You pay your coding agent's tokens, plus a licensed IDA if you choose that as your native provider (Ghidra is free and Hopper is inexpensive). The one measured figure I could verify: GNOME Calculator, a 936 KB ELF containing roughly two thousand functions, was reversed and rebuilt in Python in 28 minutes using Claude Code with Opus, with minor UI bugs. I could find no verified figures for a whole application, so treat any you see quoted as unverified. The tool is engineered to bound the spend: byte caps on every result, retained evidence you can re-read instead of re-deriving, and explicit unknowns so the agent stops looping. Scoped to a single feature it is modest; "clone the whole application" is where the bill lives.

6) Nobody installs anything these days, so what is all the fuss about?

REA is a developer's instrument: Node 22.19 or later and npm, plus Ghidra, IDA or Hopper for native targets. It is not something an end user installs, so the fuss is not really about distribution. The genuine shift is that compiled desktop software is now readable at scale, while a web application keeps its logic on a server that nobody can inspect. It is also worth separating two things currently being shared as though they were one: the viral demonstration (a screenshot and a prompt producing a roughly eighty percent functional clone) is a 789-line prompt driving a low-code builder, not the 422,000-line repository.

And as to your bet, Sophie: three days in, I have taken the opposite side of it. GitHub repositories created since 12 October with more than 3,000 stars currently number two, the largest being an Android TV debloater at 3,800 stars. REA itself stands at 332,422 stars and has been pushed to within the hour. A game changer does seem to arrive every week; more often than not it is the same one, recirculating.

On your PS: the honest answer is that pace is not the difficulty, reading the primary sources is. Everything above comes from the tool's own documentation and the clone project's own contributor rules, not from the commentary about them.

Grady, picking up on your reply to Sophie: Does your answer mean that REA reuses the original binary files, and that its approach is therefore more likely to attract legal challenges than the clean-room technique ArtCraft used for their Adobe clones?

When you respond, please talk to me as though I'm a small child, or a labrador.

Simple version, David:

Think of Adobe's program as a cookbook you own.

- REA opens the cookbook and reads the recipes. It doesn't copy the book, doesn't photocopy it, doesn't hand it to anyone. It just reads, and writes its own notes about how a dish is made. The book stays on your shelf.
- ArtCraft deliberately never opens the book. They just eat the food, taste it, and cook something similar in their own kitchen. Their rule literally says: don't look inside, only watch what it does.

So no — my post does not say REA copies Adobe's files. It doesn't. Nothing is reused or shared.

Does reading the book carry more legal risk than only tasting the food? Yes. If you read their actual words and then write your own version, it's harder to prove you didn't copy them. That's the whole reason ArtCraft avoid looking.

But two things to keep straight:

- Reading a book you own isn't automatically a crime. My line about "the legal defence" was about their choice, not a claim that REA is against the law.
- The bigger target for a lawsuit is the one who publishes clones to the world and sells credits — that's ArtCraft, not someone quietly studying an app at home.

And I'm not a lawyer; on a real project, one decides.

I think the main thing here is that REA isn't making the AI smarter. I use AI agents on my PHP repos every day, and they can read the code, follow the logic and work out how things fit together. A compiled binary is a different story. There's nothing readily readable there, so you need tools to make sense of it first. That's really what REA brings to the table. With source code, you don't have that problem.

DC, regarding the token costs, I reckon it's more about what you're asking the agent to do than the harness itself. Asking where an app stores its credentials is one thing. Asking it to reproduce the entire application is another, and that's where the costs can blow out.

The other thing worth remembering is that reverse engineering a web app only gets you so far. You can recover the front end and work out how the requests and responses are structured, but the server-side PHP, SQL and business logic remain out of reach.

There's still plenty to learn from seeing how another app works, but understanding how it behaves isn't the same as having the code that makes it work.

Cheers,
Simon

Thanks! I can certainly think of a couple of apps that I'd love to clone. However, it sounds like a legal minefield. Not sure if I'd want to touch it.