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, which are 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.