Reverse engineering plugin that turns Claude into a binary analyst. You describe what you’re looking at — device type, suspected purpose, constraints — and it coordinates radare2, Ghidra, QEMU, and GDB to build a picture. Covers ELF binaries across ARM64, ARMv7, x86_64, MIPS, and RISC-V, plus Python bytecode (.pyc files and marshalled code objects). Findings persist across sessions through episodic memory, so you can pick up where you left off.
Install
/plugin marketplace add 2389-research/claude-plugins
/plugin install binary-re
What it does
The plugin is organized into five phase-specific sub-skills that auto-detect based on what you ask:
Triage identifies the binary — architecture, ABI, libc, linked libraries, embedded strings. This runs first on any unknown binary and takes seconds.
Static analysis goes deeper with radare2 and Ghidra decompilation. Function listing, cross-references, string analysis, control flow graphs. When r2 and Ghidra aren’t available, it falls back to readelf, objdump, and standard binutils — less precise, but still useful.
Dynamic analysis runs the binary under QEMU user-mode emulation with strace, or inside Docker containers for macOS hosts. GDB multiarch and Frida attach for interactive debugging. The plugin asks before executing anything.
Synthesis compiles everything into a structured report: confirmed facts with tool attribution, hypotheses with confidence scores, and open questions.
Tool setup handles installation for whatever’s missing — radare2, QEMU, cross-architecture sysroots, Ghidra headless.
Python bytecode is a recent addition. The plugin can peel apart .pyc files, marshal-obfuscated code objects, and nested compression layers (the compress-marshal-encode pattern common in CTFs and real-world obfuscation). It handles Python version detection from magic numbers since marshal format is version-dependent.
How it works
Analysis follows a hypothesis-driven loop: observe with tools, form a theory, design an experiment to test it, run the experiment, update confidence. The I/O comparison step (comparing known inputs against actual outputs) runs first when test data exists — this alone often reveals the bug category before any disassembly.
Everything gates through human approval. Binary execution, network-capable analysis, on-device operations, and major direction changes all require a confirm before proceeding.
Episodic memory tags findings with a consistent format ([BINARY-RE:{phase}] artifact_name (sha256: hash)) so past analyses are searchable. Ask “what did we find about that camera binary?” and it pulls the full context from a previous session.
Requirements
Required: radare2, QEMU user-mode, GDB multiarch. Recommended: Ghidra (headless decompilation), frida-tools (dynamic instrumentation). Optional: angr (symbolic execution), yara (pattern matching). ARM sysroots (libc6-armhf-cross, libc6-arm64-cross) for cross-architecture work.
On macOS, dynamic analysis runs through Docker with binfmt support — the tool-setup skill walks through configuration.