iocx-dev/iocxAn extensible, deterministic static‑analysis engine that extracts high‑signal IOCs from PE binaries and text, built for SOC automation and modern threat‑analysis pipelines.
Static IOC extraction from a PE file using the IOCX CLI
This is the original IOCX engine for deterministic static IOC extraction and PE analysis. Any other repositories using the name "iocx" are not affiliated with this project.
Official links:
Modern malware is adversarial by default — malformed, evasive, and engineered to break naive extractors.
IOCX is built for environments where correctness and determinism actually matter.
IOCX is the official static IOC extraction engine — a deterministic, binary‑aware system built for DFIR, SOC automation, CI/CD security, and large‑scale threat‑intel pipelines.
Unlike regex‑only extractors or sandbox‑dependent tools, IOCX performs:
It is a core component of the MalX Labs ecosystem for scalable, modern threat analysis.
echo "http://malicious.example" | iocx -
Or scan a PE file safely:
iocx suspicious.exe -a deep
Security teams face three persistent problems:
IOCX solves this with a deterministic, static‑only engine designed for automation, safety, and scale.
IOCX is intentionally not:
It never executes untrusted code. It never performs dynamic analysis. It is static‑only by design — for safety, determinism, and CI/CD compatibility.
IOCX is engineered for the realities of modern malware, not the assumptions of legacy tools.
Stable, reproducible output — no randomness, no volatility.
Execution is unsafe. Static analysis is predictable, scalable, and CI‑friendly.
Malformed PEs, corrupted RVAs, hostile strings — IOCX treats them as normal input.
Downstream systems should never break on upgrade.
150–300 MB/s on raw text. 6–15 MB/s on typical PEs. Predictable even under worst‑case adversarial load.
These commitments are derived from a published research methodology for PE structural analysis — deterministic fixture construction, single-anomaly discipline, and Windows loader behaviour as the correctness oracle. See docs/methodology.md for the full methodology, and paax.dev for the broader adversarial-PE taxonomy and commercial fixture suite.
| Capability | IOCX | Typical IOC Extractors | Sandbox / Dynamic Tools |
|---|---|---|---|
| Safety | Zero‑execution, static‑only | Regex‑only, no binary safety | Executes untrusted code (high‑risk) |
| Determinism | Fully deterministic output | Non‑deterministic under noise | Non‑deterministic by design |
| Binary Awareness | Full PE parsing, heuristics | No binary support | Yes, but unsafe + slow |
| Adversarial Resilience | Tested against malformed PEs, hostile strings | Easily bypassed | Often crashes or misclassifies |
| Performance | 150–300 MB/s (text), 6–15 MB/s (PE) | Highly variable | Extremely slow |
| CI/CD Friendly | Yes — safe, deterministic, fast | Partial | No — unsafe for pipelines |
| Schema Stability | Guaranteed | Rare | None |
In short: IOCX is built for real adversarial reality, not idealized input.
150–300 MB/s sustained throughput Fast path — no PE parsing.
| Detector | 1 MB Time | Throughput |
|---|---|---|
| Crypto | 0.0037 s | ~270 MB/s |
| Filepaths | 0.0041 s | ~250 MB/s |
| IP | 0.0065 s | ~156 MB/s |
| Domains | 0.0035 s | ~300 MB/s |
IMPORT_* reason codes).version_info now parsed and surfaced at every analysis level (not just -a full), via a new bounded public projection.--version output, clearer --help text, reorganised argument groups..pdata) directory; 14 new reason codes; 15 validators total.