Docs / ANALYSIS ENGINES
ANALYSIS ENGINES
Exploit Engine
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
The Exploit Engine takes Scanner's cryptographic findings one step further: instead of stopping at "this code uses a weak primitive", it asks the harder follow-up question - "can this weakness actually be exploited in this specific code?" - and produces evidence either way. It works on both source code and compiled binaries : you point it at a project that the Scanner has already analyzed (or directly at an executable, library, or container artifact), and it walks the same finding set with deeper, exploitation-focused analyzers. Status - V1 scope decision pending. The Exploit Engine is currently in a Beta / preview state. Whether it ships as part of Korthex V1 or arrives in V2 is still under discussion. Treat it as a forward-looking feature: the interfaces and outputs are described here so you can plan around it, but availability, edition placement, and feature completeness will be finalized closer to launch.
What It's For
The Scanner answers "where is cryptography used and which uses look weak?" . The Exploit Engine answers the next question on the chain: "of those weak uses, which are realistically attackable in this codebase, and what would an attack look like?" Filter noise from real risk. A finding may be theoretically weak (e.g. AES-ECB) but only invoked in dead code, behind a build flag, or with values that an attacker cannot influence. The Exploit Engine separates these from vulnerabilities that an adversary can actually reach. Demonstrate impact. For findings that are exploitable, the engine produces a minimal, deterministic proof-of-concept description showing the attack steps and the kind of damage (key recovery, authentication bypass, data leak, denial of service). Prioritize remediation. Each target gets an Exploit Likelihood Score so engineering teams know which findings to fix this sprint and which can wait for the migration cycle. Audit your binaries. Works on shipped artifacts (PE / ELF executables and libraries) even when source is unavailable - useful for third-party vendor assessments and supply-chain reviews.
How It Works
The engine runs a four-stage pipeline. Each stage produces a structured artifact that you can consume independently or chain into the next stage. Each stage can be re-run independently: useful for partial replay (re-rendering a report from a saved PoC set without re-running analysis) or for feeding curated attack surfaces from an upstream tool.
| Stage | Input | Output | What Happens |
|---|---|---|---|
| Recon | Scanner findings | Attack-surface map | Crypto usages are turned into typed targets, classified against the algorithm baseline, and scored by exploit likelihood. |
| Analysis | Attack-surface map + binary | Exploit findings | Each target is examined by specialized analyzers (see below). Binaries are loaded into a CPU emulator so attacks can be evaluated without running them on your machine. |
| Attack | Exploit findings | Proof-of-concept set | For confirmed weaknesses, the engine synthesizes the minimal sequence of steps that demonstrate the issue, then validates the PoC by replaying it in emulation. |
| Report | Proof-of-concept set | JSON / SARIF document | Final report shaped for human review and CI/CD ingestion. Sensitive payload bytes are scrubbed by an output redactor before emission. |
Analyzer Categories
Analyzers are the individual detectors that look for a specific class of cryptographic weakness. The roadmap covers the following categories, with the first three available in the current preview and the remainder rolling out as the engine matures:
| Category | Looks For | Status |
|---|---|---|
| ECB Mode Detector | Block ciphers (AES, DES, Camellia, ...) used in ECB mode. Verifies the call path actually reaches the cipher. | Preview-ready |
| Hardcoded Secrets | Literal keys, IVs, salts, or HMAC secrets baked into compiled output. Combines entropy heuristics with data-segment scanning. | Preview-ready |
| Weak RNG Analyzer | Non-cryptographic random sources (e.g. rand/srand, time-based seeds) feeding into key, IV, or nonce material. | Preview-ready |
| Padding Oracle Analyzer | CBC-mode constructions where padding errors are observable to an attacker. | Roadmap |
| Key / Nonce Reuse Detector | Same key/nonce pair used across multiple encryptions of attacker-influenced data. | Roadmap |
| Timing Side-Channel Analyzer | Comparison or table-lookup patterns whose runtime leaks secret-dependent information. | Roadmap |
| TLS Configuration Analyzer | Server / client TLS setups that allow downgrade, weak suites, or insecure renegotiation. | Roadmap |
| Reverse-Engineering Risk | Binaries whose key-material handling is easy to recover via static analysis. | Roadmap |
| Deprecated Algorithm Mapper | Use of primitives officially deprecated by NIST / BSI baselines, with migration targets. | Roadmap |
Exploit Likelihood Score (ELS)
Every target on the attack surface is graded on a 0 - 10 scale that combines five independent factors: The ELS lets you sort the attack-surface map by impact and triage findings at a glance - the highest-scoring targets are the ones an attacker is most likely to chase first.
| Factor | Captures |
|---|---|
| Algorithm strength | Where this primitive sits on the baseline ladder (recommended → acceptable → deprecated → disallowed). |
| Key length | Effective key bits vs. the minimum demanded by the baseline. |
| Mode of operation | Mode-level weaknesses (ECB, CBC without MAC, IV reuse with CTR, ...). |
| Key / IV source | Whether secret material is hardcoded, RNG-derived, configuration-bound, or properly random. |
| Context | How exposed the call site is (network-facing endpoint vs. private utility, attacker-controllable inputs). |
Output & CI/CD
Exploit reports are emitted as JSON or SARIF 2.1.0 . SARIF output drops directly into GitHub Code Scanning, Azure DevOps, and any other SARIF-aware platform - the same pipeline you use for Scanner findings. # Run Exploit on the latest Scanner report and emit SARIF korthex exploit run latest --format sarif --output exploit.sarif Every finding is labeled by how it was established. A finding confirmed by replaying it in emulation is marked as verified and carries a CVSS v3.1 score; a finding raised by static or heuristic analysis that was not reproduced carries an explicit UNPROVEN marker. The report stays honest about the difference between a demonstrated weakness and a candidate that still needs review. The output redactor enforces a strict prohibited-fields policy: source code, executable bytes, and shellcode never appear in emitted reports, even if upstream data carried them. This makes Exploit output safe to attach to tickets, share with auditors, or upload to managed scanning platforms.
Ownership Enforcement
Offensive analysis is only legitimate against code you own or are explicitly authorized to test. Korthex does not leave that to policy alone: before the Exploit Engine analyzes anything, it verifies that the target is yours to test, and declines any target that is not. That verification happens before analysis begins, and a valid license by itself does not satisfy it. Ownership is a separate precondition. An Enterprise license lets you enable the engine; it does not authorize any particular target. Each target is checked on its own before the engine will touch it. Refusal is clean and explicit. A target that does not clear the check is declined with a clear message, never a crash and never a silent skip, and the decision is recorded. To keep the guard effective, Korthex does not publish how ownership is verified, nor the exact conditions under which a target or the runtime environment is accepted or declined. A valid license alone will not let you point the Exploit Engine at someone else's binary or a scraped repository, and activation itself can be declined in environments Korthex does not support for offensive use.
Activation & Safety
Ownership enforcement governs what you may analyze; the controls here govern how the engine runs. The Exploit Engine performs offensive analysis, so it is gated by default even though it works entirely in emulation. Activating it requires an explicit, license-tier-appropriate opt-in plus acknowledgement of the Terms of Service for offensive use. The CLI and Dashboard surface the toggle clearly, and the engine refuses every call until consent has been recorded. Sandboxed by design. Binaries are loaded into a CPU emulator; they are never executed natively on your machine. Proof-of-concept execution runs in an isolated sandbox with no network access. Auto-disarm. The offensive feature gate closes itself again after a period of inactivity and at session end, so the engine is never left armed longer than it is actively in use. Cooperative cancel. Long-running analyses can be cancelled at any phase boundary; resource budgets (time, memory) are configurable and enforced. Telemetry and federated learning are off by default. Both are opt-in. When telemetry is enabled, only non-sensitive structural events leave the machine; prohibited fields are stripped at the sink. The Exploit Engine is intended for assessing systems you own or have explicit authorization to analyze. Ownership enforcement blocks unowned targets technically, but it does not replace your legal responsibility: authorized use is governed by the Korthex Terms of Service.