SoftBox is a controlled execution and behavioral analysis engine for hostile binaries.
What began as a dynamic malware sandbox has evolved into a system for systematically exploring how binaries change behavior under different environmental and policy constraints — not just what they do under a single run.
SoftBox focuses on reproducible execution, policy-driven environments, and kernel-visible telemetry to surface conditional, gated, and evasive behavior that traditional sandboxes often miss.
This repository is public but under active development.
Some components are experimental or incomplete by design.
Traditional dynamic analysis answers:
“What did this binary do in this environment?”
SoftBox is designed to answer a different question:
“Under what conditions does this binary choose different behaviors?”
Instead of mutating only inputs, SoftBox treats the execution environment and policy as first-class variables:
- syscall allow / deny / lie rules
- network behavior (blocked, sinkholed, fake success)
- filesystem visibility and write constraints
- execution and fork limits
- timing and entropy behavior
By running the same binary under controlled permutations of these conditions, SoftBox enables behavioral exploration rather than single-shot analysis.
At a high level, each SoftBox run looks like:
(sample, input, policy, mode) → execution → telemetry → artifacts → analysis
Key properties:
- Clean, reproducible execution from known baselines
- Strict run isolation and reset guarantees
- Structured telemetry suitable for post-run analysis
- Backend-agnostic policy representation
SoftBox currently supports (or is actively developing) multiple enforcement backends:
- Policy-driven syscall allow/deny enforcement
- Lightweight, fast iteration
- Useful for baseline behavior and controlled failure paths
- Kernel-level hooks for syscall and process telemetry
- Reduced anti-debug / anti-instrumentation footprint
- Policy enforcement without ptrace or userland DBI
- Intended for samples that evade or self-terminate under traditional instrumentation
Both modes are designed to consume the same policy definition, allowing experiments to remain backend-agnostic.
SoftBox is evolving toward a behavioral exploration engine with the following concepts:
Each run produces a compact behavioral summary derived from telemetry:
- syscall sequences / n-grams
- behavioral edges (e.g.
mmap → mprotect(RX),socket → connect) - process tree structure
- network endpoint summaries
- persistence and execution indicators
These footprints allow runs to be compared meaningfully without source-level CFGs.
Rather than treating runs independently, SoftBox is designed to build a per-sample behavioral corpus:
- which behaviors have been observed
- under which policies they emerge
- which behaviors are novel vs previously seen
This enables novelty-guided exploration and behavioral mapping over time.
- Controlled execution pipeline with strict run isolation
- Policy-driven enforcement (seccomp-based)
- VM-backed execution and launcher orchestration
- Structured telemetry emission (
events.ndjson) - Deterministic run directories and manifests
- Reproducibility guarantees (sample + input + policy)
- Kernel-mode visibility and enforcement backend
- Behavioral feature extraction
- Corpus ingestion and aggregation
- Automated exploration / mutation loop
- Higher-level behavioral classification
The project is intentionally being developed headless-first.
UI and visualization layers will follow once behavioral primitives are stable.
-
Reproducibility over convenience
If a run cannot be reproduced exactly, it is not considered valid. -
Policy as a first-class genome
Environments are structured, diffable, and replayable. -
Behavior over artifacts
Files and network IOCs matter, but conditional behavior matters more. -
Instrumentation without perturbation
Kernel visibility is favored where userland instrumentation alters behavior.
- Being a drop-in replacement for commercial sandboxes
- Real-time SOC alerting or IOC feeds
- Fully automated ML-driven classification
- Pretty dashboards before the data model is right
SoftBox is aimed at:
- malware analysts and reverse engineers
- security researchers studying evasive or conditional behavior
- systems engineers interested in execution isolation and policy enforcement
- anyone curious about why malware behaves differently, not just what it does
This project executes untrusted code.
Do not run SoftBox on systems you care about without proper isolation.
The author assumes no responsibility for misuse or unsafe deployment.
Active development.
Interfaces and internal formats may change.
Publishing early is intentional.