mrkeyoor.com_
Tue 06 Oct 15:54 UTC
Open Source6 min read

REA Adds 2,963 Stars in a Day for Evidence-First Reverse Engineering

REA's breakout turns Hopper and Ghidra into tools an agent can call. Its evidence records are the useful part, and its security limits deserve equal attention.

MrKeyoor's tracker counted 2,963 new GitHub stars for REA in a single day as the project moved a job that usually starts in Hopper or Ghidra into the same session where a coding agent writes code. The MIT-licensed project lets an agent inspect an application, trace a feature through recovered artifacts and use the findings while implementing a similar feature. That star burst is interesting because the repository asks developers to accept a stricter idea than "ask an AI how this app works." It gives the model tools for collecting evidence, then keeps the gaps attached to the answer.

The timing matters. REA 4.0.0 arrived on October 5 with a long list of breaking changes, and a small 4.0.1 packaging fix followed 25 minutes later. The 4.0.0 release removed several replay and policy commands while expanding native inspection and agent integrations. A day later, MrKeyoor's tracker recorded the 2,963-star jump. Interest is landing on a release that has narrowed parts of its interface rather than simply adding another pile of agent tools.

The missing layer between a prompt and a binary

A coding agent can already read source files, search a repository and run tests. A closed desktop app presents a different problem: there may be no source tree, names can be stripped, behavior may sit across native code and web views, and a plausible explanation can still be wrong. REA's investigation model breaks that work into decompiling an artifact, following the recovered clues and recreating only the behavior the developer needs. The project explicitly says it does not recover original source code or clone an application automatically.

That distinction shapes the product. REA is a TypeScript CLI and Model Context Protocol server that connects an agent to local analysis providers. Its documented setup supports Claude Code, Codex, Cursor, Gemini CLI, Windsurf and several other clients, while manual MCP configuration is available for other agents. The recommended entry point is short:

npx rea-agents setup

Setup is still an operation to review. According to the installation documentation, it previews the paths and configuration changes, backs up existing configuration and asks separately before installing Hopper. An existing Ghidra installation can be registered, but REA does not download Ghidra or Java. This is a better fit for a developer workstation than an opaque hosted reverse-engineering service, provided the developer reads the plan before approving it.

What the agent can inspect

The current tool catalog spans native binaries, JavaScript and Electron applications, .NET assemblies, browser pages, archives and controlled process runs. Native providers expose functions, pseudocode, assembly, strings, symbols, calls and references. Static JavaScript analysis maps modules, imports, routes, IPC channels, storage and native add-ons without executing the extracted code. Browser tools can record page structure, network metadata, scripts and screenshots from a selected Chrome-family target.

Those modes are deliberately different. Passive browser observation does not click, navigate or evaluate page JavaScript, while a declared Playwright scenario can interact with a page and record what happened. A static map can find an IPC channel without proving that the channel ran. REA's browser observation guide also says it cannot recover activity that happened before attachment. The boundaries help stop a model from turning "I found this code path" into "the app definitely took this path."

For native work, the agent can open Mach-O, ELF and PE targets through Hopper or Ghidra. The README describes a typical search as a chain: identify the binary, search strings and procedure names, follow cross-references, reconstruct control flow, then decompile the relevant routines. REA performs the inspection steps; the coding agent handles the final implementation with its normal editing and test tools. That separation is useful because generated code can be tested in the developer's project even when the recovered explanation remains incomplete.

The breadth comes with real prerequisites. REA requires supported Node.js releases, and its main setup requirements name recent macOS and Linux versions. Deep binary work needs Hopper or Ghidra, each with its own installation and platform constraints. Hopper's demo carries vendor-defined limits. Ghidra needs a supported JDK and matching native decompiler components on macOS. Running rea capabilities or rea doctor --json is more informative than assuming every command shown in the README will work on a particular machine.

Evidence is the useful output

The project's best design choice is its Evidence record, described in the README as a bundle of artifact identity, provider, locations, confidence and limitations. Results can be exported, imported and compared. Snapshots are reused only when the target bytes, operation, parameters, provider and settings match. The files remain local with owner-only permissions, according to the documentation.

That gives the agent something more durable than a block of decompiler text pasted into a chat. A finding can retain which artifact produced it, which tool observed it and what the tool could not resolve. REA also tracks open questions and contradictions. Reconstruction checks return pass, fail or unknown, so absent evidence does not quietly become a passing result. These details matter more than the prompt syntax because they make a later human review possible.

The same caution appears in the project's descriptions of comparisons. Static findings can be connected to runtime observations, but correlation is not labeled as causation. Missing or truncated capture data cannot prove that two runs behaved the same way. An agent can easily write a clean narrative over messy evidence. REA cannot prevent a model from reasoning badly, though its output format leaves more material for a developer to challenge.

A smaller interface arrived before the surge

REA 4.0.0's changelog tells existing users to refresh tool schemas and migrate removed fields. Controlled replay, Node characterization, custom checkpoints, policy commands and several permission-related inputs disappeared. Unscoped setup now refreshes existing REA-owned registrations; configuring every detected client requires the explicit --all-detected option.

At the same time, version 4 added DOS MZ analysis in the Ghidra path, more native inspection primitives and expanded agent integrations. The release notes list fixes across ASAR handling, browser capture, JavaScript scope analysis, managed-code metadata and native binary parsing. Version 4.0.1 did not add another feature set. Its sole listed fix allows time for a new package version to propagate through npm. Anyone evaluating the project should pin an exact release in persistent MCP configuration, as the README recommends, rather than letting a major update change the available tools mid-investigation.

Local analysis carries local authority

REA says analysis stays on the supported host and is not uploaded to a hosted analysis service. That does not make an investigation isolated. The project's security policy is direct: REA is not a sandbox, and opening an untrusted binary delegates parsing to Hopper or Ghidra with the current user's permissions. Its local bridge uses a random capability token and a current-user Unix socket, but those controls do not protect against a malicious process already running as that user.

Process capture has the same boundary. It launches the declared executable and scenario with the user's permissions. The process-capture documentation describes observation and comparison, not safe execution of hostile software. Developers examining malware or an unknown download still need an isolated lab, disposable environment and the authorization to analyze the target. A local MCP server does not supply those controls.

There is also a data path beyond REA itself. The README notes that the chosen agent or model provider has its own data policy. REA can keep an application and its generated evidence on the workstation, yet an agent may send selected context to a remote model. Teams working with proprietary binaries need to inspect both sides of that route before using the convenient one-line setup.

The next useful signal will come from investigations that other developers can reproduce, especially across the same binary with Hopper and Ghidra. Watch whether exported Evidence records make disagreements easier to audit, whether issue reports expose gaps between static and runtime findings, and how quickly integrations adapt to version 4's removed fields. The star count says developers want agents closer to the artifacts. The harder test is whether the records they leave behind are strong enough for another person to verify.

We reviewed this

  1. rea — our honest review

Sources

  1. REA GitHub repository and README
  2. REA 4.0.0 release
  3. REA changelog
  4. REA installation documentation
  5. REA security policy
  6. REA browser observation documentation
  7. REA process capture documentation