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

The skill asks for confirmation before:

Executing binaries (even sandboxed)
Network-capable dynamic analysis
Operations requiring device access
Major changes in analysis direction

Documentation

CLAUDE.md -- detailed skill reference
skills/SKILL.md -- full workflow documentation

If Binary RE helped you crack a firmware blob, a ⭐ helps us know it's landing.

Built by 2389 · Part of the Claude Code plugin marketplace