We Reverse Engineered REA, the Viral Reverse Engineer

§ 01What REA actually is#

REA is three things in one package: an MCP server, a CLI, and an agent skill. The skill is the part people mean when they say “one prompt”. It is a 23,510-byte SKILL.md that teaches an agent how to route a target to the right tool, plus six reference guides totalling 50,982 bytes that it tells the agent to read one at a time.

The crucial line is in REA’s own skill, not in the hype: analysis engines are yours, not REA’s.

“REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Kuna, Binwalk, or Unblob. Use existing prerequisites.”

Deep native work still runs on Ghidra, Hopper or IDA. Android still runs on JADX. Packet work still runs on tshark. REA is the layer that decides which one to reach for, runs it, and returns the result in a fixed shape with its limits attached.

That bottom row is the one worth sitting with.

§ 02The 3.16 MB handshake#

An MCP server tells the agent what it can do by answering tools/list. We spoke the protocol directly: initialize, then tools/list, and measured the frame. The server identified itself as rea version 6.7.0, took 2.66 seconds to initialize and 0.92 seconds to answer, and returned 207 tools in 3,158,403 bytes.

The split matters more than the total.

Eighty-one percent of that payload is output schemas: machine-readable descriptions of what each tool returns. Two tools alone, compare_web_captures and inspect_analysis_view, account for 381 KB between them. The part an agent actually reads to choose a tool, the descriptions, is 92,754 bytes, under 3% of the frame.

This is the cost people miss. On October 14, HackerNoon’s Ishank Choudhary measured the same handshake on version 6.4.0 and got 170 tools in 1,954,704 bytes. Four days and three releases later we measured 207 tools in 3,158,403 bytes. The tool surface grew 22% and the payload grew 62% in four days.

Whether your agent pays for all of it depends on the client. Claude Code defers tool search, loading definitions on demand, so the resting cost is small. A client that loads every definition up front pays for the whole frame before the first question.

§ 03We pointed REA at REA#

The cleanest way to test a JavaScript analyzer is to feed it a large JavaScript project. REA ships as one, so we ran its own static analyzer over its own installed package:

bash rea analyze-javascript-application ./node_modules/rea-agents --json > self.json

Zero parse failures across 1,706 files is genuinely good engineering. So is 3.3 million AST nodes in under five minutes. The number that stops you is 234 MB: a single command produced a quarter of a gigabyte of JSON about one npm package, which is roughly 7,300 times the size of the skill file that tells an agent how to use it.

No agent reads 234 MB. REA knows this, which is why its skill opens with instructions to work “summary-first”, ask for the summary detail level, and then page into the retained record by evidence_id. The full record is the ledger, not the answer.

01What REA hands an agent before the first question

02One command, pointed at REA's own package

03The fork that removes the server

1 / 3

←→

§ 04Where it was already caught missing something#

Fast and thorough are not the same as complete. On October 14, HackerNoon’s Ishank Choudhary ran REA 6.4.0 against a real 100 MB Electron app and checked its output against the unpacked source with grep. Most counts matched exactly: five browser windows, two context-bridge APIs, four main-process IPC handlers, six renderer transmissions, five renderer listeners.

Two did not. REA reported zero preload entrypoints and zero exposed API members for an app with two preload files, because the windows load them through a helper call that static analysis could not resolve into a path. On a toy app where he knew every answer, it also missed a sender check hidden behind a helper function.

That is the honest shape of static analysis, and REA’s own limitations say as much. It is also the argument for the discipline below: a zero from a tool that cannot see through a helper call is an unknown, not an absence.

§ 05The real invention is the evidence record#

Strip away the tool count and REA’s contribution is a data shape. Every operation returns one record with the same fields: an evidence_id, the normalized_result, the raw provider output when it differs, the target’s SHA-256, and a confidence and authority label. Our self-run came back with a confidence of derived and an authority of shipped-artifact, meaning: inferred from a file someone shipped, not observed running.

Then come the limitations, and they are the best part of the design. Among the 2,529 our run produced:

“Electron relationships are derived from inert syntax; runtime registration, reachability, defaults, and enforcement remain unproven.”

“Graph coverage is incomplete; unavailable facts remain explicit and must not be read as absence.”

The skill enforces the same discipline on the agent: “Every conclusion must distinguish observations, inferences, and unknowns. Cite Evidence IDs, preserve limitations and incomplete coverage, and never imply that static analysis observed execution.”

That is the anti-hallucination mechanism, and it is a writing rule, not an algorithm. REA’s 47,158 recorded unknowns exist so an agent cannot quietly turn “I did not find it” into “it is not there”. Anyone building agent tools should steal this: a tool that reports its own blind spots is worth more than a tool that sounds certain.

§ 06The fork that deletes the server#

On October 17, a developer published leanrea: one 8 KB skill file, no MCP server, no tools. It tells the agent which plain command to run for each target, asar extract, otool, nm, go version -m, jadx, and leaves the agent to run them in Bash. It had 574 stars within a day.

Its author benchmarked all three arms side by side on Claude Code with Sonnet 5.5: four reverse-engineering tasks, three repetitions each, answers graded against hand-written keys.

Read it carefully in both directions. REA scored perfectly, 75 out of 75, and was the only arm with no misses. It also took 62% longer and cost 55% more than a text file. The bare model with no skill at all scored 67 and refused one task outright, so the skill layer earned its place; the server layer is what the benchmark questions.

The caveats are the author’s own: three repetitions per cell, one model, one machine, three targets, and Ghidra was not installed, so the hardest native path never ran. REA was tested in its best case, with deferred tool loading.

§ 07What we would take from this#

Three things, for anyone building or buying agent tooling.

A skill is cheaper than a server. Most of REA’s value in these tasks is knowing which command fits which file. That knowledge is prose, and prose costs kilobytes. A server costs a handshake, a process, a version to keep aligned, and in this case 3.16 MB before any work happens.

A server earns its keep when it owns state. REA’s own best argument is the part leanrea cannot copy: a session that holds an opened binary, a retained evidence ledger you can page through by ID, and comparisons across two versions of an artifact. Raw commands have no memory between calls.

Evidence beats confidence. The limitations, the unknown counts and the observation-versus-inference rule are the transferable idea here, and they cost nothing to adopt.

And the legal line is worth saying plainly, because the viral posts rarely do: studying a shipped binary is legal in many places and a licence violation in others, clean-room rebuilding has rules, and “the agent did it” is not a defence. REA’s skill carries the authorization language; the posts promising you a cloned paid app in one prompt do not.

We build AI employees on this principle. Every CellCog tier runs Claude Opus 5.5, and when one of our employees reads a system it does not own, we want the same discipline REA’s skill demands: cite the file, mark the inference, name the unknown.