How to Reverse Engineer an App with Claude Code

Reverse engineering means studying a finished piece of software to understand how it works, usually without having its original source code or any of the design documents that went into it. You look at what it does, how it is put together, and what it talks to, and you work backward from that to a model of its behavior.

People do this for reasons that are mostly unglamorous and mostly legitimate. Security researchers reverse engineer programs to find a vulnerability before someone with worse intentions does. Developers reverse engineer file formats and network protocols so a new program can interoperate with an old one that nobody will document for them. Archivists and hobbyists reverse engineer old software to keep it running once the original hardware and the company behind it are both gone. And sometimes the reason is simply that a program you depend on does something undocumented, and you need to know what, before you can trust it or work around it.

None of this is new. Security researchers and software archivists have been doing it for decades with disassemblers and debuggers, long before any AI agent existed. What has changed is speed: an agent can read a disassembly listing or a decompiled method and summarize it in seconds, work that used to take a skilled person hours. That is a real capability gain, and it is exactly why the legal and ethical line later in this guide matters more now, not less, since the bottleneck that used to slow people down between curiosity and copying has mostly disappeared.

The rest of this guide is specific: it walks through one tool, called REA, that connects an agent like Claude Code to this kind of analysis, and the habits worth having in place before you point it at anything.

The distinction that matters most here is the one between studying how something works and copying its protected expression. Reverse engineering to learn an interface, a file format, or a piece of behavior is, legally, a different act from lifting someone else's code or assets into a product of your own.

The practice built around that distinction is called clean-room design. One person or one session studies the original and writes a plain specification of what it does: its interfaces, its data formats, its behavior, in their own words, with no original code copied into the document. A separate person or session, who never saw the original, then builds a new implementation from only that specification. The point is that the final result can be shown to have come from a written description, not from the original work itself.

Two older US court decisions get cited often on this point, and they are worth knowing about, though neither is a general license to reverse engineer anything. Sega Enterprises Ltd. v. Accolade, Inc., decided by the Ninth Circuit in 1992, involved a company that reverse engineered a game console's lockout system so its own games would run on that console. The court held that the intermediate copying involved in that reverse engineering, done to reach unprotected functional elements needed for the games to work on the hardware at all, was fair use on the specific facts of that case. Sony Computer Entertainment, Inc. v. Connectix Corp., decided by the same court in 2000, reached a similar conclusion when a company reverse engineered a console's startup software to build an emulator for a different kind of computer, again treating the copying along the way as fair use in service of an independently written, interoperable product.

Treat both of those as historical context, not as advice for your situation. They are two specific appellate decisions about specific facts, fair use is decided case by case, other countries draw these lines differently, and later laws aimed at circumventing copy protection narrow this considerably for software tied to DRM. Anyone planning to build on this kind of work, especially anything meant to ship or be sold, should talk to an actual lawyer before relying on any of it.

REA draws its own line independently of what a court might eventually decide about any particular case. Per the project's DISCLAIMER.md, REA does not support and will not help with circumventing DRM, license checks, anti-cheat systems, or other technical protection measures, or with copying proprietary software or its protected code and assets, and the project says plainly that analysis output does not grant any rights to the original program. The practical rule that follows: only analyze software you own, wrote yourself, or are otherwise authorized to examine.

Node.js version matters here. REA's own README states its requirement exactly as: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), or 26.12.1+, plus npm. Check that against the live README before you install, since this kind of requirement changes between releases.

The setup command is npx rea-agents setup. Per the README, it walks you through choosing which agents to register REA with, shows you the changes it proposes to make before you approve them, and keeps backups of your existing configuration. Restart your agent afterward so it picks up the new MCP server; REA's own instructions say this plainly.

For a persistent command-line install rather than a one-off npx run, the README describes npm install --global rea-agents, followed by rea --help to see what is available. From a global install, rea update moves you to a new version on your own schedule instead of automatically, and running npx rea-agents@latest setup afterward refreshes the agent registration to match.

Before pointing REA at anything you do not fully own, try it on a tiny application you wrote yourself first. With REA set up, ask Claude Code to open that small app and describe what it sees, function by function, and compare that against what you already know you wrote. That one exercise confirms the setup actually worked, and it gives you a feel for how REA's evidence, a file, a function, a call, reads in practice before you lean on it for anything that matters.