Rust Reverse Engineering

Rust Reverse Engineering

Reverse engineer Rust-compiled binaries methodically. Start with fast triage, confirm that the target is actually Rust, recover namespaces and runtime clues, then move into static or dynamic analysis with a clear hypothesis.

Do not jump straight into decompiler output and treat it as source truth. Rust binaries often contain compiler-generated glue, monomorphized generic code, panic paths, and async state machines that will drown the signal if you skip the triage stage.

When to Use

Use this skill when the user wants to:

• analyze a Rust executable, shared library, static archive, .rlib, or object file
• confirm whether a binary was built from Rust
• demangle Rust symbols and recover likely crate namespaces
• trace entry points, panic/unwind paths, FFI exports/imports, or async executors
• understand high-level architecture without source code
• prepare a Rust binary for deeper work in Ghidra, IDA, Binary Ninja, gdb, or lldb

When NOT to Use

Do not use this skill when:

• the user already has the Rust source code and wants normal code review or debugging
• the target is primarily an Android APK/DEX/JAR/AAR package — use an Android-focused workflow instead
• the task is generic PE/ELF malware triage with no Rust-specific angle
• the request is to bypass licensing, DRM, or authorization controls on software the user is not authorized to analyze

Prerequisites

Required command-line tools:

• file
• strings
• readelf or llvm-readelf for ELF, or otool for Mach-O
• nm or llvm-nm
• objdump or llvm-objdump, or otool on macOS

Recommended:

• rustfilt
• gdb or lldb
• Ghidra, IDA Pro, or Binary Ninja

Verify availability first:

bash <path-to-skill>/scripts/check-deps.sh

If tooling is missing, install one dependency at a time:

bash <path-to-skill>/scripts/install-dep.sh rustfilt
bash <path-to-skill>/scripts/install-dep.sh ghidra

If automatic installation is not possible on the current machine, read references/setup-guide.md.

Workflow

Phase 1: Check and install dependencies

Run the dependency checker first:

bash <path-to-skill>/scripts/check-deps.sh

Parse the output looking for:

• INSTALL_REQUIRED:
• INSTALL_OPTIONAL:

If required tooling is missing, install it one dependency at a time:

bash <path-to-skill>/scripts/install-dep.sh <dependency>

The installer:

• uses Homebrew when available on macOS
• uses apt, dnf, or pacman on Linux when available
• uses cargo install rustfilt for rustfilt when cargo exists
• prints exact manual instructions and exits when a dependency cannot be installed automatically

For optional tooling, recommend at least:

• rustfilt
• one debugger: gdb or lldb
• ghidra

Re-run check-deps.sh after installation attempts. Do not proceed until all required dependencies show OK.

Phase 2: Materialize reverse-engineering artifacts first

Do not keep the analysis ephemeral. Create an artifact bundle on disk before doing interpretation.

bash <path-to-skill>/scripts/collect-artifacts.sh /path/to/binary

The script writes a reusable output directory:

<target>-reverse-output/
├── input/
├── triage/
├── symbols/
├── headers/
├── disassembly/
├── decompiled/
│   └── ghidra/
└── reports/

Treat this directory as the source of truth for the rest of the workflow. It should contain:

• triage/summary.txt — file type, architecture, strip/debug-info status, Rust confidence
• triage/strings.txt and triage/interesting-strings.txt — raw and filtered strings
• symbols/raw.txt, symbols/demangled.txt, symbols/namespaces.txt, symbols/imports.txt, symbols/exports.txt
• headers/* — readelf, otool, or PE header dumps
• disassembly/disassembly.txt — best-effort disassembly when available
• decompiled/ghidra/status.txt, summary.txt, functions.tsv, decompile-errors.tsv, and functions/*.c — headless Ghidra pseudocode artifacts when available
• reports/summary.md and reports/pattern-hits.txt

Phase 3: Fast triage before any deep analysis

If you need a quick rerun or a narrower pass, the underlying triage script is still available.

bash <path-to-skill>/scripts/triage.sh /path/to/binary

Capture these facts before doing anything else:

1. Container and file type

   • ELF, Mach-O, PE/COFF, static archive, object file, or .rlib
   • target architecture and bitness
   • executable vs shared library vs archive

2. Symbol quality

   • stripped vs not stripped
   • exported vs imported symbols
   • whether a usable symbol table still exists

3. Debug-info availability

   • DWARF sections
   • macOS DWARF segments / dSYM hints
   • Windows PDB hints in strings
   • split-debug or external-debug indicators when visible

4. Rust confidence

   • v0 or legacy Rust mangling patterns
   • demangled core::, alloc::, std::, or crate-like namespaces
   • panic/unwind strings and runtime artifacts
   • Rust-specific crate names in symbols or strings

Do not describe the binary as “definitely Rust” from a single clue. Use multiple, independent signals.

Phase 4: Recover symbols and namespaces

Dump symbols and demangle them as early as possible.

bash <path-to-skill>/scripts/demangle-symbols.sh /path/to/binary

Focus on these buckets:

• standard runtime buckets: core::, alloc::, std::, panic, unwinding, formatting
• user-space buckets: crate-like top-level namespaces that are not runtime crates
• interop buckets: main, _start, exported C ABI functions, imported libc / Win32 / networking APIs
• framework buckets: likely third-party crates such as serialization, async runtimes, HTTP stacks, crypto, CLI parsing, and logging

Build a short namespace inventory:

- runtime crates:
- likely app crates:
- likely third-party crates:
- exported ABI functions:
- imported platform APIs:

Use references/triage-and-fingerprinting.md for the triage rubric and references/rust-patterns.md for common Rust-specific fingerprints.

For targeted bucket searches across the generated artifacts, run:

bash <path-to-skill>/scripts/find-rust-patterns.sh <target>-reverse-output

Phase 5: Recover high-level structure without assuming a stable Rust ABI

Recover structure conservatively.

Look for:

1. Entry and boundary functions

   • _start, main, CRT glue, loader entry points
   • exported extern "C" / no_mangle style boundaries
   • plugin or callback registration functions
   • thread starts, task executors, and worker loops

2. Subsystem anchors

   • config parsing
   • logging initialization
   • network / filesystem / crypto imports
   • panic setup and error paths
   • serialization and IPC edges

3. Call-shape clues

   • large dispatcher-style functions that may be async state machines
   • indirect calls through vtable-like structures
   • formatter-heavy branches around error handling or panic paths
   • repeated monomorphized helpers with type-specific variants

Critical rule: do not assume undocumented Rust layouts are stable.

• Treat Option, Result, Vec, String, trait objects, and closure layouts as hypotheses until confirmed by debug info, repeated call-site evidence, or explicit repr(C) / repr(transparent) style interop boundaries.
• Do not label every two-word structure as a trait object.
• Do not infer source-level module boundaries from one demangled symbol alone; confirm using clusters of neighboring symbols, xrefs, and strings.