open-reverselab: a runnable reverse-engineering knowledge base with an MCP tool layer

The gap open-reverselab is trying to close

Reverse-engineering tooling is fragmented by design. Ghidra, Frida, x64dbg and Rizin each have their own scripting surface, and a single analysis session usually means moving artefacts between them by hand. open-reverselab's stated aim is to make that movement explicit and repeatable: the README describes the project as a "point-of-view, directly runnable" attack knowledge base whose articles follow a fixed structure of scenario, input signal, method, attack chain and MCP tool mapping. The intended reader is named in the README's own table: CTF players stuck on Web, Android or PE challenges, security researchers who have just received a sample, reverse engineers who want a workspace without reading tutorials, and developers who want to attach an AI agent to existing reverse-engineering tools. That last group is the real target. The knowledge base is the payload; the MCP server is the interface.

How the MCP layer and the knowledge base fit together

The architecture visible in the README has three parts. The first is kb/, a tree of more than 180 articles split across ctf-website, apk-reverse, pe-reverse, general and windows. Each board is indexed by trigger signal rather than by tool: an APK, a URL, a JWT, a PE header, a packer. The second is the MCP server, described as exposing 100+ tools through a component named reverse_lab_tools, with examples including curl, frida, ghidra, rizin, yara, triage and kb_router. The third is a directory contract: samples/, exports/, patches/, kb/ and reports/ are fixed destinations, and the README states that every artefact has a defined home. The routing idea is that an agent reads an input signal, calls kb_router or a board entry tool such as triage_pe or android_app_baseline, and follows the chain until it writes evidence into reports/. The README is blunt about the standard: if a step cannot be executed, it does not belong in the knowledge base. That is a editorial constraint as much as a technical one, and it is the most interesting design decision in the repository.

Getting a first run to complete

The README gives two human entry points. On Windows, double-click START_HERE.bat or START_HERE.cmd at the repository root; the script checks Python, uv, Git and the reverse_lab_tools MCP, makes a real call to a core MCP tool, and writes reports/misc/first-run-report.json plus reports/misc/mcp-smoke-report.json. On macOS and Linux, run ./START_HERE.sh, which performs the same checks using POSIX wrappers under tools/bin/; Windows-only GUI and PE tools are skipped or explicitly marked. Board installation is deliberately modular and the README warns against installing everything: scripts/misc/bootstrap.ps1 generates core wrappers without downloads, then install_tools.ps1 takes -CTF, -Android, -Windows or -Common, the last pulling Ghidra and Maven. The shell equivalents are bootstrap.sh and an ai_toolcheck.py --board misc call. For agent use, the README instructs cloning to a fixed path, starting Claude Code from inside that directory, or opening the folder in Codex, then creating a task with python scripts/misc/new_task.py --board ctf-website --name <name>. The MCP smoke test is explicit: uv run --project tools/skills/mcp/ReverseLabToolsMCP python scripts/misc/mcp_smoke_check.py --write-report. Two post-install checks are listed, lab_healthcheck.py and ai_toolcheck.py.

The Windows-first assumption and its cost

The README is honest that the platform is not symmetric. The Windows path is described as the recommended first run and ships a single double-click entry point. The macOS and Linux path uses shell wrappers and explicitly skips or annotates Windows-only GUI and PE tooling, which means a Linux user working through the pe-reverse board will hit gaps in the tool mapping rather than a clean failure. There is a separate release tag, v1.1.0-windows, labelled as a full Windows toolchain, which suggests the maintainers treat the Windows bundle as a distinct deliverable. The second practical cost is antivirus friction. The README states that Windows Security may flag tools/ctf-website/exploitdb, kb/ctf-website/techniques/24-database/03-nosql-injection.md and docs/llms-full.txt because they contain payloads, webshells, shellcode or ExploitDB samples, and it recommends a narrow exclusion via Add-MpPreference -ExclusionPath rather than excluding the whole repository. That is a sensible instruction, but it also tells you what kind of content you are cloning onto a work machine. If your endpoint policy forbids shellcode samples on disk, this repository is the wrong shape for you regardless of how good the knowledge base is.

Where the agent integration can fail quietly

MCP tool counts are a poor proxy for reliability. The README advertises 100+ tools and a smoke check that makes a real call, which is the right minimum, but a passing smoke check only proves that one tool round-trips. The failure mode to watch for is stale tool bindings: an agent that loads the context chain (CLAUDE.md, AGENTS.md, AI-USAGE.md, boards/<board>/AI-USAGE.md) and then calls a tool whose underlying binary is missing or on a different path will produce a plausible-looking analysis with no evidence behind it. The README's own answer to this is the environment snapshot protocol in AGENTS.md, which probes the machine and writes ~/.open-reverselab/env/env.md, shared across projects and refreshed only after seven days or a protocol version bump. That caching is convenient and also the weak point: a toolchain installed after the snapshot was written will not appear in it, and the agent has no reason to re-probe. If you change your Ghidra version or move Frida, delete that file. The README does not say to do this.

How it differs from scripting Ghidra yourself

The obvious alternative is Ghidra's own headless analyzer plus a personal set of scripts, or a general automation framework such as angr for symbolic work. The difference is not capability, it is where the knowledge lives. Ghidra headless gives you an analyzer and a scripting API; it says nothing about what to do with a packed PE file or which Frida hook to try first. open-reverselab inverts that: the articles are organised by attack surface and each one maps to named MCP tools such as triage_pe, ghidra_headless_analyze, make_x64dbg_breakpoint_script, android_crypto_unpack_recipe and sample_full_workup. The cost of that inversion is coupling. If you disagree with the directory contract or with the board taxonomy, you are working against the repository rather than with it, and the MCP tool names are baked into the prose. A team that already has a working internal playbook will find the knowledge base redundant and the tool layer the only part worth taking.

Licence, maintenance and what a fork inherits

The repository is GPL-3.0. That matters more than usual here because the deliverable is a tool that other software calls into. If you embed the MCP server in a product, or ship a modified version, the licence's copyleft terms apply to the distributed work; the licence text in LICENSE is the authority, not this article. The GPL also means a commercial fork cannot be closed, which is worth deciding before you build on the tool layer rather than after. On maintenance, the release history shows v1.2.0 and v1.2.1 within a day of each other in early September 2026, after a v1.1.0-windows tag in July. That cadence suggests active work, but it also means the MCP tool surface can move between minor versions, and anything you write against a specific tool name should be pinned to a release tag rather than to main. The README does not document a deprecation policy for tool names, so treat the tool list as unstable until you see otherwise.

Who should clone this, and what to check on day one

This is a good fit for a security engineer on Windows who already has Ghidra and Frida installed, wants an agent to drive them, and is comfortable reading Chinese, since the README and much of the knowledge base are in Chinese with an English README.en.md alongside. It is a poor fit for anyone who needs vendor support, a documented stability guarantee, or a Linux-native PE workflow. The first thing to verify is not the article count but whether the MCP server actually answers on your machine: run the uv run command against tools/skills/mcp/ReverseLabToolsMCP and confirm mcp_smoke_check.py writes a report with a real tool result, not a stub. The second is whether ai_toolcheck.py --board misc passes after you install only the board you need. If either fails, the 180 articles are still readable, but the agent-driven workflow the project is built around is not the thing you have.

Editorial conclusion

Adopt open-reverselab if you already run Ghidra or Frida and want an agent to call them through MCP inside a repository whose directory conventions are fixed. Do not adopt it if you need a supported cross-platform product, if you cannot accept GPL-3.0 obligations, or if you work mainly on macOS or Linux with Windows-only tooling. Verify first that mcp_smoke_check.py returns a live tool call on your machine, then run ai_toolcheck.py --board misc before installing any board-specific toolchain.

Official sources

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