Skip to content
Qubitron Security

4 min readQubitron Labs security team

REA after the hype: what AI reverse engineering can and can't take from your app

REA passed 360,000 GitHub stars in October 2026. What it actually does, what developers found running it on their own apps, and what to change in yours.

  • AI reverse engineering
  • REA
  • App hardening

In October 2026 an open-source project called REA, short for Reverse Engineer Anything, went viral on GitHub. Headlines said it could clone any app. The truth is narrower, and for anyone who ships software, more useful to understand.

What REA is

REA is a toolkit that gives AI coding agents such as Claude Code, Codex, Cursor and Gemini CLI access to established reverse engineering tools, including Ghidra, so the agent can analyse a program it has no source code for. Its README puts it plainly: it "can inspect the app without its source code, explain how the feature works, show the evidence, and build a version for your project."

It covers native binaries, Android packages, Electron apps, .NET and web pages, and the list keeps growing: between 19 and 22 October the maintainers added support for APK signing declarations, Unity IL2CPP metadata, PyInstaller bundles and more.

How fast it spread

Startup Fortune, citing OSSInsight, reported the repository went from under 10,000 stars on 6 October to 234,477 by 14 October. On 23 October, GitHub's API showed 367,203 stars and more than 92,000 forks. Stars measure attention, not use, but attention at that scale means a lot of people now know how to point an agent at someone's app.

What developers found when they tried it on their own apps

The most useful reports come from developers who ran REA against software they own.

  • A macOS app, from the installer alone. A developer writing on DEV gave REA only the installer of their app. It reconstructed the architecture from symbols and strings, and in their words, "drew a clearer picture of my architecture than the one in my own memory."
  • A working web clone of a Mac app. Moe Lueker ran REA through Claude Code on his own Mac app. It identified the stack and helped build a working web version, for roughly $28.60 at API prices. It wasn't seamless: Ghidra timed out on a large file and the analysis was partial. He is clear that "REA does not give you back the original source code."

What REA is not

  • Not a source code recovery tool. It returns pseudocode, structure and behaviour, then helps an agent rebuild something that behaves the same.
  • Not behind every viral clone. Several widely shared "AI clones" of big-name apps weren't made with REA. PBX Science and Lueker both note that the Adobe lookalikes were built from scratch with a different tool. REA's own documentation warns its output can be incomplete or wrong.
  • Not, so far, a documented theft tool. We found no primary source documenting REA being used to clone and sell a named company's product. We'll update this post if that changes.

One genuine incident is worth knowing: on 13 October, a user reported a fake repository copying REA's README and distributing a Windows trojan. The maintainers added a warning that a similar repository name or copied README doesn't make a download official. If your team experiments with REA, install it only from the official repository or package.

What changes for your app

REA doesn't create a new kind of attack. It makes an old one, reading a shipped program to understand and copy it, cheap enough for anyone with an agent and an afternoon. The practical consequences:

  • Obscurity is no longer a defence. Minified JavaScript, a compiled binary or an obfuscated-by-default APK slows a person down. It barely slows an agent.
  • Logic on the client is logic you've published. Pricing rules, scoring, limits, licence checks and feature flags that run in the browser or the app can be read and reproduced.
  • What you ship by accident matters most. Source maps, debug symbols, verbose logs, internal endpoints and embedded keys turn a hard job into an easy one.

What to do

  1. Find out what your build gives away, using the same kind of tooling. That's the honest starting point, and it's what our AI reverse-engineering exposure audit does.
  2. Move what matters to the server. If you'd hate to see it copied, it shouldn't run on the user's device.
  3. Strip what ships by accident: source maps, symbols, logs, test routes and secrets.
  4. Harden what has to stay on the client: obfuscation where it counts, integrity checks and tamper response. App hardening is designed for this, then verified by re-running the tools.

None of this makes an app impossible to copy. It makes copying slow, expensive and unreliable, which for most products is the difference that matters. For a quick first look at your own app, request a free exposure check.

Sources

Keep reading

All posts

Next step

Find out what your app gives away. Book a free exposure call.

Thirty minutes with an engineer, not a sales deck. Tell us what you ship; we tell you what we'd look at first and what an audit would involve.

Book a free exposure callRequest an audit

We only test applications you own or are explicitly authorized to test.