open-reverselab: an AI reverse-engineering lab that runs on Ghidra, Frida and x64dbg

What open-reverselab actually solves, and for whom

Reverse engineering work spreads across tools that do not talk to each other. A PE sample goes through a triage scanner, then Ghidra, then x64dbg. An APK goes through jadx, apktool, adb and Frida. Each handoff loses context, and the notes about what was tried live somewhere else entirely. open-reverselab addresses that by fixing two things: a directory convention where every artifact has a home (samples/, exports/, patches/, kb/, reports/), and an MCP server named reverse_lab_tools that exposes the tools to an agent session.

The README is explicit about the audience. It lists CTF players stuck on a Web, Android or PE challenge, security researchers who have a sample in hand, reverse engineers who want a workspace without a tutorial, and developers who want to attach an AI agent to reverse-engineering tools. The knowledge base is organized by attack surface rather than by tool, and the README states the rule behind it plainly: if a step cannot be executed, it does not belong in the KB. That is a real editorial constraint, and it explains why the articles are structured as scenario, input signal, method, attack chain, MCP tool mapping rather than as a tool manual.

The project is not a disassembler and does not try to be. It is a coordination layer plus a curriculum, and judging it as a Ghidra replacement misses the point.

How the MCP server and the context chain fit together

The mechanism has three parts. First, an MCP server under tools/skills/mcp/ReverseLabToolsMCP exposes more than 100 tools through a single namespace, reverse_lab_tools. The README names curl, frida, ghidra, rizin, yara, triage and kb_router among them, and the board table maps signals to entry points: http_probe, run_ctf_tool and kb_router for web work, android_app_baseline and the android_frida_* tools for APKs, triage_pe and ghidra_headless_analyze for PE files.

Second, a context chain that an agent loads at session start. The README gives the order as CLAUDE.md, then AGENTS.md, then AI-USAGE.md, then boards/<board>/AI-USAGE.md. This is a progressive-disclosure design: the root files set global rules, and the board file narrows them to the task at hand. It also means the quality of your session depends on those files being read in order, which is a convention the user has to respect rather than something the server enforces.

Third, an environment snapshot protocol. On first use with an agent, the project probes the machine (OS, dev environment, reverse-engineering toolchain, Python RE libraries, devices, redacted environment variables, network, workspace) and writes the result to ~/.open-reverselab/env/env.md, or %USERPROFILE%\.open-reverselab\env\env.md on Windows. The file is machine-level and shared across projects, is re-probed only after seven days or a protocol version bump, and stays outside the repository. Environment variables are redacted by protocol, with secrets marked only as set and proxy credentials stripped of userinfo. That last detail is the kind of thing most agent tooling gets wrong, and it is worth noting that the project thought about it.

Installing open-reverselab and running a first check

The README splits the install by role. Human users on Windows are told to double-click START_HERE.bat or START_HERE.cmd in the repository root. macOS and Linux users run ./START_HERE.sh. Both paths check Python, uv, Git and the reverse_lab_tools MCP server, call core MCP tools for real, and write reports/misc/first-run-report.json and reports/misc/mcp-smoke-report.json. Those two files are the evidence that the install worked, so read them rather than trusting the console output.

After the first check passes, tooling installs per board. The README is direct about not installing everything: the lab is modular. On Windows the commands are PowerShell scripts under scripts/misc.

# 按需选择 —— 实验室是模块化的，不要全装
.\scripts\misc\bootstrap.ps1                # 生成核心脚本 wrappers（无下载）
.\scripts\misc\install_tools.ps1 -CTF       # Web 工具（sqlmap、nuclei、ffuf、jwt_tool …）
.\scripts\misc\install_tools.ps1 -Android   # APK 工具（apktool、jadx、frida、uber-apk-signer …）
.\scripts\misc\install_tools.ps1 -Windows   # PE 工具（cutter、pe-bear、procmon …）
.\scripts\misc\install_tools.ps1 -Common    # Ghidra + Maven

On macOS and Linux the equivalent is a shell bootstrap followed by a PATH export and a tool check. The export matters: the wrappers live under tools/bin and tools/ctf-website/bin, and without them on PATH the board tools are present but not callable.

./scripts/misc/bootstrap.sh
export PATH="$PWD/tools/bin:$PWD/tools/ctf-website/bin:$PATH"
python scripts/misc/ai_toolcheck.py --board misc    # 校验最小化核心

Creating a task is a separate script, and the board name has to match one of the boards in the knowledge base. For an agent session, the README also describes an MCP smoke check run through uv against the MCP project directory, which is the command to repeat after moving machines or reconfiguring MCP.

python scripts/misc/new_task.py --board ctf-website --name <name>
uv run --project tools/skills/mcp/ReverseLabToolsMCP \
  python scripts/misc/mcp_smoke_check.py --write-report

The README closes the install section with a health check and a per-board tool check, so the intended sequence is bootstrap, install the board you need, then verify before starting real work.

Windows Defender will flag parts of the knowledge base

The README devotes a section to antivirus warnings, and it is not boilerplate. After installing CTF and ExploitDB tooling, Windows Security may quarantine files such as tools/ctf-website/exploitdb, the NoSQL injection article at kb/ctf-website/techniques/24-database/03-nosql-injection.md, and docs/llms-full.txt. The README states that these contain security testing payloads, webshells, shellcode or ExploitDB samples, and that the detection is expected content rather than a compromise.

The recommended remedy is a narrow exclusion rather than excluding the whole repository, and the README gives the exact command for a single path.

Add-MpPreference -ExclusionPath "D:\open-reverselab\tools\ctf-website\exploitdb"

This is the right call, but it is still an operational constraint: on a managed corporate machine you may not be permitted to add exclusions at all, and in that case the CTF and exploit portions of the lab are effectively unavailable. There is no documented alternative for that situation. The README also does not document rollback, so if an install breaks a toolchain you are on your own for undoing it. Treat the modular board install as the mitigation: install one board, verify it, and only then add another.

Where open-reverselab is the wrong tool

The platform differences are stated plainly in the README, and they are the first limitation. On macOS and Linux the first-run script uses the POSIX shell wrappers under tools/bin, and Windows-only GUI and PE tools are skipped or explicitly marked as unavailable. If your work is Windows binary reversing on a Linux workstation, a meaningful part of the PE board is not there for you.

The second limitation is the interface itself. The MCP tool surface is large, more than 100 tools, and the release history shows the platform still moving: v1.1.0-windows in July 2026, then v1.2.0 and v1.2.1 in September 2026. A tool namespace that size, changing across minor releases, is a real integration risk if you build scripts or prompts that name specific tools. Nothing in the README promises interface stability.

The third is the audience boundary. This is an agent-first lab. If you do not use Claude Code, Codex, OpenCode or another MCP-compatible client, you get a directory convention and a set of markdown articles, which is a much smaller product than the README's framing suggests. The knowledge base is still useful on its own, but the automation is the part that justifies the setup cost.

How it differs from a plain Ghidra MCP bridge

A typical Ghidra MCP server exposes decompilation and navigation calls for one program, one disassembler, one session. open-reverselab takes the opposite approach: it is a multi-tool router. One namespace, reverse_lab_tools, fronts Ghidra, Frida, x64dbg, Rizin, YARA, curl and a knowledge-base router, and the board table assigns different entry tools to different signal types. The difference in practice is that a Ghidra bridge answers questions about a binary you already opened, while open-reverselab is meant to take an entry signal (a URL, an APK, a PE file) and walk a chain that crosses tools, writing artifacts into samples/, exports/ and reports/ as it goes.

That breadth is also the cost. A single-tool bridge has a small, stable surface you can reason about. A router with more than 100 tools requires the context chain to work: if the agent does not read boards/<board>/AI-USAGE.md, it is choosing among a hundred tools without the board-specific guidance the project wrote for exactly that situation. The project's own answer is the kb_router tool and the AI-USAGE.md files. Whether that is enough depends on your agent, not on the repository.

Licence, upgrades and what the repository does not promise

open-reverselab is GPL-3.0. That matters more here than for a standalone tool, because the project is designed to be embedded in agent workflows and extended through boards and MCP tools. If you fork it, add proprietary tooling and distribute the result, the GPL-3.0 obligations travel with the derivative work. Internal use inside one organization is a different question, and the repository does not answer it; that is a conversation with your legal team, not something to settle from a README.

Upgrade cost is the other open item. The CHANGELOG.md exists at the repository root, and the release cadence through mid-2026 was steady, but the README does not document a migration procedure between minor versions, nor does it describe how a board-level install interacts with an upgrade of the core scripts. The practical approach the README supports is to re-run the health check and the per-board tool check after any update, and to re-run the MCP smoke check whenever the MCP configuration changes. Beyond that, the README is silent, and the honest reading is that upgrades are currently a manual, verify-after-the-fact operation.

Editorial conclusion

Adopt open-reverselab if you already drive Claude Code, Codex or another MCP client and you want reverse-engineering tooling and a knowledge base reachable from the same session, and if you can accept GPL-3.0, a Windows-first toolchain and a per-board install. Skip it if you want a single cross-platform binary-analysis GUI, if your environment forbids installing CTF and ExploitDB tools, or if you need a stable tool interface that will not be renamed between releases. Verify first that the MCP server answers on your machine by running the smoke check with --write-report, then read boards/<board>/AI-USAGE.md for the board you actually intend to work in before installing anything else.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LING71671/open-reverselab on GitHub
4. README
5. Releases