Rob Shocks calls REA (Reverse Engineer Anything) one of GitHub's fastest-rising repositories. The more useful claim in his hands-on video is narrower: a coding agent can use existing reverse-engineering tools to investigate a compiled program, show an evidence trail, and build a plausible replacement for one behavior. Rob tests that on a small Mac app he wrote himself. The result is impressive, but it is not recovery of the original source, a universal benchmark, or permission to inspect any app.
REA is an MCP server and CLI that makes tools such as Ghidra usable by coding agents. In Rob's controlled test, the agent inferred a hidden unlock rule from a stripped binary and produced a working code; Rob then checked the result against source he had retained. That supports the value of agent-assisted analysis on this target. It does not show that REA reconstructs original source or automatically understands every commercial application.
Watch Rob Shocks Test REA
Credit: The demonstration, test app, and commentary are Rob Shocks'. The video includes a TestSprite sponsor segment. REA is a separate open-source project maintained at the linked repository.
What REA Actually Does
The project README describes agent-facing analysis of native binaries, JavaScript and Electron apps, .NET assemblies, Android packages, firmware, websites, and other supported targets. The exact backend varies. Native-code analysis relies on installed tools such as Ghidra, Hopper, or IDA; REA itself is not a new decompiler. Its contribution is the interface and workflow that let an agent ask useful questions, follow evidence, and report uncertainty.
| REA can help surface | It does not guarantee |
|---|---|
| Pseudocode, assembly, strings, module maps, and call paths from a supported target. | The developer's original names, comments, project structure, or exact source. |
| A traceable hypothesis about how one behavior works. | That the hypothesis applies to every path, version, or environment. |
| Agent access through MCP or CLI over established analysis tools. | That the target is lawful to analyze or safe to execute. |
The installation guide describes a setup flow that previews configuration changes and backs up existing config. Read that plan before approving it, and check the current README for supported runtimes and tool requirements. The repository has an MIT license, but that license covers REA, not the software you analyze with it.
The Stripped-App Test: What Was Proven?
At 04:14, Rob compiles a small Mac app with a hidden unlock-code rule and strips identifying symbols. He gives the binary, not its source, to his agent. The agent searches unnamed functions, narrows the relevant logic, and generates a code the app accepts. Rob compares the inferred rule with the source he kept as an answer key.
This is a useful test because the target and answer key are controlled. It also sets the limit: the agent inferred behavior and wrote its own generator; it did not restore Rob's original codebase. A single small app cannot establish success rates for optimized, obfuscated, network-dependent, or legally restricted software. The observed win is reduced investigation friction, not an end to all closed-source protection.
A Second Case: DX-Ball Reconstruction
The REA team's DX-Ball showcase gives a more detailed example: the investigators used analysis of a legacy game executable to reconstruct a sound-panning function, then compared behavior against the original. The case study reports 3,205 behavioral checks and matching compiled bytes for that one function. The broader DX-Ball reconstruction repo is the place to inspect the work. The showcase says the larger game rebuild is still in progress; one verified function is not a finished game.
These two examples make a better standard for future demos: show the target, the inferred behavior, an independent check, and the parts that remain unknown.
Legal, Security, and Data Boundaries
Permission first. Reverse engineering rights depend on the software, jurisdiction, contract, and purpose. The EU Software Directive includes conditional interoperability provisions; they are not blanket permission to copy a program. U.S. anti-circumvention rules and exemptions add a separate question where access controls are involved. This is not legal advice: obtain written authorization and a purpose-specific review before touching a third-party target.
Execution is not sandboxing. REA's process-capture documentation says runtime observation executes the target with the current user's permissions. Treat unfamiliar binaries and their output as untrusted. Use an isolated test environment, limited accounts, backups, and a human approval gate before running anything. Agent-visible strings, logs, and web content can contain instructions you did not intend to give the agent.
Local tool does not always mean local data. The README notes that analysis can happen locally while results are still sent to the model provider under its data policy. Before inspecting proprietary software, decide which artifacts, pseudocode, paths, and screenshots may leave the organization. Review REA's security notes and your agent's connector permissions.
A Responsible First Test
- Choose an owned target. Use a small app you wrote or a binary supplied with written analysis permission. Keep its original source or test cases as a hidden answer key.
- Set one question. Ask for a narrow behavior such as input validation or a file-format field, not a complete clone.
- Record evidence. Require function locations, observed outputs, confidence, and what the agent could not establish.
- Verify independently. Compare the result with source or black-box tests, including failure cases, before calling it correct.
- Stop at the boundary. Do not move from an authorized test into another vendor's product, DRM bypass, credential extraction, or production execution without a new review.
Rob's most practical point is that closed source alone is a thinner moat when analysis becomes easier. That is his strategic inference, not proof that every proprietary feature is easy to copy. Data, service operations, customer relationships, and sound security architecture remain separate questions.
Jump to a Segment
| Time | Segment | Time | Segment |
|---|---|---|---|
| 00:00 | Intro and claim | 01:04 | What REA is and is not |
| 02:15 | Tool architecture | 03:13 | TestSprite sponsor |
| 04:14 | Hidden-rule demo | 05:59 | The closed-source moat |
| 07:25 | Legal and security catches | 08:21 | What Rob would use it for |
| 08:52 | Outro |
Build a Business Around Authorized Evidence
One credible offer is a small, owner-approved audit of a legacy application's behavior before migration. The sale is a verified decision record, not a promise to clone software. Use this prompt in any capable AI assistant to test whether a buyer and problem are real.
Legacy software, verified
Find one authorized migration or compatibility pilot.
Sources and Limits
Creator: Rob Shocks' REA test and X profile. Project: REA repository, guides and showcases, DX-Ball case study, and reconstruction source. Underlying tool: Ghidra. The video's star-growth framing is time-sensitive and was not used as a measured ranking. Product support and project security guidance may change; verify current documentation before installation.