REA: Reverse Engineer App Behavior and Native Binaries with Agents

Who it’s for

REA is for people who need reverse engineering inside their agent: developers and maintainers who want to understand what an application actually does, or who need to inspect native binaries, JavaScript and Electron apps, .NET assemblies, and websites; it equally fits those maintaining Electron desktop apps or .NET services who want to see what a third-party dependency or a historical build really does. It wires these inspection tools into your agent, the same tools also work directly in the terminal, and the analysis runs locally. The test is simple: if the question you need to answer is “what does this program or file actually do,” and the answer is hidden in binaries, bundled artifacts, or runtime behavior, it is worth installing. When it does not fit: the target is not a file or application you are authorized to inspect; your environment cannot install the Node.js version it requires; or what you want is a purely online scanning service that never touches local files.

First attempt in 3 minutes

There is exactly one recommended main path: use the official setup command to register REA’s MCP server and install the matching instructions, then restart your agent.

npx rea-agents setup

Prerequisites: Node.js 22.x (at least 22.19), 24.x (at least 24.11), or 26+, plus npm, already installed locally. Run the command above in a terminal; it registers the MCP server and installs the matching usage instructions. If the hookup fails, first check that your Node.js version meets the requirements above.

After restarting, make one low-risk call to confirm the hookup: ask the agent to run a static inspection of a local JavaScript file. Before the action, state its nature — the official documentation states that static JavaScript and .NET inspection only reads the files you provide and never runs the application, so this step will not launch the target program. Observable success signals: the setup command completes, and the restarted agent can return inspection results for that file, meaning the REA tools are now available in your agent. The official documentation does not list each tool’s exact names and parameters; what counts is the list of tools the agent registers after the restart. Besides invoking them through the agent, you can also use the same tools directly in the terminal, which the official documentation describes as a secondary usage.

Use cases

Case 1: understand a JavaScript file without running it. Scenario: you receive a bundled or obfuscated JS file and want to know what it does before deciding whether to execute it. Approach: hand the file path to the agent and let it analyze the file with REA’s static JavaScript inspection. Expected result: the agent reads the file and reports its conclusions without ever executing that code; the same applies to .NET assemblies, where static inspection likewise only reads files; static findings and runtime observations can also corroborate each other.

Case 2: capture a target’s runtime behavior. Scenario: static analysis reveals nothing and you need to observe how the program actually runs. Before acting you must confirm the side effects: the official documentation states that runtime capture runs or interacts with the selected target under your user permissions, and each runtime guide describes its own effects; after confirming the target and its impact, have the agent run the capture. If the target involves real user data or a production environment, validate the steps on an isolated copy first. Expected result: the agent returns information about the target’s runtime behavior; exactly what gets changed is governed by the corresponding runtime guide.

Boundaries of use

Distinguish read from write: static JavaScript and .NET inspection only reads files and never runs the application; runtime capture is an operation with real effects that runs the target or interacts with it under your user permissions. The official documentation provides no unified undo path, so do not assume any step is reversible.

On where analysis happens, the official documentation states that REA analyzes targets locally; this only describes where the analysis occurs and is not a security conclusion, and this guide makes no independent judgment about data flows or privacy boundaries either. Where analysis artifacts are stored locally and how to clean them up is not explained on the official page and remains unconfirmed.

Information the official page does not list and that you should confirm before acting: the exact names and parameters of each inspection tool, the supported operating systems and agent clients, whether account credentials are required, and the specific entries of each runtime guide. Version requirements may change as the project evolves; before running setup, the current wording on the official page is what counts.