| name | General Reverse Engineering |
| description | General-purpose binary analysis — understand functionality, architecture, and behavior |
| tags | ["analysis","reverse-engineering","general"] |
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
get_binary_info — format, architecture, size, function count
list_imports + list_exports — understand the binary's interface (batch these)
- Start at the function of interest (or entry if exploring)
decompile_function → understand → rename_function / rename_variable → follow call chains
- Use
xrefs_to and xrefs_from to trace data and code references
- 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:
function_xrefs on entry → map top-level subsystems without decompiling everything
xrefs_to on interesting imports → find which functions use specific APIs
- Decompile only the nodes you actually need to understand
- 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