REA: asking your coding agent how someone else's app does it

By Seyed Masoud Hosseini · Oct 14, 2026 · Engineering

You see a feature in an app and wonder how it works. REA is an open-source tool that lets a coding agent like Claude Code answer that question by inspecting the app itself, with no source code. What it is, how it works, what its case studies actually show, and where the legal and practical lines are.

You've seen it a hundred times. An app does something small and clever: a search that feels instant, a copy and paste that keeps its formatting, a sound that moves left and right with the action on screen. You want the same thing in your own product, and the only way to learn how it's done is to guess.

REA ("Reverse Engineer Anything") is an open-source project that replaces the guessing with evidence. You ask your coding agent, in plain words, how a feature in an app works. The agent uses REA to look inside the app itself (no source code needed), traces the feature, shows you what it found and how sure it is, and can then build a version for your project.

It's also one of the fastest-growing repositories on GitHub this year: created in April 2026 and past 200,000 stars by October. That alone is a reason to understand what it is. This post covers what REA does, how it works, what its own case studies show, and the limits you should know about before you point it at anything.

What reverse engineering means here

When a company ships an app, they ship the result of their code, not the code itself. For a native program that's machine code: millions of bytes a processor understands and people mostly don't. For a desktop app built on web technology (Notion, Slack, VS Code and many others are built with a framework called Electron) it's bundled and minified JavaScript: technically readable, but squashed into huge files with meaningless names.

Reverse engineering is working backwards from that result to an understanding of how it works. Specialists have done this for decades with tools called disassemblers and decompilers. Ghidra (free, released by the US National Security Agency), IDA and Hopper turn machine code back into something closer to readable code. They're powerful and they take years to use well.

REA doesn't replace those tools. It puts a layer on top of them that an AI agent can drive.

How REA works, in one minute

REA is an MCP server. MCP (Model Context Protocol) is the standard way to give an AI agent extra tools. Once REA is registered, your agent (Claude Code, Codex, Cursor, Gemini CLI and others) gets a set of new abilities: open a binary, list its functions, decompile one, find who calls it, analyse a JavaScript bundle, watch a website's network requests, and so on.

The loop looks like this:

1. You ask a question: "How does search work in this app? Show me the evidence."
2. The agent calls REA's tools to inspect the app, follow the relevant code and read the details.
3. REA returns what it found, with the evidence attached: the addresses, the instructions, the files, and what it couldn't determine.
4. The agent explains the behaviour, or writes and tests an implementation of its own.

Everything runs on your machine. REA doesn't upload the app anywhere. (Your agent does send the results to its model provider, as with anything else you ask it.) The same tools also work from the terminal without an agent, through a rea command.

Evidence, not just answers

The part I find most interesting isn't the decompiling. It's that REA is built around Evidence as a first-class idea. Every result says what was observed, what was inferred, and what stayed unknown. The project's own guided workflows tell the agent to keep those three apart.

This matters because AI agents are very good at producing a confident, plausible explanation. Reverse engineering is a field where plausible and true diverge often: a decompiler can show you a function with no inputs that actually takes one, or a name that means nothing. A tool that hands the agent the raw evidence, and forces the gaps into the open, makes it much harder for the agent to quietly fill them with a guess. You can check the claim yourself.

What it can look inside

The list is long and growing every release. The main ones, in plain terms:

Two things stand out. First, a lot of it works without running the target: static analysis reads the files and nothing more. Second, the JavaScript and .NET analysis needs no specialist tool at all, which makes those the easiest place to start.

What the case studies actually show

The project publishes worked showcases. They're worth reading in full, because they show both what REA can do and how much a human still does.

Notion: how copy and paste keeps its formatting

The question: when you copy blocks in the Notion desktop app, how do they get to the system clipboard, and how does pasting bring the blocks back?

REA analysed the app's packaged JavaScript and found the API the page can call (window.__electronApi.clipboard) and that it sends a message to the main process. The author then followed the wrapper functions by hand to the receiver. The result is a clean picture: one IPC channel, notion:clipboard:write, joins the two sides. The receiver checks the request comes from a Notion window and writes text and HTML to the clipboard. The HTML carries a hidden comment with a copy ID, and Notion keeps the full block data locally under that ID. When you paste and the ID matches, you get your blocks back. If it doesn't, you get plain text and HTML.

That's exactly the kind of answer that's useful if you're building an editor: a design pattern, not code to copy. And the write-up is honest that REA found one side and a person connected the other.

DX-Ball: rebuilding a 1996 game function in C

The question: in the old Windows game DX-Ball, how does the position of a brick turn into a left or right sound pan?

The first decompiler view was misleading: a function that seemed to take no input. REA's instruction view showed the real input on the stack, its caller showed the input was 20 + 30 × tile_x, and reading the raw bytes gave the constants (1.5625, 500.0 and a scale of 1.0). The agent then wrote a C function: at normal scale it returns −500 at the left edge, 0 in the middle and 500 at the right.

The verification is what makes it convincing. The C version was tested against the original x86 code on 3,205 inputs, and when compiled with the same 1996 compiler it produces the same 63 bytes as the original. That's not "looks right". That's proof.

The pattern in both: REA is good at getting to the right place quickly and showing exactly what's there. The judgement (which lead to follow, what the evidence means, whether the result is correct) is still yours and the agent's, and the best results come with a test that checks against the original.

Getting started

You need Node.js (22.19+, 24.11+ or 26+) and npm. Then:

npx rea-agents setup

It asks which agents to set up, shows you the changes it will make to their configuration (and backs up the old files), and waits for your approval. Restart your agent afterwards.

Then ask it something, in plain words:

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

For native programs you also need a disassembler. Ghidra is free and the simplest choice. Hopper is a paid Mac and Linux tool with a demo mode (setup can install it with your approval). IDA works if you already own it.

If you'd rather start without an agent, the JavaScript analysis runs straight from the terminal on an extracted Electron app or an .asar file:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

A practical warning from the docs: the full evidence for a real app can run to hundreds of megabytes (their Obsidian example is 334 MB). Save it to a file and ask for a summary view, which shrank that example to about 10 KB, rather than pouring the whole thing into your agent.

REA moves fast. Version 6.5.0 came out on 13 October 2026, and the project says plainly that new releases fix a lot of bugs. Update often:

npx rea-agents@latest setup

Where the lines are

This is the section not to skip. Reverse engineering is legal in many situations and illegal in others, and the rules differ by country and by the licence of the software you're looking at. REA's disclaimer is unusually clear about it.

It's built for: security research, malware analysis, finding and responsibly reporting vulnerabilities, CTF competitions and learning, making software work with other software, preserving old software, and examining software you own or are allowed to examine.

The project says it won't help with: breaking DRM, licence checks or anti-cheat; making game cheats; getting around logins or bot protection on systems you're not allowed to test; and copying proprietary software or its protected code and assets.

That last one is the line that matters for "I want that feature in my product". Learning how an app solves a problem and building your own version from that understanding is one thing. Lifting its code is another, and owning a copy of the app doesn't give you the right to reuse what's inside it. The Notion case study is the good model: it ends with a design pattern (an ID in the HTML, data kept locally), not a block of Notion's code.

Three more things worth knowing:

• Some workflows run the target. Static analysis only reads files. Runtime capture, browser observation and especially Frida instrumentation actually execute or modify the app, with your user permissions. For anything you don't trust, use a separate machine or a virtual machine.
• Commercial tools keep their licences. REA doesn't give you a licence for IDA, Hopper or JEB. A trial or demo is still bound by the vendor's terms, including how you may automate it and share its output.
• Only install from the official sources. The README warns that a similar repository name or a copied README doesn't make a download genuine. Get it from github.com/morluto/rea, rea.tools or the rea-agents package on npm. For a tool that's going to open binaries on your machine with your permissions, that's not paranoia.

When it's worth it

Use it when you have a specific question about software you're allowed to examine, and the answer is buried in a build rather than a document. How does this app talk to its backend? Why does this old program crash on this input? What libraries is this binary built with? What changed between version 3 and 4? Those are the questions it's designed for, and its guided workflows cover several of them directly (trace a feature, compare two versions, trace a crash).

Don't expect a full rebuild of an app from one prompt. Both case studies cover one function or one path, carefully. The DX-Ball project, after a lot of work, has 55 functions rebuilt and the game still isn't playable. Decompiled code can be wrong, and the docs say so.

Do expect to read the evidence. The whole point of the tool is that every claim comes with the thing it's based on. If you only read the agent's summary, you've thrown away the best part.

Cheat sheet

Set up (once)
  npx rea-agents setup                 pick agents, review, approve, restart
  install Ghidra (free) if you want native programs

Ask
  "Understand how <feature> works in <app>, show me the evidence,
   and build a similar feature for my project."

From the terminal
  npx -y rea-agents@latest analyze-javascript-application /path/to/app --json
  rea analyze /path/to/program --provider ghidra --json
  rea decompile /path/to/program <address> --provider ghidra --json

Keep it current
  npx rea-agents@latest setup   (or: rea update)

Before you start
  Am I allowed to examine this?   Is it running or just being read?
  Am I learning the idea or copying the code?

The short version: REA turns "I wonder how they did that" from a guess into a question you can actually answer, with your agent doing the tedious part and the evidence there for you to check. Use it on things you're allowed to look at, read what it shows you, and build your own.