Docs / ANALYSIS ENGINES
ANALYSIS ENGINES
Runtime Agent
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
The Runtime Agent watches a running process and observes the cryptography it actually uses - not what the source code says , but what the binary calls at runtime. Catches dynamic algorithm choice (config-driven), third-party library decisions (chosen at link time), unzeroed key buffers, deprecated library versions, and live TLS handshake characteristics.
Modes
Auto-attach to child processes always runs in passive mode (to avoid disrupting short-lived children). Top-level mode is your choice; descendant processes downgrade automatically.
| Mode | Mechanism | Use case |
|---|---|---|
| Passive | No injection. Observes OS-level signals only: Windows ETW for CNG/Schannel events, loaded-module enumeration, TCP connection table. | Production / shared environments. Works on any process the calling user owns. |
| Active | Injects an instrumentation agent for per-call detail. | Pre-production / staging. Highest fidelity. |
| Hybrid | Both at once. | Audit-level visibility when you control the target binary. |
What It Captures
| Stream | Examples |
|---|---|
| Findings | MD5 / MD4 / RC4 / DES / RC2 hard-flagged on first use. Unzeroed key buffers. Deprecated library versions detected. |
| API call log | Every BCrypt / Schannel call observed during the session. |
| Memory snapshots | Periodic key-material checks; flags secrets persisting longer than expected. |
| Network connections | TLS-port vs plaintext-port classification. |
| TLS deep inspection | Every ~10 seconds, opens its own handshake to verify cipher suite / cert chain on each established connection. |
Using the Agent
The Runtime Agent is driven from the Desktop app : open Runtime , pick the target from the process list, and attach. The screen handles the elevation pre-flight, streams the live event view while the session runs, and writes the session out when you detach. Attaching starts a privileged operation, so the screen is gated on the findings.read permission. What you configure before attaching is which streams to record - crypto API calls, network connections, loaded-module enumeration, memory analysis, and key-material tracking. The first three are on by default; memory analysis and key-material tracking are off until you turn them on. The CLI cannot drive a session yet. The runtime verb exists and declares --pid and --path , but it stops after the license check and reports that the engine integration is still pending. It does not attach, does not record, and does not write a session file - treat it as reserved surface, not as a scriptable entry point. # Declared today - refuses with "integration pending", writes nothing korthex runtime --pid 14782 korthex runtime --path ./my-service
Output
Sessions are stored as .krxr (encrypted runtime reports). The session contains both the event stream and a periodic posture snapshot so the file is independently readable without needing access to the original target. The Runtime Agent integrates with Dataflow Engine: a recorded session produces a .kxg.runtime file that can be merged into the static-analysis dataflow graph to show "what's documented to happen" alongside "what actually happened".