Reverse Engineering & Debugging

Professional methodology for static analysis, dynamic analysis, debugging, and binary exploitation.

Quick Reference — Load the Right Reference File

Bundled Tools (tools/)

The skill ships ready-to-use companion utilities (all original work, MIT-licensed):

See tools/README.md for usage details. The tools/mcp/ directory documents the live-query workflow (alternative to file export) — both modes are supported by the methodology files above.

Universal First Steps

Before loading any reference file, establish context:

1. Identify the Target

file <binary>           # file type, arch, bits, stripped?
xxd <binary> | head -4  # magic bytes
strings -a <binary> | head -60
checksec --file=<binary>  # NX, PIE, RELRO, stack canary, ASLR

Binary format decision tree:

• ELF → Linux native → references/static-analysis.md + references/dynamic-debugging.md
• PE/PE32+ → Windows native → references/windows-re.md + references/static-analysis.md
• PE with .NET metadata → references/managed-code-re.md (dnSpy first)
• Mach-O → macOS/iOS → references/macos-kernel-re.md + references/ios-re.md
• DEX/APK/AAB → Android → references/android-re.md
• JAR/WAR/AAR → Java → references/managed-code-re.md
• .sys driver → references/windows-re.md (kernel section) or references/anticheat-re.md
• Assembly-CSharp.dll → Unity → references/managed-code-re.md (Unity section)
• Unknown/firmware → references/firmware-embedded.md (binwalk + entropy)

Task-type decision tree (applies to any format):

• Stripped binary, unknown functions → references/symbol-recovery.md
• Unknown struct layouts in decompilation → references/struct-recovery.md
• Need to run just one function in isolation → references/unicorn-emulation.md
• Using IDA Pro for analysis → references/idapython.md
• Using Ghidra for analysis → references/ghidra-scripting.md

2. Establish Scope

Ask the user (or infer from context):

• Goal: understand logic / find vuln / bypass protection / patch / CTF flag / malware IOCs?
• Platform: Linux / Windows / macOS / Android / iOS / embedded?
• Tools available: Ghidra / IDA / radare2 / Binary Ninja / Hopper?
• Dynamic possible?: Can we run it? VM? Emulator? Physical device?

3. Choose Analysis Mode

Static only  → No execution risk, slower understanding
Dynamic only → Fast but misses dead code
Static + Dynamic (recommended) → Static for map, dynamic for runtime truth

Core Toolchain Summary

Static

Dynamic

Network

Methodology Frameworks

Static Analysis Workflow

1. file + strings + checksec           → quick triage
2. Entropy analysis                    → packed/encrypted?
3. Import table / symbol table         → understand capabilities
4. Load in decompiler                  → rename, retype, annotate
5. Identify key functions              → main(), crypto, network, anti-debug
6. Trace data flow                     → user input → sink
7. Document findings                   → comment inline

Dynamic Analysis Workflow

1. Set up isolated environment         → VM / container / device
2. Run with strace/ltrace first        → understand syscall footprint
3. Attach debugger                     → set breakpoints at key functions
4. Observe runtime behavior            → memory, registers, branches taken
5. Correlate with static              → validate decompiler output
6. Patch / hook as needed             → bypass checks, log values

Vulnerability Discovery Workflow

1. Attack surface mapping             → inputs: file, network, env vars, args
2. Dangerous function search          → strcpy, gets, sprintf, memcpy, system
3. Integer overflow candidates        → size calculations, loops
4. Format string candidates           → printf(user_input)
5. UAF / double-free candidates       → heap allocation patterns
6. Trigger + confirm                  → crash → controlled → exploitable

Anti-Analysis Bypass — Quick Reference

Anti-Debug Detection

# Check if binary detects debugger
strings <bin> | grep -iE "ptrace|debugger|isDebuggerPresent|TracerPid"

# Linux: ptrace self-detection
# Bypass: preload hook or patch the ptrace call

Common Protections

Output Standards

When reporting RE findings, always structure output as:

## Binary: <name>
- **Format**: ELF64 / PE32+ / DEX / Mach-O
- **Arch**: x86_64 / ARM64 / ARMv7 / MIPS
- **Stripped**: Yes/No | **PIE**: Yes/No | **NX**: Yes/No

## Key Findings
1. <function name @ offset> — <what it does>
2. ...

## Vulnerability / Behavior
- <description with evidence>
- Offset: 0x<addr>
- Triggerable via: <input vector>

## Recommended Next Steps
- [ ] <action>

Naming Conventions for Decompiler Work

Follow these standards when annotating in Ghidra / IDA / r2:

Functions:  verb_noun_context      → decrypt_config_xor, check_license_hwid
Variables:  type_purpose           → buf_user_input, sz_packet, ptr_heap_chunk
Structs:    ST_<name>              → ST_PacketHeader, ST_LicenseData
Labels:     loc_<purpose>         → loc_anti_debug_fail, loc_success

Scripting Quick Starters

See references/frida.md for full Frida patterns.

GDB Python one-liner (log function args)

# In GDB: source this file
import gdb
class LogArgs(gdb.Breakpoint):
    def stop(self):
        frame = gdb.selected_frame()
        print(f"[*] {frame.name()} rdi={gdb.parse_and_eval('$rdi')} rsi={gdb.parse_and_eval('$rsi')}")
        return False  # don't stop, just log
LogArgs("target_function")

radare2 batch analysis

r2 -A -q -c "afl~suspicious; pdf @ sym.check_license" <binary>

Ghidra headless analysis

$GHIDRA_HOME/support/analyzeHeadless /tmp/proj MyProject \
  -import <binary> -postScript PrintAST.java -scriptPath ~/ghidra_scripts