REA Lets Claude Code and Codex Reverse Engineer Any App, So Treat Your Shipped Client as Readable

The #1 repo on Trendshift this morning gives coding agents 39 native inspection tools as a local MCP server. Here is what that changes for anyone who ships a desktop app.

Reverse engineering used to have a skill floor. You needed to read assembly, know your way around a disassembler, and have the patience to rename a few hundred functions before anything made sense. That floor kept most shipped software opaque to most people, and a lot of product security depended on it, even when nobody said so out loud.

morluto/rea removes most of that floor. Its tagline is "Reverse engineer anything with agents, from app behavior down to native binaries," and it sat at #1 on Trendshift's daily board when I read it at about 07:26 ET on October 5. One setup command wires it into Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI and Windsurf as a local MCP server. After that, "how does this app decide whether I'm on the paid plan?" is a question you type, not a weekend you spend.

That is a useful tool. It is also a change in the threat model for every team that ships a client.

What REA actually exposes to an agent

The README describes 39 native inspection tools and 15 investigation workflows. The native side covers what you would expect from a disassembler: functions, pseudocode, assembly, strings, symbols, calls and cross-references, plus utilities for Mach-O metadata, code signatures, plists and Swift demangling. It reads Mach-O, ELF and PE binaries, so macOS, Linux and Windows executables are all in scope.

The part that should get product teams' attention is everything above native code. REA maps JavaScript and Electron modules, reads source maps, and runs static analysis without executing anything. It inspects .NET metadata and CIL instructions and compares builds. It can observe websites too: page structure, network metadata, scripts, and screenshots you approve.

The workflows matter more than the tool count. App overviews, batch decompilation and "cross-layer feature traces" are the steps a human reverser chains by hand. REA packages them so an agent can chain them for you, and the project says "results include the evidence and limitations behind each conclusion." That is the right design. An agent that tells you how a feature works should show you the function it read.

Two releases explain the momentum. v3.1.0 on August 9 added autonomous Electron runtime analysis. v3.2.0 on October 3 focused, in the maintainer's words, on removing artificial limits and returning complete results inline, and v3.2.1 followed the same day with a fix for npm registry propagation delay.

The safety design is decent, and it points the wrong way for you

REA is careful about the person running it. "Analysis runs locally," per the README, and targets are not uploaded to hosted services. Runtime observation is off by default and needs explicit configuration and approval. JavaScript replay runs in a sandbox.

All of that protects the analyst's machine. None of it protects the app being analyzed, and nobody should expect it to. The README, as far as I could find, offers no guidance on what you are authorized to take apart. That is normal for reversing tools, which have always left the legal question with the user. It means the only thing standing between your client and a curious agent is whatever you shipped inside it.

Electron's own documentation is honest about that. It says ASAR archives help "conceal your source code from cursory inspection." Cursory is the key word. An agent with a module mapper and a source-map reader does not do cursory.

What becomes readable

Run through what a typical desktop or Electron product keeps in the client, and ask how it holds up against an agent that can trace a feature from the button to the function.

API keys and service tokens embedded for convenience. Feature flags and plan checks evaluated locally. License validation that returns true or false in client code. Internal endpoint URLs and undocumented API shapes. Source maps accidentally shipped with a production bundle, which hand back near-original code. Prompt templates and system prompts for your own AI features, which live as plain strings in a surprising number of apps.

None of these were ever secret in the strict sense. A determined person could always find them. The difference now is cost. When the explanation takes one prompt to a coding agent the user already has open, "determined person" stops being a filter.

Web developers learned this rule a long time ago. Anything sent to the browser is readable, because view-source and the network tab ship with every copy of Chrome. Good web teams stopped trusting the client years ago and moved every decision that matters to the server. Desktop and mobile teams got to skip that lesson, because a compiled binary or a packed Electron bundle felt like a locked box.

REA is the moment that box opens for everyone. The rule web teams live by now applies to every client you ship, whatever language it is written in and however it is packaged. If a decision would hurt you when a user flips it, it does not belong in code that runs on their machine.

Put this into practice

Start with your own build. The fastest way to learn what REA can see in your app is to point it there before anyone else does.

Install it in a throwaway environment. npx rea-agents setup on Node 22.19 or newer registers the MCP server with the agents it finds. The README pins the server in config as npx -y rea-agents@3.2.1 mcp; keep a pinned version rather than tracking latest, since this server runs locally with read access to whatever you point it at.
Ask your agent the questions an attacker would. "Where does this app check whether the user has paid?" "List every hard-coded URL and credential-looking string." "Is a source map present, and what does it reveal?" Read the evidence it cites, not just its summary.
Move enforcement to the server. Any check that gates money, access or data belongs where the user cannot edit it. Treat client checks as user experience, not security.
Pull secrets out of the bundle. Rotate anything REA finds. Use short-lived tokens issued by your backend instead of keys baked into the binary.
Strip source maps from production builds, or host them privately for your error tracker.
Use it for the legitimate jobs too. REA is a strong tool for figuring out why a third-party integration breaks, how a closed SDK actually behaves, or what your own legacy binary does when nobody remembers. That is where I would reach for it first.
Check your rights before you reverse someone else's software. Many license agreements restrict reverse engineering, and the rules differ by country. The tool will not ask, so you have to.

Honest limitations

I did not run REA for this article. Everything about its capabilities comes from its README and release notes, verified with cache-busted fetches, and the "evidence and limitations" promise is the project's claim, not something I tested.

The serious native analysis depends on outside tools. REA needs Hopper, which is separately licensed with a limited demo mode, or a pre-installed Ghidra, and the README says Windows Ghidra support is "experimental and currently unavailable." Supported hosts are macOS 12+, recent Ubuntu, Fedora and Arch.

Agents misread code. A decompiler's pseudocode is a reconstruction, and a model summarizing it can invent intent that is not there. Hardened, obfuscated or packed binaries remain hard for humans and agents alike. And returning "complete results inline," as v3.2.0 does, likely means large outputs landing in your agent's context, which costs tokens on big targets; I have not measured how much.

The star count also deserves a caveat. Shields reported about 3.8k for the repo while Trendshift's own card showed a different figure, so treat popularity numbers as rough.

The skill floor is gone

For years, a lot of client-side logic stayed private because reading it was tedious. REA is one of the clearest signs that tedium no longer protects anything. The agent your users already run can now read the app you ship them.

You can treat that as a threat or as an audit you get for free. Either way, run it on your own build this week, and see what it says about you.

Sources: morluto/rea on GitHub · REA README · REA releases · Electron ASAR archives documentation · Trendshift daily board

Medium metadata

SEO title: REA Reverse Engineering MCP Server for Claude Code and Codex: Your Client Is Readable
SEO description: morluto/rea gives coding agents 39 native inspection tools for binaries, Electron and .NET apps. What it exposes, how to audit your own app with it, and where it falls short.
Tags: Artificial Intelligence, Reverse Engineering, MCP, Claude Code, Software Security
Canonical: import from fervorai.dev