REA 6.4 adds Android ADB and JEB tools so coding agents can reverse-engineer apps

What shipped in rea-agents 6.4.0?

GitHub Actions published rea-agents 6.4.0 on 11 October 2026 (03:58 UTC). The npm package rea-agents lists the same version. Release notes credit 336 commits and 163 merged pull requests in the window, with named contributors across Android, JEB, Ghidra, JavaScript and capture tooling.

Headline items: Android device inspection and Apktool-backed manifest/string decoding; JEB unit browsing and decompilation via a local JEB MCP server the caller starts; Evidence discovery that lets an agent retain large analyses as summaries and open selected views on demand; JavaScript analysis in an owned process with heap and timeout limits; richer Ghidra import controls; and RPC discovery for tRPC, HTTP-link URLs and named GraphQL operations inside JS bundles.

The 6.x line also carries explicit breaking changes—WebSocket result shapes, caller-owned ArtifactResourceScope arguments, semantic graph schema edits, and capture-comparison versioning. Teams pinning MCP clients should read the breaking-changes section before upgrading mid-investigation.

What is REA, and how does an agent use it?

REA (Reverse Engineer Anything) brands itself as one MCP for reverse engineering across binaries, applications and runtime behaviour. The public site at rea.tools and the GitHub README describe a local server plus workflow skills that coding agents load during setup.

Setup is deliberately agent-native: `npx rea-agents setup` proposes MCP registration and skill files for Claude Code, Codex, Cursor, Gemini CLI, Grok Build and others, backs up existing config, and asks for approval before writing. That sits on top of what the Model Context Protocol is rather than inventing a parallel plugin format.

A typical prompt asks the agent to inspect a shipped app feature, show evidence, and rebuild a similar behaviour in the user’s project. Native paths can call Hopper, Ghidra or IDA for pseudocode, assembly, strings, symbols and references. Static JavaScript and Electron analysis can run without a native decompiler. Runtime captures observe selected process activity under the operator’s permissions.

Which targets and engines does it cover?

Documented surfaces include native binaries, JavaScript/Electron trees and ASAR packs, .NET metadata and CIL, Android APKs (JADX + JDK), firmware (Binwalk/Unblob), WebAssembly, EVM bytecode, Linux crash artefacts and saved network captures. Browser scenarios need a Chrome-family browser; Termux Android browser scenarios landed in 6.4.

Provider coverage is uneven by design. Some PE/.NET and NativeAOT paths are read-only or marked unverified on real Windows hosts in the notes. Ghidra gained Windows PE DLL and bounded MIPS ELF support in the 6.x window. Hopper remains optional and may be installed during setup only with approval.

Compared with end-to-end computer-use agents, REA aims at understanding existing software artefacts rather than clicking a live GUI. The two can combine in a workflow—REA to recover a rule, a computer-use agent to validate a rebuild—but the security boundary differs.

What do the maintainers claim about evidence and safety?

Documentation stresses a split between findings from analysis tools and interpretations from the agent. Results are supposed to carry supporting evidence and limitations so users do not treat regenerated explanations as recovered source. Showcases on the website claim reconstructions such as a DX-Ball sound-position routine matching thousands of original x86 tests; those demos are vendor-presented, not re-run here.

Local analysis does not imply local secrecy. Tool outputs go to the connected agent, then to that agent’s model provider under the provider’s data policy. That is the same class of concern as other MCP servers that exfiltrate file contents into prompts. Pair REA with NVIDIA’s OpenShell agent controls, Microsoft Execution Containers, or basic agent sandboxing basics if you analyse proprietary binaries on a shared machine.

Maintainers state the intended use is lawful reverse-engineering research, analysis and reconstruction. Authorisation and local law remain the operator’s problem. Technical capability is not permission.

How do you install it, and what broke in 6.x?

Install Node.js, run `npx rea-agents setup`, approve the plan, restart the agent. Global CLI install is `npm install --global rea-agents`. Doctor and MCP catalog docs live in the repository. Compact MCP input schemas exist for size-capped clients such as Kimi/Moonshot.

From 8 to 11 October the project cut five 6.x tags (6.0.0 through 6.4.0). Several breaks remove legacy aliases—for example WebSocket connections move under `network.websocket_connections`, and artifact graph edges require occurrence-scoped child ids. Upgrade guides in the release notes matter more than the marketing one-liner.

Supply-chain hygiene still applies. Pin versions, review the setup diff, and remember recent interpreter incidents such as vLLM’s October RCE advisories when you pull analysis stacks into CI.

What should security and product teams watch?

We inspected the 6.4.0 GitHub release JSON, the README, the public website, and npm package metadata on 12 October 2026. We did not install REA against proprietary binaries, did not validate the DX-Ball or Notion showcases, and did not audit the MCP surface for prompt-injection paths.

For product teams, the useful question is whether REA shortens authorised interoperability and security review work with inspectable artefacts. For defenders, assume any agent with REA tools can read whatever those tools can reach under the user’s OS permissions. For open-source watchers, 6.4.0 is a concrete dated event after a week of rapid 6.x iteration—enough to cover without treating every intermediate tag as a separate story.