reverse-engineering-analysis

name

reverse-engineering-analysis

description

Plan and run safe reverse engineering, decompilation, disassembly, instrumentation, and post-processing workflows for binaries, firmware, mobile apps, WebAssembly, JavaScript bundles, and .NET assemblies. Use when the user asks for reversing strategy, decompiler selection, binary analysis, malware-style triage, Wakaru, Ghidra, IDA, RetDec, radare2, Rizin, Frida, angr, YARA, or command scripts that capture analysis stats.

Reverse Engineering Analysis

Use this skill to turn an unknown artifact into calibrated Security Signals, ranked Hypotheses, and durable Evidence. Prefer passive inspection, local emulation, isolated execution, and reproducible command logs. See GLOSSARY.md for shared term definitions.

Handoffs: Use proactive-security-strategy when a patch or CVE is the starting point. Use exploitation-sandbox to verify a Hypothesis with a PoC once a primitive is located. Use bug-hunt-planner to structure a full hunting plan around the binary's surface.

Quick Start

1. Preserve the artifact. Work on a copy and record hash, size, timestamps, source, permissions, and container/package metadata.
2. Run static triage: file, sha256sum, strings, readelf/objdump/nm, hexdump, package manifests, and entropy/packer checks.
3. Pick the decompiler path from TOOL-MATRIX.md: native binary, JavaScript bundle, WebAssembly, .NET/JVM, firmware, mobile, or managed package.
4. Wrap every long-running command with scripts/capture-command-stats.sh or equivalent logic.
5. Post-process outputs into smaller searchable artifacts: function indexes, symbol tables, call graphs, string clusters, API usage, config values, routes, and suspicious constants.
6. Record outputs as Evidence and large bodies as linked Artifacts.

Required Stats

For every command that produces analysis output, capture enough pre/post stats to scan results later:

• Command, arguments, tool version, working directory, environment notes, start/end time, duration, and exit code.
• Input file count, total bytes, hashes, file types, and relevant archive member counts.
• Output file count, total bytes, per-file bytes, line counts, function counts when available, and truncation notes.
• Stdout/stderr byte counts and line counts, plus warnings, crashes, timeouts, and killed processes.
• Comparison stats for post-processing: before/after line counts, deduplicated rows, matched signatures, named functions, and unresolved symbols.

Strategy Menu

• Static first: identify format, architecture, compiler hints, imports, exports, strings, sections, resources, and embedded artifacts before executing anything.
• Decompiler fanout: run two or more decompilers when possible, then diff function names, call graphs, recovered types, and suspicious branches.
• Patch-oriented reversing: compare vulnerable/fixed versions, locate changed functions, and lift patch intent into a testable Hypothesis.
• Dynamic isolation: use GDB, QEMU, Valgrind, Unicorn, Frida, PIN, or sandboxed VM snapshots only after static triage.
• Symbol recovery: apply debug symbols, PDBs, DWARF, public symbol servers, type libraries, FLIRT/signature packs, demanglers, and package source maps.
• Post-processing: normalize decompiler output, split by function, strip addresses when diffing, cluster strings, extract routes/configs/secrets with redaction, and build indexes.
• Semantic analysis: use angr, Triton, Miasm, BAP, Capstone, Dyninst, or Unicorn for path constraints, taint-like reasoning, lifting, coverage, and emulation.
• Signature analysis: write YARA rules for observed traits, but validate them against clean and near-neighbor samples to avoid brittle matches.

Decompilation Paths

• Native ELF/PE/Mach-O: Ghidra, IDA Pro, Binary Ninja, Hopper, RetDec, radare2/r2ghidra, Rizin/rz-ghidra, Cutter, Snowman.
• JavaScript bundles: Wakaru for modern frontend debundling/decompilation; also use source maps, AST parsers, formatters, bundler metadata, and chunk graph recovery.
• WebAssembly: WABT tools such as wasm-objdump, wasm-decompile, and wasm2c; compare imports/exports, tables, memory usage, and host bindings.
• .NET/JVM: ILSpy/dnSpy/dotPeek/.NET IL Viewer for .NET; CFR/FernFlower/Procyon/JD-GUI for JVM bytecode.
• Firmware/mobile: binwalk, unsquashfs, apktool, jadx, class-dump, otool, nm, strings, Ghidra loaders, QEMU user/system emulation.

See EXAMPLES.md for command patterns and SAFETY.md for tool-specific risk analysis.

Analysis Output

Present findings as:

• Artifact inventory: hash, type, architecture, packaging, tool versions, and command stats.
• Security Signals: concrete observations with source, confidence, and affected Subject.
• Hypotheses: ranked next steps with target surface, rationale, expected Evidence, and stop condition.
• Open gaps: missing symbols, failed tools, anti-analysis behavior, packed/encrypted sections, or unsupported architectures.

Guardrails

• Do not run unknown binaries on the host. Use a disposable Workspace Container, VM snapshot, emulator, or offline sandbox.
• Do not connect samples to external networks unless explicitly approved and scoped.
• Redact secrets from strings, configs, logs, screenshots, and summaries.
• Treat malware-style tooling as dual-use: keep work authorized, local, bounded, and reproducible.