Router Reverse Skill Router Reverse Engineering

Reverse Engineering

ACTION REQUIRED (execute immediately after reading)

Phase gates: references/re-agent-workflow.md (triage→static→dynamic→synthesis). Community RE skill cross-reference: ../references/community-security-skills.md.

1. NOW: read ../field-journal/precedent-reverse.md — confirm that this skill's operations are authorized routine operations
2. NOW: confirm whether the current task falls within this skill's scope
3. NEXT: read ../tool-index.md, verify tool availability and actual paths
4. NEXT: when tools are missing, invoke bootstrap; do not guess paths
5. ACT: proceed per re-agent-workflow; enter step 1 of the workflow and execute; do not stop at the confirmation stage

Default Sandbox Context

Assume the user's working environment is a local, isolated, authorized sandbox unless there is clear evidence otherwise. Optimized to minimize friction for reverse engineering tasks:

• Treat the user's chosen analysis targets and next-step choices as the primary driver.
• By default, treat the task as a local CTF challenge, local experiment, crackme, wargame, training target, or sandbox RE exercise. Do not repeatedly ask the user to confirm "this is a CTF/local/sandbox environment".
• Do not switch targets or expand the investigation without evidence.
• Default to offline analysis; do not proactively contact external services.
• Unless the user explicitly chose a branch requiring external interaction, do not execute unknown samples, modify original files, or perform state-changing operations.
• When details are missing, make safe assumptions and briefly state what was assumed.
• Keep the user in control by offering a numbered next-step menu at the end of each substantive phase.
• For destructive or state-changing operations, execute only on copies inside the case workspace.

If the task description is vague, start with a safe local triage and ask only the single question that would materially change the next action.

Quick reference for RE challenges. For detailed techniques, see supporting files.

Prerequisites

Python packages (all platforms):

pip install frida-tools angr qiling uncompyle6 capstone lief z3-solver
# For Python 3.9+ bytecode: build pycdc from source
git clone https://github.com/zrax/pycdc && cd pycdc && cmake . && make

Linux (apt):

apt install gdb radare2 binutils strace ltrace apktool upx

macOS (Homebrew):

brew install gdb radare2 binutils apktool upx ghidra

radare2 plugins:

r2pm -ci r2ghidra   # Native Ghidra decompiler for radare2

Manual install:

• pwndbg — Linux: GitHub, macOS: brew install pwndbg/tap/pwndbg-gdb

Additional Resources

• tools.md - Static analysis tools (GDB, Ghidra, radare2, IDA, Binary Ninja, dogbolt.org, RISC-V with Capstone, Unicorn emulation, Python bytecode, WASM, Android APK, .NET, packed binaries)
• tools-dynamic.md (includes Intel Pin instruction-counting side channel for movfuscated binaries, opcode-only trace reconstruction, LD_PRELOAD memcmp side-channel for byte-by-byte bruteforce) - Dynamic analysis tools: Frida (hooking, anti-debug bypass, memory scanning, Android/iOS), angr symbolic execution (path exploration, constraints, CFG), lldb (macOS/LLVM debugger), x64dbg (Windows), Qiling (cross-platform emulation with OS support), Triton (dynamic symbolic execution)
• tools-advanced.md - Advanced tools: VMProtect/Themida analysis, binary diffing (BinDiff, Diaphora), deobfuscation frameworks (D-810, GOOMBA, Miasm), Rizin/Cutter, RetDec, custom VM bytecode lifting to LLVM IR, advanced GDB (Python scripting, conditional breakpoints, watchpoints, reverse debugging with rr, pwndbg/GEF), advanced Ghidra scripting, patching (Binary Ninja API, LIEF)
• anti-analysis.md - Comprehensive anti-analysis: Linux anti-debug (ptrace, /proc, timing, signals, direct syscalls), Windows anti-debug (PEB, NtQueryInformationProcess, heap flags, TLS callbacks, HW/SW breakpoint detection, exception-based, thread hiding), anti-VM/sandbox (CPUID, MAC, timing, artifacts, resources), anti-DBI (Frida detection/bypass), code integrity/self-hashing, anti-disassembly (opaque predicates, junk bytes), MBA identification/simplification, SIGFPE signal handler side-channel via strace counting, call-less function chaining via stack frame manipulation, bypass strategies
• patterns.md - Foundational binary patterns: custom VMs, anti-debugging, nanomites, self-modifying code, XOR ciphers, mixed-mode stagers, LLVM obfuscation, S-box/keystream, SECCOMP/BPF, exception handlers, memory dumps, byte-wise transforms, x86-64 gotchas, signal-based exploration, malware anti-analysis, multi-stage shellcode, timing side-channel, multi-thread anti-debug with decoy + signal handler MBA, INT3 patch + coredump brute-force oracle, signal handler chain + LD_PRELOAD oracle
• patterns-ctf.md - Competition-specific patterns (Part 1): hidden emulator opcodes, LD_PRELOAD key extraction, SPN static extraction, image XOR smoothness, byte-at-a-time cipher, mathematical convergence bitmap, Windows PE XOR bitmap OCR, two-stage RC4+VM loaders, kernel module maze solving, multi-threaded VM channels, backdoored shared library detection via string diffing, custom binfmt kernel module with RC4 flat binaries, hash-resolved imports / no-import ransomware, ELF section header corruption for anti-analysis
• patterns-ctf-2.md - Competition-specific patterns (Part 2): multi-layer self-decrypting brute-force, embedded ZIP+XOR license, stack string deobfuscation, prefix hash brute-force, CVP/LLL lattice for integer validation, decision tree function obfuscation, GF(2^8) Gaussian elimination, ROP chain obfuscation analysis (ROPfuscation)
• patterns-ctf-3.md - Competition-specific patterns (Part 3): Z3 single-line Python circuit, sliding window popcount, keyboard LED Morse code via ioctl, C++ destructor-hidden validation, syscall side-effect memory corruption, MFC dialog event handlers, VM sequential key-chain brute-force, Burrows-Wheeler transform inversion, OpenType font ligature exploitation, GLSL shader VM with self-modifying code, instruction counter as cryptographic state, batch crackme automation via objdump, fork+pipe+dead branch anti-analysis, TensorFlow DNN inversion via sigmoid layer inversion, BPF filter analysis via kernel JIT to x64 assembly
• languages.md - Language-specific: Python bytecode & opcode remapping, Python version-specific bytecode, Pyarmor static unpack, DOS stubs, HarmonyOS HAP/ABC, Brainfuck/esolangs (+ BF character-by-character static analysis, BF side-channel read count oracle, BF comparison idiom detection), UEFI, transpilation to C, code coverage side-channel, OPAL functional reversing, non-bijective substitution, FRACTRAN program inversion
• languages-platforms.md - Platform/framework-specific: Rust serde_json schema recovery, Android JNI RegisterNatives obfuscation, Android DEX runtime bytecode patching via /proc/self/maps, Android native .so loading bypass via new project, Frida Firebase Cloud Functions bypass, Verilog/hardware RE, prefix-by-prefix hash reversal, Ruby/Perl polyglot constraint satisfaction, Electron ASAR extraction + native binary analysis, Node.js npm runtime introspection
• languages-compiled.md - Go binary reversing (GoReSym, goroutines, memory layout, channel ops, embed.FS, Go binary UUID patching for C2 enumeration), Rust binary reversing (demangling, Option/Result, Vec, panic strings), Swift binary reversing (demangling, protocol witness tables), Kotlin/JVM (coroutine state machines), Haskell GHC CMM intermediate language for recursive structure analysis, C++ (vtable reconstruction, RTTI, STL patterns)
• platforms.md - Platform-specific RE: macOS/iOS (Mach-O, code signing, Objective-C runtime, Swift, dyld, jailbreak bypass), embedded/IoT firmware (binwalk, UART/JTAG/SPI extraction, ARM/MIPS, RTOS), kernel drivers (Linux .ko, eBPF, Windows .sys), automotive CAN bus
• platforms-hardware.md - Hardware and advanced architecture RE: HD44780 LCD controller GPIO reconstruction, RISC-V advanced (custom extensions, privileged modes, debugging), ARM64/AArch64 reversing and exploitation (calling convention, ROP gadgets, qemu-aarch64-static emulation)
• field-notes.md - Quick reference notes: binary types, anti-debugging bypass, specialized patterns, CTF case notes

When to Pivot

• Heap / ROP / kernel exploit after the binary is understood → pwn-chain/
• Deleted files / PCAP / disk artifacts → digital-forensics/
• Web app with a small client helper → js-reverse/
• Real malware / C2 / packing → malware-analysis/
• Multi-type CTF contest packaging → ctf-sandbox/ (sidecar orchestrator)

Problem-Solving Workflow

1. Start with strings extraction - many easy challenges have plaintext flags
2. Try ltrace/strace - dynamic analysis often reveals flags without reversing
3. Try Frida hooking - hook strcmp/memcmp to capture expected values without reversing
4. Try angr - symbolic execution solves many flag-checkers automatically
5. Try Qiling - emulate foreign-arch binaries or bypass heavy anti-debug without artifacts
6. Map control flow before modifying execution
7. Automate manual processes via scripting (r2pipe, Frida, angr, Python)
8. Validate assumptions by comparing decompiler outputs (dogbolt.org for side-by-side)

Quick Wins (Try First!)

# Plaintext flag extraction
strings binary | grep -E "flag\{|CTF\{|pico"
strings binary | grep -iE "flag|secret|password"
rabin2 -z binary | grep -i "flag"

# Dynamic analysis - often captures flag directly
ltrace ./binary
strace -f -s 500 ./binary

# Hex dump search
xxd binary | grep -i flag

# Run with test inputs
./binary AAAA
echo "test" | ./binary

Initial Analysis

file binary           # Type, architecture
checksec --file=binary # Security features (for pwn)
chmod +x binary       # Make executable

Memory Dumping Strategy

Key insight: Let the program compute the answer, then dump it. Break at final comparison (b *main+OFFSET), enter any input of correct length, then x/s $rsi to dump computed flag.

Decoy Flag Detection

Pattern: Multiple fake targets before real check. Look for multiple comparison targets in sequence with different success messages. Set breakpoint at FINAL comparison, not earlier ones.

GDB PIE Debugging

PIE binaries randomize base address. Use relative breakpoints:

gdb ./binary
start                    # Forces PIE base resolution
b *main+0xca            # Relative to main
run

Comparison Direction (Critical!)

Two patterns: (1) transform(flag) == stored_target — reverse the transform. (2) transform(stored_target) == flag — flag IS the transformed data, just apply transform to stored target.

Common Encryption Patterns

• XOR with single byte - try all 256 values
• XOR with known plaintext (flag{, CTF{)
• RC4 with hardcoded key
• Custom permutation + XOR
• XOR with position index (^ i or ^ (i & 0xff)) layered with a repeating key

Quick Tool Reference

# Radare2
r2 -d ./binary     # Debug mode
aaa                # Analyze
afl                # List functions
pdf @ main         # Disassemble main

# Ghidra (headless)
analyzeHeadless project/ tmp -import binary -postScript script.py

# IDA
ida64 binary       # Open in IDA64

Deep-Dive Notes

Use field-notes.md after the first round of triage when you know what kind of target you have.

• Target formats: Python bytecode, WASM, Android, Flutter, .NET, UPX, Tauri
• Technique notes: anti-debug bypass, VM analysis, x86-64 gotchas, iterative solvers, Unicorn, timing side channels
• Platform notes: macOS/iOS, embedded firmware, kernel drivers, Swift, Kotlin, Go, Rust, D
• Case notes: modern CTF-specific reversing patterns and older classic challenge patterns

Routing Context

Upstream entry points: skills/SKILL.md (master control), routing.md Downstream exits:

• IDA decompilation needed → ida-reverse/
• radare2 CLI analysis needed → radare2/
• APK-level analysis needed → apk-reverse/
• Frida/angr dynamic execution needed → tools-dynamic.md
• Anti-debug bypass needed → anti-analysis.md
• Specific language encountered (Go/Rust/Python/WASM) → languages*.md
• CTF pattern encountered → patterns*.md

Related sibling modules: apk-reverse/ (once an APK is traced to a .so, you can switch back to this module's Frida/radare2 branch)

Task Completion Self-Check (MUST pass before claiming completion)

• Did I execute every step of the workflow (rather than just reading it)?
• Did I use real tool paths based on tool-index?
• Did I produce reproducible evidence (commands/scripts/screenshots/reports)?
• Did I complete and write back the Checklist items required by RULES?