# General Reverse Engineering

> General-purpose binary analysis — understand functionality, architecture, and behavior

- Skill: `buzzer-re/general-reverse-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add buzzer-re/general-reverse-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/buzzer-re/general-reverse-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: buzzer-re (https://skillmd.com/u/buzzer-re)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/buzzer-re/general-reverse-engineering

---

Task: General Reverse Engineering. You are analyzing a binary to understand its functionality, architecture, or behavior. No assumption about maliciousness.

## Approach

Build a mental map of the binary's structure. Start at the entry point or user-specified function. Name functions as you understand them — each rename makes the next function easier to read. Focus on what the user is interested in, not exhaustive coverage.

## Workflow

1. `get_binary_info` — format, architecture, size, function count
2. `list_imports` + `list_exports` — understand the binary's interface (batch these)
3. Start at the function of interest (or entry if exploring)
4. `decompile_function` → understand → `rename_function` / `rename_variable` → follow call chains
5. Use `xrefs_to` and `xrefs_from` to trace data and code references
6. Build up a picture of the binary's modules, data structures, and control flow

## Call Graph Strategy

Use xref tools BEFORE decompiling for exploration — they're cheaper:
1. `function_xrefs` on entry → map top-level subsystems without decompiling everything
2. `xrefs_to` on interesting imports → find which functions use specific APIs
3. Decompile only the nodes you actually need to understand
4. After understanding a function's purpose, check its callers to propagate context upward

Depth guidance:
- Immediate callers/callees: quick orientation
- 2 levels: neighborhood — usually sufficient
- 3+ levels: subsystem mapping — only for deep dives

## Domain-Specific Tips

**Libraries/frameworks:** Focus on exported functions and their calling conventions. Use `list_exports` to map the public API.

**Drivers/kernel modules:** Identify dispatch routines, IOCTL handlers, initialization. Consider using `/driver-analysis` for Windows drivers.

**Proprietary formats:** Trace the parsing code. Use `create_struct` and `suggest_struct_from_accesses` to reconstruct data structures. Apply with `apply_struct_to_address`.

**Firmware/embedded:** Check for known library signatures in function prologues. Map memory-mapped I/O regions via `list_segments`.

**Statically linked (Go/Rust):** No imports — look for runtime strings (runtime., go.itab, panicked at). Function count will be high; focus on entry and user code.

## Renaming Strategy

- Before renaming, form a hypothesis from: decompiled code + xrefs + string references
- Rename in semantic batches: all network functions together, all crypto together
- After renaming a batch: re-decompile to verify the renamed code reads correctly
- Use `set_comment` and `set_function_comment` to document non-obvious logic
- Naming conventions: PascalCase for functions, g_ prefix for globals, PascalCase for structs

## Output

Deliver what the user asks for:
- Function summaries with addresses
- Architectural overview
- Data structure definitions (C-style)
- Specific answers about behavior