I Tested REA (Reverse Engineer Anything) on My Own Tool — Here's What It Actually Found

CluoPrints — Sun, 08 Nov 2026 19:56:08 +0000

I had seen REA — Reverse Engineer Anything — mentioned everywhere, so instead of repeating the hype, I decided to test it on something I know inside out: my own tool.

That is the important limit of this post. I tested one tool, my own, once, in a controlled setup. What follows is what actually happened — including the parts REA missed.

The full, step-by-step version of this test, with the exact commands and prompts, is here: REA (Reverse Engineer Anything): What It Is, How to Install It, and What It Can (and Can't) Do — A Hands-On Test. The companion repo is CluoPrints/rea-tutorial on GitHub.

What REA is

REA is an open-source MCP server and CLI by morluto. It connects reverse-engineering tools such as Ghidra, IDA, Hopper and JADX to AI coding assistants including Claude Code, Codex, Cursor and Gemini CLI.

In practice, that means you can ask in plain English — "Where is the image export code?" or "Does this app upload anything?" — and REA translates the question into a decompiler or disassembler call, then returns the answer with evidence such as a function name, a file, a line number or a byte offset.

It is MIT-licensed. It does not bundle Ghidra, IDA or the other engines, and it does not include licences for commercial tools such as IDA. Those are separate.

Installing it took about 40 seconds

I tested version 6.8.0 on Ubuntu, with Node v24.22.1 and npm 10.9.4. The install was:

npm init -y
npm install rea-agents@6.8.0
./node_modules/.bin/rea --version
# 6.8.0
./node_modules/.bin/rea doctor

rea doctor reported that no native engines were installed. That turned out not to be a blocker for my test: static JavaScript and .NET analysis works without an engine. I also noted the other engines need their own setup, which I did not test.

The test target: my own Social Image Sizes tool

I chose my own Social Image Sizes tool because I already knew the correct answers, so I could check REA instead of trusting it.

The tool lets you upload an image, pick one of eight social-media sizes, crop or fit it, choose an output format and quality, and download the result. The test input was four files, which REA parsed into 2,869 AST nodes and a 2.9 MB JSON output.

My questions were the ones a developer or security reviewer would actually ask:

Where does the image export happen?
Does the image ever leave the browser?
What does the app store, and where?
What happens if the original image is smaller than the chosen preset?

Attempt 1: it worked, but with a warning I should not have ignored

The first run completed in about five seconds and produced a 15,835-byte answer. It correctly found the AdSense script and the cookie-consent code that writes to localStorage.

But it also said, in its own output, that "2 inline JavaScript bodies … were not analyzed." That was the warning. The most important logic in my tool lives in inline scripts, and the first attempt had skipped it.

So I ran it again, explicitly asking it to analyse the inline scripts.

Attempt 2: this time, the answers were checkable — and mostly right

The second run reported zero parse failures. More importantly, I could verify its claims against code I had written myself. It got these right:

The export function: it located drawPreset() at byte offset 2921 — exactly where it is.
How the export works: canvas, 2D context, drawImage, toBlob and URL.createObjectURL, plus the PRESETS table, fillStyle and fillRect.
The upscale warning: it found the exact user-facing string, "Upscaled from a smaller original — may look soft."
The Android fallback: it found the setInterval polling fallback, running every 400 ms.
Privacy: it reported zero network calls, and that the only thing stored is the cookie-consent flag — cookie-consent in app.js, line 63, exactly. The image is processed locally and never uploaded.

That last point is the kind of answer that matters in a review: it is specific, it names the file and line, and I could confirm it. REA did not just say "this app is safe." It said what it checked and where.

What it missed

This is the part that would be lost if I only quoted the successes. REA did not recover:

The preset dimensions themselves — 1080×1080, 1080×1350 and 1080×1920, for example.
The crop-versus-fit logic, Math.max versus Math.min.
The output format and quality settings, which live in HTML dropdowns rather than in the JavaScript it analysed.

It also left 654 unknowns in its output. That is not a small footnote. It means the analysis was partial, even on a small, plain JavaScript tool with no obfuscation.

So the honest summary is: the structure was accurate, and the specific function, storage and network answers were verifiable — but the data coverage was partial.

What REA cannot do

Based on this test, and on what the tool itself reports, a few limits are worth stating plainly:

It cannot recover original source code, and it cannot clone an app.
It gives you a partial view of the program, not a complete one. The 654 unknowns above are the evidence for that.
Without a native engine installed, it cannot do deep native analysis.
Static analysis does not run the app, so it cannot tell you what happens at runtime.

If you point it at a binary you do not own or do not have permission to analyse, that is a legal and ethical problem, not a technical one. I only tested my own tool, and I would only use REA on code I own or am authorised to review.

One practical warning from my own notes: only download REA from the official places — GitHub morluto/rea, rea.tools, or npm rea-agents. Fake copies and lookalike repos are a known risk with popular tools, and the repository I used for this test is the companion repo linked above, not the REA project itself.

My verdict

REA is a genuinely useful assistant for reverse engineering: it is fast on a small target, it answers specific questions with locations you can check, and on my own tool its structural answers held up.

It is not a replacement for reading the code, and it is not a way to recover a lost codebase. The first attempt quietly skipped the inline scripts, the second still left hundreds of unknowns, and the data-level details — the actual dimensions, the crop logic, the format settings — needed a human reading the source.

Use it to find where to look, and to check privacy and storage questions quickly. Then verify the answer yourself, especially before you trust it on code you do not know.

If you want the commands, prompts and full results, the complete tutorial is here: https://cluoprints.com/rea-tutorial.html. The companion repo is https://github.com/CluoPrints/rea-tutorial.

This post is a condensed rewrite of my own hands-on tutorial and test above. It is based on the same single test of my own tool, version 6.8.0, and adds no new results.

DEV Community: CluoPrints