English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Türkçe · Русский · Tiếng Việt · ไทย · Deutsch · Español · Français · Українська · Polski · Português (Brasil) · العربية · فارسی · Bahasa Indonesia · Italiano · Ελληνικά · മലയാളം

ANTI-REA

One MCP for protecting binaries, applications, and core logic against REA.

Have a core feature you need to protect? Keep it from being analyzed or cloned, down to the binary level.

Reverse-engineering tools like REA let an agent inspect a binary when you ask "Understand how this feature works in that app and build a copy for my project."

Agentic attack? Meet agentic defense — defense that grows stronger over time. The ultimate goal of ANTI-REA is to block everything that REA can analyze. Ask your agent in plain language — "Protect the core logic in my program so REA can't analyze or clone it" — and the agent locates your core functions and surrounding clues, applies obfuscation and virtualization (VM), verifies that behavior isn't broken, and measures what percentage of the original speed it runs at.

You don't need to build a complex attack-and-defense lab yourself. Every day, we pit our defense environment against a separate REA attack environment on TestApp's VM, inspect how attacks break through, patch the weak spots, and continuously strengthen the defense. You simply connect the battle-hardened ANTI-REA to your agent and use it.

Current Defense & Roadmap (TestApp VM vs. Live REA Attacks)

This gauge is not an abstract project schedule — it represents how well our VM-protected TestApp holds up against direct attacks from REA on a separate environment.

Defense Stages (Ultimate Goal: Block Everything REA Analyzes)

• 25% (Current) · First-Stage Static Reconstruction Blocked: Starting from a baseline VM that was easily broken, handler diversification and operand context coupling now prevent external REA static analysis from reconstructing the core formula in one shot.

• 50% · Block Static Analysis & Context Inference: Hide internal dispatcher helpers and call-graph clues so the original logic cannot be inferred from static decompilation alone.

• 75% · Defend Against Dynamic Tracing & Debugging: Protect core logic and constants when attackers turn to debuggers, Frida, execution traces, and memory dumps.

• 100% · Full Defense Across Everything REA Analyzes: Extend protection beyond native binaries (C/C++, Rust, Go) to .NET, Java/Kotlin, JavaScript/Electron, Python, and macOS (Mach-O/ARM64), blocking REA across every target and analysis path it supports.

Related MCP server: REA

Quick start

1. Set up your agent

No need to touch terminal commands or config files manually. Just ask your agent (Claude Code, Cursor, Codex, Gemini CLI, etc.):

Install ANTI-REA in a local Python virtual environment (.venv) and connect the antirea.defense_mcp server to your MCP configuration so you can use it right away.

2. Ask your agent

Once connected, ask your agent in natural language:

Protect the core calculation logic and surrounding clues in my project so REA cannot analyze or clone them, and tell me if the original behavior is intact and what percentage of the original speed it runs at.

Or if you already have a built executable and a commercial protector profile:

Create a VMProtect protection plan for app.exe, show it to me first, and run it once I approve.

Your agent automatically calls ANTI-REA MCP tools to check available engines (protection_doctor), generate a hashed execution plan (protection_plan), and run protection after approval (protection_protect).

3. Use the terminal

You can also inspect supported providers and local setup directly from the terminal:

.\.venv\Scripts\python.exe -m antirea.defense_mcp --config .runs/protectors.local.json providers
.\.venv\Scripts\python.exe -m antirea.defense_mcp --config .runs/protectors.local.json doctor

How It Works & How It Gets Stronger Daily

On Your Machine

• Scope Beyond a Single Function: Hiding just one function leaves callers and constants exposed. In the LLVM IR path, ANTI-REA traces call graphs and shared data to include surrounding functions that leak clues.

• Plan Before Execution: Input hashes and commands are locked into a plan first so the agent never overwrites binaries unexpectedly.

• Behavior & Relative Speed Measurement: VM protection inevitably adds overhead. ANTI-REA verifies that outputs match the original binary and measures what percentage of the original speed the protected binary achieves.

Our Daily Live Attack-Defense Loop

We run a continuous loop between our Defense Environment and an External Attack Environment (REA + Ghidra):

1. Build & Verify (Defense Environment): Apply new VM/obfuscation techniques to TestApp and verify 100% output equivalence and performance bounds across thousands of test cases.

2. Blind Attack Test (External Attack Environment): Share only the protected EXE and public I/O specification (never source code or private tests). The attack environment uses REA to analyze and reimplement the binary.

3. Weakness Analysis & Next Defense: Inspect the incoming attack report to see which clues leaked (constant tables, handler patterns, helper functions) and harden the next-generation VM against them.

Supported Engines

While the built-in open-source engine (Kagura + ANTI-REA Hardening) grows stronger every day, if you need even stronger protection right now, you can purchase Themida, VMProtect, or Code Virtualizer, connect it to ANTI-REA, and simply tell your agent in natural language what execution speed and defense level you want.

Use VMProtect (or Themida / Code Virtualizer) to keep execution speed above 80% of the original while defending the core logic as strongly as possible.

Development & Testing

Run the unit and boundary test suite from the repository root:

python -m unittest discover -s tests -v

Contributions for commercial protector verification, new VM obfuscation ideas, general project build integration, and macOS support are welcome. Distributed under the MIT License (connected third-party protection engines follow their own respective licenses).