Untrusted Binary Sandbox

Purpose

Use this skill to plan and execute controlled behavioral observation of untrusted software without trusting the software, its installer, or its documentation. Treat wallet, private-key, trading, MEV, arbitrage, and closed-source crypto tools as high-risk by default.

This skill does not prove safety. It reduces uncertainty for the exact artifact, configuration, runtime, and observation window tested.

Non-Negotiables

• Do not run downloaded binaries, JARs, install scripts, release artifacts, or curl | sh flows unless the user explicitly approves dynamic execution.
• Prefer a sacrificial VM/VPS over a production host. Never mount production secrets, SSH keys, browser profiles, Docker socket, cloud credentials, or funded wallets.
• Never use a real private key during observation. Use invalid keys, empty throwaway wallets, or a tiny-fund wallet only in the final live tier after explicit approval.
• Pin artifact identity before execution: source URL, version, size, SHA-256, timestamp, and any signature/digest metadata.
• Keep confirmed findings separate from risk signals and unknowns. Report confidence level.

Workflow

1. Scope the sample: Identify the artifact, claimed purpose, required command, required secrets, network endpoints, supported OS/CPU, and whether the user is asking for static analysis, dynamic observation, or production feasibility.

2. Static triage first: Hash the artifact, inspect archive contents, review scripts/configs, run file, readelf, objdump, strings, jar tf, or language-specific archive inspection as appropriate. Avoid ldd on untrusted ELF files; use readelf -d or objdump -p instead.

3. Choose the lowest sufficient tier:

   • Tier 0: no-run static analysis only.
   • Tier 1: offline Docker run with network_mode: none.
   • Tier 2: internal-only network with mock RPC/API/DNS sinks.
   • Tier 3: controlled egress with allowlisted endpoints and packet/DNS logging.
   • Tier 4: sacrificial VM/VPS with tiny-fund throwaway wallet for live behavior, only after prior tiers are clean.

4. Build containment: Use non-root users, read_only root filesystem, cap_drop: [ALL], no-new-privileges, PID/CPU/memory limits, tmpfs for scratch, no host networking, no privileged mode, no host path mounts except read-only artifacts/config and writable logs.

5. Instrument before execution: Capture process tree, syscalls, opened files, filesystem writes, DNS queries, outbound connections, child processes, resource use, and any downloaded or modified files. Prefer strace inside Linux containers and VM-level packet capture when network is enabled.

6. Execute briefly and repeat: Start with short timeouts such as 60-180 seconds. Repeat with a known-bad config, mock RPC, then controlled egress. Preserve logs and hashes after each run.

7. Report with judgment: Summarize confirmed behavior, suspicious signals, unknowns, confidence, and a go/no-go recommendation. For wallet software, include a separate private-key exposure assessment.

Stop Criteria

Stop and report immediately if the sample:

• Reads SSH keys, shell history, browser profiles, cloud credentials, .env files, unrelated wallet paths, or host-sensitive directories.
• Writes cron/systemd/profile startup hooks, modifies shell init files, changes file permissions broadly, or downloads and executes new payloads.
• Requires root, host networking, Docker socket, privileged mode, broad host mounts, or disabled sandboxing without a clear technical need.
• Connects to endpoints not declared in config/docs, especially paste sites, generic file hosts, Telegram bot APIs, raw IPs, or newly registered domains.
• Attempts to exfiltrate key material or sends transactions before the expected safe stage.

Solana And Wallet-Specific Rules

• Never mount ~/.config/solana/id.json or any funded wallet.
• Prefer invalid key material or an empty throwaway keypair. Do not print, transform, or store private keys in chat.
• Use a local mock RPC in Tier 2. In Tier 3, allow only explicit RPC/Jito/sender endpoints.
• Treat "encrypt your private key with this binary" as high-risk behavior, not as a safety feature.
• Measure failed transactions, priority-fee burn, Jito tips, and RPC rate-limit pressure separately from malware risk.

Resources

• Read references/docker-sandbox.md when building the actual Docker or VM containment plan.
• Read references/observation-checklist.md when preparing the final evidence report.
• Use scripts/scaffold_sandbox.py to generate a local sandbox scaffold. It creates Docker Compose files and a mock Solana RPC service, but does not execute the sample by default.

Appropriate for: In-depth documentation, API references, database schemas, comprehensive guides, or any detailed information that Codex should reference while working.

assets/

Files not intended to be loaded into context, but rather used within the output Codex produces.

Examples from other skills:

• Brand styling: PowerPoint template files (.pptx), logo files
• Frontend builder: HTML/React boilerplate project directories
• Typography: Font files (.ttf, .woff2)

Appropriate for: Templates, boilerplate code, document templates, images, icons, fonts, or any files meant to be copied or used in the final output.

Not every skill requires all three types of resources.