Is REA Safe? Install the Real Reverse Engineer Anything from npm

REA (Reverse Engineer Anything) is the open-source project by morluto, and it has become popular enough to attract imitators. A user recently reported a lookalike GitHub repository offering a Windows download that antivirus tools flagged. This guide shows how to make sure the REA on your machine came from the real project, using checks you can run yourself in a few minutes.

It is written for anyone about to install REA, or who already installed it and wants to double-check. You will learn:

the official sources for REA, and the only install methods its documentation describes,
what the report in issue #2424 says, and nothing beyond it,
how to read the npm registry metadata with npm view,
how to check npm provenance and registry signatures with npm audit signatures, and what that does and does not prove,
how to inspect an existing installation,
where to report a fake.

Everything below applies to REA 6.4.0, the current npm release at the time of writing.

The short answer

REA is distributed through two channels:

What	Official value
Source repository	github.com/morluto/rea
npm package	`rea-agents`
MCP Registry name	`io.github.morluto/rea`
Project website	rea.tools, linked from the repository README

The package README gives one install command:

npx rea-agents setup

The installation guide also documents an optional shell wrapper for macOS and Linux, served from the official repository. It installs only the global npm package, and when a terminal is available it then starts the interactive rea setup (pass --no-setup to skip that):

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash

REA 6.4.0 has no standalone Windows .exe and no GUI download. On every platform, including Windows, REA runs on Node.js and comes from npm. If a page offers you an REA executable, archive or installer from anywhere else, do not run it.

What issue #2424 reports

On 2026-10-13 a user opened issue #2424 in the REA repository, titled “Warning: fake repo rea-tools/rea distributes a trojan ‘Windows exe’. Please add a README note”. At the time of writing the issue is open. According to the reporter:

the repository rea-tools/rea copies REA’s README and adds a “Windows Standalone .exe / GUI” section that points to a release called “rea-agents: v6.3.0”;
that release serves an archive named rea-x64.7z (82.6 MB, SHA-256 64116f55779f1a30250aa2497ada9199221d0f867f98575359a5c5cefa9b78a3);
Microsoft Defender flags the archive as Trojan:Script/Wacatac.B!ml and the extracted rea-x64.exe as Trojan:Win32/Wacatac.B!ml, and VirusTotal shows 8 of 45 engines flagging it;
the organization was created on 2026-10-10, and the reporter notes its name “seems chosen to look like your official site rea.tools”;
the reporter says they reported it to GitHub.

The reporter suggested adding a README line saying the only official downloads are the npm package rea-agents and releases on github.com/morluto/rea. The rest of this article does not depend on that one repository. The same checks work against any imitation.

Step 1: Check the name before you install

Most supply-chain mistakes happen at the moment you copy a command. Before you run anything:

The npm package is exactly rea-agents. It is not rea, rea-tools or rea-agent. npx rea-agents setup and npm install --global rea-agents are the documented forms.
The repository owner is morluto. A repository under another owner, even one with an identical README, is not the source of the npm package.
Any install script URL starts with https://raw.githubusercontent.com/morluto/rea/. That is the only install.sh the documentation mentions, and it installs the same npm package. If a README asks you to pipe a script from another domain into a shell, stop.

Why be strict about this: a copied README looks identical. The owner name and the package name are the parts an imitator cannot copy.

Step 2: Read the registry metadata with `npm view`

npm view reads package metadata from the registry without installing or running anything, so it is safe to run first:

npm view [email protected] maintainers repository.url homepage mcpName

For 6.4.0, check that:

maintainers lists morluto,
repository.url is git+https://github.com/morluto/rea.git,
homepage is https://github.com/morluto/rea#readme,
mcpName is io.github.morluto/rea.

Then see who actually published the release:

npm view [email protected] _npmUser --json

For 6.4.0 the publisher is “GitHub Actions” with a trustedPublisher block whose id is github. That means the version was published from a GitHub Actions workflow through npm’s trusted publishing (OIDC), not uploaded from someone’s laptop with a long-lived token.

To check the newest version instead of 6.4.0, drop the version suffix (npm view rea-agents ...). A future release may have different metadata, so compare it against the repository, not against this article.

What this step proves: the package named rea-agents on the public registry claims the official repository and is maintained by morluto. What it does not prove: that the files you download were built from that repository. That is what provenance is for.

Step 3: Check provenance and signatures

npm can attach a signed provenance attestation to a package version. The attestation records which source repository and which CI workflow produced the tarball, and it is logged in a public transparency log. You can see whether a version has one directly in its metadata:

npm view [email protected] dist.attestations --json

We checked this against the registry on 2026-10-13. For 6.4.0, dist.attestations is present, and its provenance.predicateType is https://slsa.dev/provenance/v1. Decoding the attestation at the URL listed there shows the build was triggered from the repository https://github.com/morluto/rea, using the workflow .github/workflows/release.yml on refs/heads/main, on a GitHub-hosted runner.

On the npm website the same information appears as a provenance section on the package page, with links to the source commit and workflow run.

Verify it cryptographically with `npm audit signatures`

Reading metadata is not the same as verifying it. npm audit signatures checks the registry signatures and provenance attestations of packages installed in a project, so it needs a node_modules tree. Use a throwaway directory:

mkdir rea-verify && cd rea-verify
npm init -y
npm install --ignore-scripts [email protected]
npm audit signatures

Why each part matters:

A throwaway directory keeps the check away from your real projects.
--ignore-scripts downloads the package and its dependencies without running any install scripts. You are verifying files here, not running them.
npm audit signatures reports how many installed packages have verified registry signatures and how many have verified attestations. If any signature or attestation is invalid, or a registry signature is missing while the registry provides signing keys, it lists the affected packages and exits with a non-zero code. A package that simply has no provenance attestation is not an error, and the attestation count is a total for the whole tree, so this command alone does not show that rea-agents itself has provenance. Pair it with the dist.attestations check above. Add --json for machine-readable output.

npm’s documentation recommends a recent npm CLI for this command, because attestation formats change. If yours is old, update npm before relying on the result.

When you are done, delete the directory. Nothing in it is needed to use REA.

What provenance proves, and what it does not

Provenance shows that this tarball was built by a GitHub Actions workflow in morluto/rea, from a specific commit, and that the registry copy has not been altered since. That rules out the main risk this article is about: a lookalike package or download that did not come from the real repository.

It does not prove the code is free of bugs or vulnerabilities, and npm’s own documentation says provenance does not guarantee a package is free of malicious code. It gives you a verifiable link to the source so you can audit it, or decide to trust the maintainers. It also covers only what npm installs. A .exe or .7z file downloaded from a website has none of these guarantees.

Step 4: Check what is already on your machine

If you installed REA earlier and want to confirm what you have, start with the CLI version and its location:

rea --version
npm ls --global rea-agents

npm ls --global rea-agents shows whether the rea command comes from the global npm package. If rea exists but npm does not list rea-agents, find out where it came from with command -v rea (macOS/Linux) or where rea (Windows) before you use it.

Next, look at how your agents launch REA. npx rea-agents setup registers MCP servers that run either npx -y rea-agents@<version> mcp or an absolute path to your global rea with the argument mcp. To preview which configuration and skill files setup would write or update on your machine, without changing anything:

npx rea-agents@latest setup --dry-run

Then run the readiness check:

rea doctor

If any agent configuration launches an REA server from an unfamiliar executable or download folder, remove that entry. rea uninstall removes REA-owned registrations and skill files, and rea uninstall --purge-data also removes REA’s caches and state under ~/.rea. Then reinstall with npx rea-agents setup.

Step 5: Know the red flags

Treat any of these as a reason to stop:

an “REA” download that is an .exe, .msi, .7z, .zip or .dmg, rather than the npm package;
a README that matches REA’s but lives under a different owner;
instructions to run an install script hosted somewhere other than raw.githubusercontent.com/morluto/rea;
a “release” whose version label does not match a published rea-agents version on npm (npm view rea-agents versions lists them all);
any instruction to disable antivirus or SmartScreen to “make REA work”. REA’s own setup never asks for this.

A simple rule covers most of these: if it did not come from npm as rea-agents, or from github.com/morluto/rea, do not run it.

Step 6: Understand REA’s own security model

Installing the genuine package is the first half. The second half is knowing what REA does once it runs:

REA does not install analysis engines for you. Setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk or Unblob. The only external software it can install is Hopper, and only after a separate, explicit approval.
Setup shows its plan first. Every path it will write, every backup and every external action is listed before you approve.
REA is not a sandbox. The project’s SECURITY.md states that opening an untrusted binary delegates parsing and analysis to the selected local provider with your user’s permissions. Analyze suspicious samples in a disposable VM, not on your daily machine.
You choose the targets. Analyze software you own or are authorized to examine, and read the DISCLAIMER.

Step 7: Report a fake or a problem

Use the channel that matches what you found:

An impersonating repository or account on GitHub: use GitHub’s “Report abuse” or “Report content” option on that repository or profile. Do not star it, fork it or download from it to “check”.
A suspicious package on npm: use the “Report malware” link on the package’s npmjs.com page.
Confusion about what is official, or a lookalike that is not yet tracked: open an issue at github.com/morluto/rea/issues and include facts you observed, such as URLs and file hashes. Do not attach the malware.
A security vulnerability in REA itself: do not file a public issue. Per SECURITY.md, use “Report a vulnerability” in the repository’s Security tab.

If you already ran a file from an unofficial source, disconnect the machine from sensitive accounts, run a full scan with your security software, change credentials that were used on that machine, and follow your organization’s incident process if it is a work device.

FAQ

Is REA itself safe to install? The npm package rea-agents is published from the official repository with provenance, and you can verify that yourself (Step 3). Like any tool that analyzes binaries, it runs with your permissions, so the usual care about untrusted samples still applies.

Why does npx ask to download a package? That is npm’s own prompt before fetching rea-agents. Check the package name in the prompt, then approve. REA’s setup plan is a separate approval.

Will there be an official Windows build? The issue reporter mentions a planned Windows portable build tracked in the repository. Until the project announces one in its README and changelog, the npm package is the only way to install REA on Windows. If one ships, it will be in the Releases of github.com/morluto/rea, not in another account’s repository.

Is skills.sh an official source? The REA README links to a skills.sh listing for the reverse-engineer-anything skill. That installs instructions only, not the MCP server or any executable. See Claude Code reverse engineering skill for what the skill contains.

Next steps

Install and connect REA properly: Install REA MCP and connect Claude Code, Cursor and Codex.
Learn what setup installs for Claude Code and how to verify agent tool calls: Claude Code reverse engineering skill.
Start analyzing safely with a free engine: REA + Ghidra for native binaries.