Reverse Engineering with AI: A Deep Dive into REA, the Toolkit That Lets Your Coding Agent Explain…

Meta description: REA is an open-source toolkit that lets AI coding agents like Claude Code, Cursor and Codex reverse engineer apps, binaries and websites. This guide covers what it is, how it works, real examples and an honest analysis.

Quick note before you read: you didn't send me your own analysis, so I wrote the "My Analysis" section from what I found on the site and in the project's public pages. I haven't run REA myself. Please edit that section with your own hands-on experience, since personal observations will make the blog more credible.

Introduction: The Question Nobody Can Answer by Looking

Open Windows Calculator and type 200 + 10%. The answer is 220, not 210.

Most people accept it and move on. A few wonder why. But finding the real answer used to require opening the program in a disassembler, reading hundreds of lines of low-level instructions, tracing which function calls which, and eventually recovering the rule. That takes real skill and a lot of time.

That is the world REA (rea.tools) wants to change. Its tagline is simple: find out how software works. You give your AI coding agent the tools to inspect a program, and the agent explains what it found, in plain English.

In this post I'll cover:

1. What reverse engineering is and why people do it
2. What REA is and how it works
3. How to set it up
4. The two live examples on the site (Chrome's dinosaur game and Windows Calculator)
5. What else REA can analyze
6. My analysis: strengths, limits and who should use it
7. Responsible use
8. Final verdict

Part 1: What Is Reverse Engineering?

Reverse engineering (RE) means finding out how software works by examining the program itself, not by reading its source code or documentation. The REA site frames the goal as understanding a feature well enough to explain it, change it or rebuild it.

People do this for many reasons:

• Learning: seeing how well-built software solves real problems
• Compatibility: making your software work with an undocumented system
• Verification: checking what an app actually does, not what it claims
• Recreation: rebuilding a feature you admire in your own product
• Security research: examining unfamiliar binaries for risky behavior

Why it has always been hard

A traditional investigation usually has three painful stages:

1. Decode the branches. Read machine instructions and work out what each jump and comparison means.
2. Trace the calls. Follow function after function to see where values go.
3. Recover the rule. Turn all of that into a human-readable statement of how the feature behaves.

You also need to pick the right tool, learn its interface and move evidence between programs by hand. That is why RE has mostly belonged to specialists.

Part 2: What Is REA?

REA stands for Reverse Engineer Anything. It is an open-source, MIT-licensed project that connects reverse-engineering tools to your AI coding agent. Instead of you operating the tools, the agent does it.

The project describes itself as a single command-line tool and MCP server for coding agents. MCP (Model Context Protocol) is the standard that lets AI agents use external tools. The practical meaning is that REA gives the work of choosing tools, learning their interfaces and moving evidence around to the agent, using commands, skills, structured results and repeatable investigation workflows. github

The division of labor

The site explains the split clearly:

Works with the agent you already use

According to a third-party listing, REA runs inside agents you may already have, such as Claude Code, Cursor, Codex, Gemini CLI and Windsurf, so you keep paying only for the model access your agent already uses. The same listing says that if you want one workflow spanning native binaries, JavaScript/Electron apps, .NET assemblies and websites, REA is free and open source, with Hopper or Ghidra as optional extras. tt

Part 3: Setting Up REA

Setup is deliberately light. There are two ways to do it.

Option A: Ask your agent. Paste an instruction into your coding agent asking it to install REA with npx rea-agents@latest setup, show you the plan for approval and verify the installation.

Option B: Run it in your terminal:

npx rea-agents@latest setup

npx rea-agents@latest setup

Either way, you:

1. Review the setup plan and approve it
2. Restart your agent so it loads the new tools
3. Start asking questions

The approval step is a good design choice. The tool tells you what it will change before it does anything. The project also notes that you don't need to install the underlying reverse-engineering tools manually, because REA installs and manages them behind the scenes. github

Part 4: Example 1, Why Does Chrome's Dinosaur Get Faster?

The first demo uses the famous offline dinosaur game (a browser edition of it). The question is simple: why does it speed up over time?

The goal

Rebuild the game with adjustable speed. To reproduce the feel of the original, you need its exact rule, not a guess.

The prompt

The site's prompt is essentially: use REA to inspect this dinosaur game, explain why it gets faster, show the speed rule, then build a small version with an adjustable speed.

What REA did

REA connected to the browser through a local debugging connection and returned the script actually running in the page, including its settings. The agent read the update logic and found three numbers:

• Starting speed: 6
• Acceleration: +0.001 on each update without a collision
• Maximum speed: 13

How the answer was verified

This is the part I find most convincing. The team didn't just read the code and trust it. They called the original game's update function in a controlled browser check, with obstacles and automatic scheduling turned off. After 4,000 updates the speed was 10.0, and after 10,000 it reached 13.0. The recovered rule matched the real behavior.

The result

A small playable mini-game with a speed slider, built on the recovered acceleration rule. The drawing, jumping and collision code is a simple teaching implementation, but the speed logic comes from the original.

The three-part workflow

1. REA reads the running game's script and returns its code and settings
2. Your agent rebuilds the rule and adds a speed control
3. You change the speed and play

Part 5: Example 2, Rebuilding Windows Calculator's % Button

This example is a better demonstration of real reverse engineering, because it works on an installed desktop application.

The puzzle

Why does 200 + 10% give 220?

What REA inspected

The site reports the analysis was done on Windows Calculator 11.2508.4.0 (x64) with REA 4.1.0. The agent launched the app, selected its installed library, found the percent handler and read the relevant instructions.

What was found

The percent handler checks which operator came before it:

• After + (or −): the percentage is taken of the first number. 10% of 200 is 20, so 200 + 20 = 220.
• After × (or ÷): 10% simply becomes 0.1. So 200 × 0.1 = 20.

In the machine code, the handler compares the operator against two IDs (0x5b for divide, 0x5c for multiply) and uses the constant 0x64, which is 100 in decimal. A human analyst would look up the IDs, label the branches, inspect helper functions and name the rule. The agent does that chain of reasoning for you.

Cross-checking

The team compared the recovered branch with Microsoft's public Calculator source code and test cases. This matters: a good RE result is checked against something independent, not just believed.

The result

A small calculator that applies both rules correctly.

Part 6: Before REA vs. With REA

Part 7: What Else Can REA Analyze?

The home page points to three main areas, each with its own guide.

1. Native binaries

Inspect functions, strings, references and call relationships in executables and libraries. This is the classic RE use case.

2. JavaScript and Electron apps

Map modules, routes, IPC (inter-process communication) and native dependencies from an application folder or ASAR archive. Many popular desktop apps are built on Electron, so this covers a lot of everyday software.

3. Browser and runtime activity

Capture selected browser or process activity and compare results across runs. This is useful for understanding how a website behaves or what changes between two actions.

Bigger ambitions

The site suggests prompts like:

• "Use REA to inspect this website and clone it" (the page jokes that it means itself)
• "Reconstruct this game from its executable, recover the gameplay logic in C and test it against the original", with a DX-Ball case study linked as the example

A first project for beginners

The site offers a guided "first investigation": download a small Notes example app, trace its CSV export and check what happens when one input changes. It is a low-risk way to learn.

The project's repository also says its longer-term plan extends the same workflow to packaged apps, JavaScript bundles, websites, APIs, protocols, mobile artifacts, firmware, runtime behavior and differences between versions. Treat that as a roadmap rather than a guarantee of what works today. mdskills

Part 8: My Analysis

Edit this section with your own experience.

What impressed me

1. It starts with a question people actually care about. "Why does 200 + 10% equal 220?" is relatable to everyone. Most tool pages start with features. This one starts with curiosity, which makes the value obvious in seconds.

2. The examples are verified, not just claimed. The dinosaur result was tested by running the original update function thousands of times. The Calculator result was cross-checked against Microsoft's public source. For a tool built on AI interpretation, that discipline matters, because an agent can sound confident and still be wrong.

3. The workflow is easy to understand. REA supplies evidence, the agent explains, you decide. The roles are clear, so you always know what is a fact from the program and what is the agent's interpretation.

4. Setup respects the user. Show the plan, ask for approval, verify afterward. For software that installs analysis tools on your machine, this is the right approach.

5. It sits inside tools you already use. There is no new interface to learn. If you already use a coding agent, REA adds a capability instead of asking you to change habits.

6. Open source under the MIT license. You can read the code, see what the tool does and contribute. For a tool that touches other programs' internals, transparency builds trust.

What to keep in mind

1. The examples are deliberately small. A percent button and a speed variable are ideal demos. Real software, with obfuscation, large codebases and anti-tampering protection, is much harder. The site's showcase points to bigger work like DX-Ball, but a small demo doesn't prove that every large app will be this smooth.

2. You still need to judge the answer. The agent explains what the evidence suggests. If you can't evaluate the result, you can't tell a correct explanation from a plausible wrong one. The best practice, which the site's own examples follow, is to test the recovered rule against the original behavior.

3. Some setups may need extra tools. Third-party descriptions of REA mention that parts of the workflow use decompilers such as Hopper or Ghidra, and a listing for an earlier version said Hopper must be installed and licensed. The project has evolved quickly (its tool count has been reported at 42, 50 and more than 70 in different places), so check the current documentation for exactly what your setup needs. socket

4. The project is young and moving fast. Fast development means features improve quickly, but also that details change. Read the current guides before relying on any specific behavior.

5. Legal and ethical judgment is on you. The tool makes reverse engineering easier. It doesn't tell you whether you're allowed to do it. More on that below.

Who benefits most

My verdict in one line

REA won't turn a beginner into a seasoned malware analyst overnight, but it substantially lowers the barrier to asking and answering "how does this software actually work?"

Part 9: A Practical Starter Guide

If you want to try REA, here is a sensible path:

1. Start with the guided Notes example on the site. It is small and safe.
2. Pick a target you own or that is open to study. Your own app, an open-source project or a game you wrote.
3. Ask a narrow question first. "Why does this export put the date in that format?" works better than "explain this whole app."
4. Ask the agent to show its evidence. Request the code, addresses or settings behind each claim.
5. Verify by testing. Change an input and see if the real program matches the agent's rule.
6. Only then rebuild. Use the recovered rule in your own original implementation.

Sample prompts you can adapt:

• "Use REA to inspect [app]. Why does [specific behavior] happen? Show the evidence."
• "Use REA to find where this app handles [feature] and explain the logic step by step."
• "Recover the rule, then write a small test that compares my version with the original."

Part 10: Responsible Use

Reverse engineering sits in a gray area that varies by country, license and purpose. Some guidelines:

• Only analyze software you own, have permission to inspect or that is clearly open to study. Read the license and terms of service first.
• Understanding is different from copying. Learning how a feature works and writing your own original implementation is very different from copying someone's code or assets.
• Respect licenses. REA's own examples credit the original licenses of the things they inspect, and you should do the same.
• Don't use it to bypass protections or harm others. That is outside what this kind of tool is for.
• If in doubt, ask a lawyer. This blog isn't legal advice.

Final Thoughts

For years, the gap between using software and understanding it has been wide. REA narrows that gap by letting your AI agent do the technical grind while you stay in charge of the questions.

What stands out to me is how carefully the examples are presented. They show not only that the agent can explain a result but that the result was tested. That habit of checking is what you should bring to your own investigations too.

If you're curious, run the setup command and ask your agent the same question the site starts with: why does 200 + 10% equal 220? Then try it on something of your own.

Links

• Website: rea.tools
• Source code: github.com/morluto/rea
• Community: Discord (linked on the site)