Binary Reverse Engineering Plugin

You pulled a binary off an embedded device. It's an ELF, probably ARM, and you need to figure out what it does. Binary RE gives Claude the tools to help — radare2 for disassembly, Ghidra for decompilation, GDB for dynamic analysis, QEMU for emulation — driven by hypothesis-testing, not blind exploration.

Installation

/plugin marketplace add 2389-research/claude-plugins
/plugin install binary-re@2389-research

What this plugin provides

Skills

• binary-re -- structured RE workflow with hypothesis-driven analysis

Sub-skills

Name	Description
binary-re:triage	Fast binary fingerprinting — architecture, ABI, dependencies, and strings via rabin2. Use first on any unknown binary.
binary-re:static-analysis	Deep code analysis via radare2 and Ghidra — functions, cross-references, decompilation, and CFGs without execution.
binary-re:dynamic-analysis	Runtime behavior observation via QEMU, GDB, and Frida — syscall tracing, breakpoints, and memory inspection; requires human approval.
binary-re:synthesis	Compiles analysis findings into structured reports with validated hypotheses and evidence chains.
binary-re:tool-setup	Installs and configures radare2, Ghidra, GDB, QEMU, Frida, and cross-compilation toolchains.

Capabilities

• Cross-architecture static analysis (ARM64, ARMv7, x86_64, MIPS)
• Dynamic tracing via QEMU user-mode emulation
• GDB integration for debugging
• Ghidra headless decompilation
• Human-in-the-loop gates for risky operations

Quick example

User: "Analyze this binary from an IoT device - ARM, Linux-based"

Claude: [Triggers binary-re skill]

Let me start with triage to understand what we're working with.

Phase 1: Initial Triage
┌─────────────────────────────────────────┐
│ Architecture: ARM 32-bit LE (v7)        │
│ Libc: musl 1.2.3                        │
│ Dependencies: libcurl, libssl, libz     │
│ Stripped: Yes                           │
│ Strings: 847 (including URLs, paths)    │
└─────────────────────────────────────────┘

FACTS recorded:
- Links against libcurl.so.4 (network client)
- Contains string "api.vendor.com/telemetry"
- Imports socket, connect, SSL_read functions

HYPOTHESIS: This is a telemetry client that phones home over HTTPS
Confidence: 0.7
Evidence: curl+ssl imports, telemetry URL string

Do you want me to proceed with static analysis of network-related
functions, or should we try dynamic analysis under QEMU first?

Tool requirements

# Required
sudo apt install radare2 qemu-user gdb-multiarch

# Recommended
# Ghidra from https://ghidra-sre.org/
pip install frida-tools

# ARM sysroots
sudo apt install libc6-armhf-cross libc6-arm64-cross

Use cases

• Firmware analysis -- understand device behavior without source
• Protocol reverse engineering -- map network communications
• Security research -- find vulnerabilities in embedded systems
• Hardware hacking -- analyze robot/IoT device internals

Philosophy

The LLM drives analysis; the human provides context.

You tell Claude what platform/device the binary came from, what hardware is involved, what the binary is theorized to do, and any constraints (no network, isolated test env, etc).

Claude runs the tools, forms hypotheses from evidence, designs experiments to test theories, and synthesizes findings into something actionable.

Human-in-the-loop