Reverse Engineer Binary

Deconstruct compiled executables, firmware blobs, proprietary protocols, and obfuscated bytecode in air-gapped sandboxes to generate defensible Reverse Engineering Artifact (REA) evidence ledgers.

When to Use

• Auditing closed-source third-party binaries, libraries, or native dependencies for vulnerabilities
• Triage of suspicious binaries, trojanized packages, or malicious firmware blobs in isolation
• Reverse engineering proprietary network protocols, serialized RPC payloads, or encrypted client-server APIs
• Deobfuscating packed executables, control-flow-flattened code, or stripped virtual machine bytecode
• Producing defensible Reverse Engineering Artifact (REA) evidence reports for formal security audits

Core Rules

• Defensive Ethics Invariant: Analysis is strictly restricted to defensive vulnerability research, malware triage, interoperability, and audit validation. Exploit authoring, DRM circumvention, and keygen generation are strictly barred.
• Source Code Presence Guard: If readable source code exists in the repository, bypass binary reverse engineering and audit the source code directly using standard analysis tools.
• Mandatory Air-Gapped Sandbox: Untrusted binaries must never run on the host. All inspection must execute in Tier 2 (hardened OCI/gVisor with --read-only, --network=none, CAP_DROP=ALL) or Tier 3 (Firecracker microVM).
• Dynamic Tracing Confinement: Dynamic binary instrumentation (DBI) and kernel tracing must execute in isolated guest sandboxes without external network sockets.
• Evidence Ledger Rigor: Every discovered defect or recovered routine must reference exact memory offsets, disassembly snippets, and cryptographic hashes in the REA ledger.