reversing-technique

# Reverse Engineering Technique **Extract actionable intelligence efficiently** by adapting workflow to your objective. ## When to activate - **Malware analysis**: Understand behavior, C2, persistence, evasion. - **Software protection analysis**: Identify license/protection logic, emulate validation checks, reconstruct key material where authorized. - **Patch diffing**: Find security fixes, understand vendor patches. - **OS/runtime behavior verification**: Recover a version-bound rule from matching sources, symbols, disassembly, and a controlled execution trace. - **Firmware reversing**: Extract filesystems, analyze embedded code. - **.NET reversing**: Deobfuscate, understand managed code logic. - **Protocol reversing**: Reconstruct proprietary protocols or file formats. - **Vulnerability hunting**: Find bugs in closed-source components. - **Exploitability triage**: Qualify a corruption primitive found during RE, then hand off to `binary-exploitation-technique` for chaining and proof. - **Secrets extraction**: Recover keys, tokens, passwords. - **Custom VM / obfuscation**: Binary has a bytecode VM, LLVM CFF dispatcher, or VMProtect/Themida packing. - **Anti-analysis bypass**: Binary exits under debugger, detects VM, crashes analysis tools, or uses signal-handler tricks. - **Side-channel RE**: Validation timing, instruction count, or signal behavior leaks per-character correctness. - **Language-specific RE**: Go, Rust, Python bytecode, Unity IL2CPP, Nim, VBS/WSH, Node.js/V8 snapshots requires language-specific tooling (see `references/languages.md`, `references/nim-rev.md`, `references/node-v8-snapshots.md`). - **In-memory loading**: Linux binary loads a second-stage ELF via `memfd_create` + `dlopen` (fileless; see `references/in-memory-loading.md`). ## Initial triage Before diving deep, classify the artifact and the operator objective so the workflow starts in the right lane. - **Starting state**: is the target malware, protected software, firmware, a managed assembly, a protocol artifact, a crash primitive, or an unknown binary? - **First questions**: what do you need to learn first, what architecture/runtime/packing signals are present, and is static or dynamic evidence the fastest way to reduce uncertainty? - **Immediate actions**: perform fast format/entropy/import/string triage, assign the objective workflow, and only then choose the decompiler/debugger/tooling mix. - **Tool-family direction**: start with CLI/static triage families (`radare2`, `objdump`, `readelf`, `strings`, `capa`, `binwalk`) and escalate to heavy decompilation/debugging (`ghidra`, `binaryninja`, `gdb`, `x64dbg`, `windbg`, `dnspy`, `frida`) once the goal is defined. - **Escalation rule**: objective first, tool second; do not decompile everything before deciding what question you are answering. ## Core methodology ``` 1. Triage (5-10 min): Quick assessment before deep dive. 2. Define objective: What do you need to know? 3. Select tools: Based on binary type, objective, environment. 4. Static analysis: Structure understanding without execution. 5. Dynamic analysis: Validate assumptions via runtime behavior. 6. Synthesis: Pseudocode, documentation, or exploit. 7. Verification: Test findings; iterate if needed. ``` ## Triage (first 5-10 minutes) Quick assessment to decide approach: | Check | Tool reference | What to look for | |-------|-----------------|-------------| | File type | `file`, `detect-it-easy` | PE/ELF/Mach-O/.NET, arch, bits | | Packers/obfuscation | `Detect It Easy`, `binwalk` | UPX, ASPack, ConfuserEx, high entropy | | Strings | `strings`, `radare2` (`iz`) | URLs, IPs, registry keys, crypto constants | | Imports/exports | `radare2` (`ii`, `ie`), `ghidra` | Suspicious APIs, crypto, network, process | | Metadata | `pefile`, `radare2` (`iI`) | Timestamps, version, compiler, PDB | | Hashes | `sha256sum`, `rahash2` | Submit to VirusTotal, MalwareBazaar | | Capabilities | `capa` (`offensive-tools/forensic/capa/`) | TTP fingerprint, malware family, embedded shellcode | **Decision tree:** - High entropy + suspicious imports → **Malware analysis** workflow - Protection messages (registration, trial, activation) → **Software protection** workflow - Two versions of same binary → **Patch diffing** workflow - Firmware header (uImage, vmlinux) → **Firmware** workflow - .NET assembly → **.NET reversing** workflow - Network capture + unknown protocol → **Protocol RE** workflow - Large `switch(opcode)` + byte-buffer IP loop → **Custom VM** workflow (see `references/custom-vm.md`) - `fork()` + `ptrace(TRACEME)` or `SIGTRAP`/`SIGFPE` signal loop → **Nanomites** (see `references/custom-vm.md §2`) - Binary exits/behaves differently under debugger or in VM → **Anti-analysis bypass** (see `references/anti-analysis.md`) - Validation response varies by character (timing/count) → **Side-channel RE** (see `references/custom-vm.md §4`) - Go buildid / Rust `__rust_panic` / `.pyc` file → **Language-specific RE** (see `references/languages.md`) - LLVM control flow flattening (dispatcher switch, state variable) → `references/custom-vm.md §6` - VMProtect / Themida packing detected → dump after OEP (see `references/anti-analysis.md §unpacking`) - `NimMain` / `HEXnn` mangled names / `@[` slice constants → **Nim RE** (see `references/nim-rev.md`) - `pkg/prelude` / `NODE_SEA_FUSE` / `snapshot_blob` in strings → **Node.js/V8 snapshot** (see `references/node-v8-snapshots.md`) - `memfd_create` in strace / `/proc/self/fd/` path to `dlopen` → **In-memory loading** (see `references/in-memory-loading.md`) - `ljmp 0x33:` / `push 0x33; retf` in 32-bit ELF → **Heaven's Gate Linux** (see `references/anti-analysis.md §Category 8`) - PCAP / protobuf / gRPC / grpc-web / WebSocket frames / length-prefixed binary RPC → **Protocol reversing** (see `references/protocol-rev.md`) - `.crx` / `.xpi` / `manifest.json` / MV3 service worker / `content_scripts` / `externally_connectable` → **Browser extension reversing** (see `references/browser-extension-rev.md`) - Two binary versions for patch analysis / a single Microsoft Patch-Tuesday MSU to reconstruct / stripped library with unknown symbols → **Binary diffing / FLIRT** (see `references/binary-diffing.md`) - Confirmed overwrite primitive with partial control over RIP/EIP/PC, heap metadata, or function pointer → **Exploitability triage** (§7b), then hand off to `offensive-techniques/binary-exploitation-technique` - Kernel driver/module, hidden artifacts, boot-chain tampering, or EFI/bootloader changes → **Rootkit / bootkit RE** workflow (see `references/rootkit-and-bootkit-re.md`) ## CLI-first tool preference Prefer CLI/scriptable tooling for triage, batch work, and repeatable evidence. Move to GUI decompilers/debuggers when semantics, types, or interaction speed justify it. | Need | Prefer first | GUI/decompiler escalation | |---|---|---| | File metadata, imports, sections, strings | `rabin2`, `radare2`, `objdump`, `readelf`, `strings` | Ghidra/Binary Ninja project when structure matters | | Fast static triage | `radare2` (`aaa`, `afl`, `iz`, `ii`, `iS`), `capa` | Ghidra for decompilation and type recovery | | Linux dynamic behavior | `strace`, `ltrace`, `gdb` | Ghidra debugger only if needed | | Windows crash/debug | `windbg`/`cdb` for dump triage | `x64dbg` for interactive patch/trace | | Firmware extraction | `binwalk` CLI first | Ghidra/radare2 per extracted binary | | .NET | `de4dot`/CLI metadata first | `dnspy` for decompile/debug/patch | Formal tool skills: `offensive-tools/rev/radare2/`, `offensive-tools/rev/gdb/`, `offensive-tools/rev/frida/`, `offensive-tools/rev/binwalk/`, `offensive-tools/rev/ghidra/`, `offensive-tools/rev/binaryninja/`, `offensive-tools/rev/dnspy/`, `offensive-tools/rev/windbg/`, `offensive-tools/rev/x64dbg/`, plus `offensive-tools/forensic/capa/` for capability triage. ## Objective-driven workflows ### 1. Malware analysis **Goal**: Understand behavior, extract IOCs, identify C2, assess threat. **Operator flow:** ``` 1. Triage: strings, imports, VirusTotal, Any.Run sandbox report. 2. Static: Load in `ghidra` or `radare2` → auto-analysis. - Check imports for: VirtualAlloc, CreateRemoteThread, WriteProcessMemory. - Cross-reference suspicious strings (URLs, IPs, registry paths). - Identify decryption routines (loops with XOR/RC4/AES). 3. Dynamic: Debug in `x64dbg` (Windows) or `gdb`+`pwndbg` (Linux). - Set breakpoints on crypto APIs, network APIs. - Dump decrypted strings/config from memory. - Monitor: Process Monitor, Wireshark, ProcMon. - Linux: use `strace -e trace=network,file` to log syscalls without a debugger; `ltrace` for library call interception. 4. Unpack if packed: Use `x64dbg` + Scylla, or `binwalk` for firmware. 5. Report: IOCs, TTPs, C2 config, YARA rules. ``` **Key tricks:** - Decryption routines often precede string usage—trace backwards from strings. - Config often in resources or appended to binary—check `binwalk`, `radare2` (`iS`). - Anti-debug: PEB.BeingDebugged, NtGlobalFlag, RDTSC—use `ScyllaHide` or patch. - C2 often encrypted with simple XOR—search for XOR loops with constant key. **Key tools:** `capa` (TTP triage), `ghidra`/`radare2` (static), `x64dbg`/`gdb`+`pwndbg` (dynamic), `frida` (hooking), `binwalk` (unpacking), `strace`/`ltrace` (Linux syscall/lib tracing), `windbg` (crash dumps). → Full workflow: `references/re-workflow.md`. Anti-debug bypass: `references/anti-analysis.md`. --- ### 2. Software protection bypass and licensing emulation **Goal**: Understand license/protection checks, emulate validation, and produce authorized proof of bypass or key-generation logic. **Operator flow:** ``` 1. Triage: Identify protection (ASProtect, Themida, custom). 2. Static: Load in `ghidra` → find protection strings, error messages. - Search for: "Invalid key", "Trial expired", "Wrong password". - Cross-reference strings to validation functions. 3. Dynamic: Debug in `x64dbg` or `radare2` debugger. - Set breakpoint on validation function or message box. - Trace backwards to find comparison logic. - Patch: NOP conditional jump, or change return value. 4. Key reconstruction: Understand algorithm from decompiled code. - Reconstruct in Python/C based on pseudocode. 5. Verify: Patched binary accepts valid key. ``` **Key tricks:** Cross-ref error strings to validation functions; NOP/invert the final comparison; watch for CRC re-checks after patching. **Key tools:** `ghidra` (decompile validation), `x64dbg` (patch jumps), `frida` (hook online activation), `dnspy` (.NET). → Unpacking details: `references/anti-analysis.md §unpacking`. Binary diffing: `references/binary-diffing.md`. --- ### 3. Patch diffing **Goal**: Find what changed between two binary versions (security patch, CVE reconstruction). - Run `radiff2 -g main old new` or Ghidra Version Tracking to correlate functions. - Focus on functions with added `if` / early-return → likely security fix. - Verify the bug is reachable before claiming exploitability. → Full workflow with FLIRT, BinDiff, and symbol recovery: `references/binary-diffing.md`. --- ### 4. Firmware reversing **Goal**: Extract filesystem, analyze embedded binaries, find backdoors. **Operator flow:** ``` 1. Triage: Identify firmware type (router, IoT, BIOS, etc.). - Check magic bytes: uImage (0x27051956), vmlinux, squashfs, etc. 2. Extract: preserve/hash first, identify the outer format, then follow `references/firmware-rev.md` for isolated, bounded extraction. 3. Analyze filesystem: - `squashfs-root/`: config files, web interfaces, binaries. - Search for: hardcoded credentials, backdoor accounts, crypto keys. 4. Reverse embedded binaries: - Identify arch: MIPS, ARM, AVR (use `radare2` or `ghidra`). - Load in appropriate tool with correct base address. 5. Emulate (optional): QEMU user-mode for MIPS/ARM binaries. ``` **Key tricks:** - Firmware often has: Telnet backdoors, hardcoded SNMP community strings, private keys. - Web interfaces: check for command injection (ping, traceroute), path traversal. - Embedded binaries may be stripped → use `radare2` zignatures or `ghidra` function ID. - Check `/etc/passwd`, `/etc/shadow`, SSH keys, certificate files. **Tool citations:** - `binwalk` — signature scan, extraction, entropy analysis. - `ghidra` — analyze MIPS/ARM binaries, recover structs. - `radare2` — headless analysis, scripting for batch processing. - `frida` — dynamic analysis if firmware runs on emulated device. **Common pitfalls:** - Wrong architecture → decompilation nonsense. - Wrong base address → function calls go to invalid addresses. - Ignoring filesystem configs → missing high-value IOCs. --- ### 5. .NET reversing (managed code) **Goal**: Understand C#/VB.NET logic, bypass obfuscation, extract configs. 1. Detect obfuscator: `de4dot --detect sample.exe` 2. Deobfuscate: `de4dot sample.exe -o clean.exe` 3. Analyze in `dnspy` — start at Entry Point (Ctrl+Shift+K); set breakpoints on decryption/config load 4. Watch for multi-stage loaders: `Assembly.Load()` + `GetManifestResourceStream` call sites 5. Network isolation is mandatory before dynamic debugging stealers/RATs **Key tools:** `dnspy` (decompiler/debugger/patcher), `de4dot` (deobfuscation), `ghidra` (fallback). → Full deobfuscation table, ConfuserEx/Reactor flags, config extraction: `references/dotnet-rev.md`. --- ### 6. Protocol reversing **Goal**: Reconstruct proprietary protocol, understand message format. **Operator flow:** ``` 1. Capture traffic: Wireshark, tcpdump, or `frida` SSL pinning bypass. 2. Triage: Identify protocol type (text, binary, encrypted). - Look for magic bytes, length fields, checksums. 3. Static: Analyze client/server binaries in `ghidra`. - Find send/recv functions → cross-reference to protocol handlers. - Reconstruct structs from serialization code. 4. Dynamic: Hook send/recv with `frida` → log raw packets. - Correlate with network capture. 5. Document: Message format, state machine, encryption (if any). ``` **Key tricks:**