Deep Capture compatibility

Published baseline: v0.11.1.

Rust integrations can drive the same behavior through fragcap::deep_capture. The public API supports side-effect-free preflight, exact-plan authorization, checked lifecycle methods, narrow proxy, trust, launch, Capture, and storage adapters, typed events, and one authoritative terminal report. Controlled adapters require no capture driver, elevation, game account, remote service, or trust-store change.

Deep Capture does not promise that every encrypted flow becomes readable. It does not bypass certificate pinning, downgrade TLS, extract keys from a target process, or silently change system-wide proxy settings. Packet truth remains available through Capture even when application inspection is unavailable.

See Output formats and session bundles for the current native artifact authority, sensitivity, omission, correlation, retention, and cleanup contract. The native bundle includes versioned application and cleanup streams, packet-to-application correlation, a bounded HAR projection, and a manifest that declares finalization, completeness, loss, sensitivity, and omissions for every expected artifact.

Traffic support

All supported routes preserve IPv4 or IPv6 family from authorization through listener ownership, routing, lifecycle, artifacts, and cleanup. The default is IPv4; IPv6 selection is explicit and never uses a wildcard listener.

In compatibility facts, full means the proxy observed the required supported semantics for that exact target, launch case, route, address family, protocol, backend, and product version. It does not mean every body byte, WebSocket frame, or custom payload was retained. Bounded retention and explicit omission or truncation remain authoritative. A TLS key log is an analyzer aid produced by the proxy side of the session. It is not a key extracted from the selected process.

v0.11.0 direct route

The v0.11.1 release includes fragcap calibrate <target> --routing-strategy child-environment-direct-socket and fragcap deep-capture <target> --launch --direct-route. The composite plan keeps child-scoped proxy environment settings and adds one signed, exact final-client direct TCP or supported UDP route. It requires Administrator and the packaged WinDivert 2.2.2-A x64 component.

Calibration stores the composite route identity child-environment+direct-socket-v1 separately from earlier child-environment-v1 facts. A positive direct-route fact needs a correlated original final-client flow, a native proxy observation, and independently retained packet evidence. Launcher-only traffic, proxy traffic from the environment route, missing owner proof, and an old environment-only positive fact do not qualify the composite route.

The route result is separate from inspection: selected means the exact original flow reached the proxy; inspected means supported application semantics were observed; opaque means routing succeeded without readable semantics; bypassed means the packet was reinjected without selected ownership; refused names a routing, trust, protocol, or resource boundary; packet-only is Capture evidence without a qualifying proxy observation. Candidate queue and worker failures retain explicit loss and cleanup outcomes. WinDivert queue loss before packet delivery is not measurable by the route counters.

Local target matrix

Compatibility depends on the launch path and local evidence. fragcap therefore does not publish a guessed title list. Inspect the facts stored for one selected target instead:

fragcap targets show sample-target

With evidence, the detail view adds one line per stored fact:

compatibility proxy-routing:     reached-client | launch=steam-protocol-cold | source=observed-run | freshness=current
compatibility inspectability:    metadata-only | source=stale-observation | freshness=stale

Without evidence, it says:

compatibility:    unknown (no stored evidence)

Repeated or conflicting rows remain visible. fragcap does not collapse them into a single compatible or incompatible verdict because two launch cases, target versions, or proxy backends can produce different results.

Evidence and freshness

targets show is read-only. It does not launch software, start a proxy, change certificate trust, contact a catalog, or refresh facts. A later explicit and authorized Deep Capture measurement can add newer evidence. Existing launch-specific rows remain available as context rather than being silently rewritten.

Calibrating an unknown target

Start with the guided front door:

fragcap calibrate sample-target
fragcap calibrate --id 42 --protocol https --inspect-scope auto

Inspection scope is part of the exact case. In current source, auto resolves before effects to launch-chain inspection for Steam, publisher, and direct topology. game explicitly selects exact-game inspection with blind middleware relay. Packet evidence retains the exact session-created chain under either choice. Version 1 and differently scoped facts remain visible but cannot qualify the current version 2 case.

Stored resolution takes precedence. On a clean miss, an exact installed Steam application identifier or case-insensitive display name can produce a separately confirmed registration plan. For a Steam target without an authored client, appinfo supplies a launch hint only. Interactive setup can separately confirm a cold Steam launch and observe owned descendants with operating-system socket rows. One complete observed socket owner can be proposed under an exact client-authoring plan; this does not prove packet traffic or proxy reachability. No owner, multiple owners, incomplete observation, or a decline changes no target row. --client-executable sample.exe is an explicitly labeled manual declaration when observation is unavailable. Setup ends after the target change; close the title and Steam normally before rerunning calibration for reachability. A content-derived --candidate identity selects one current discovery candidate, never a list position. Registration, setup, and each later session require separate fresh authorization; a choice is not consent to traffic inspection.

The workflow proposes reachability first when applicable routing evidence is missing. Fresh eligible final-client observations can propose concrete protocols, but requested --protocol values are only measurement intent. Each workflow runs reachability at most once and each concrete protocol at most once, with at most fourteen durable attempt ordinals. A failure, limitation, decline, partial result, interruption, target change, or repeated case checkpoints coverage and stops later effects instead of pretending success.

In v0.10.9, an early packet withheld by Capture's selected scope does not automatically invalidate a later, separate proxy connection. The later connection still needs retained packet observations in its exact time window with one proven final-client owner. A withheld packet inside that window remains a refusal (packet-scope-withheld); saturated per-flow history reports packet-history-bound-exceeded, and an acquisition-buffer loss reports capture-buffer-history-incomplete. An unknown omission or exhausted omission history also refuses a positive match. These reasons explain missing evidence; they are not a claim that the target accepted TLS or that the route propagated. v0.10.8 has the earlier untimed omission behavior.

Resume from the same effective local store using the workflow identity printed by the command:

fragcap calibrate --resume 17 --local-db C:\Users\you\local.db
fragcap calibrate --resume 17 --pause-for login --local-db C:\Users\you\local.db

The workflow stores an immutable target snapshot and exact-case intent. Resume rebuilds process inventory, fact applicability, proposal, recovery, bundle, plan, and confirmation authority; it never reuses an old plan or response. An in-flight record first becomes an effect-free interruption pause. Login, EULA, update, anti-cheat, gameplay, shutdown, and interruption pauses record operator work, not compatibility proof. Advanced fresh workflows can assert the inferred cold launch case, choose IPv4 or IPv6, and select child-environment routing or the explicit composite direct-socket route; remaining routing strategies refuse before effects. Resume cannot change those dimensions or the candidate.

If a delegated session fails, the terminal diagnosis names the earliest known stage from retained launch, process, route, fact, and cleanup evidence. An artifact marked written can contain zero retained target packets. A paused failed workflow retains its attempt history, so --resume does not automatically retry that failed exact case. A fresh workflow may include --retry-game-scope to authorize one new exact-game successor after a failed launch-chain attempt, with a separate attempt bundle and fresh authority. --fallback-capture may retain eligible packet-only evidence under its actual window without appending a positive inspection fact. Neither authority can be added on resume. A zero-observation attempt may append a launch-case fact while appending no proxy-routing fact; inspect the exact fact-write report.

Ordinary eligibility uses the latest exact applicable routing row for target/version, launch case, route, loopback family, selected measurement, native backend/version, and fragcap version. A historical current display label, imported fact, protocol fact, launcher observation, or another workflow cannot substitute for that decision. See the CLI reference for full options.

Reading a calibration result

The S168 contract shipped in v0.10.6 presents authorization, observation, captured evidence, resource cleanup, and one final calibration verdict as separate blocks. The complete canonical plan and exact identifier still govern authorization. Human field anchors use the widest actual label plus four spaces; redirected output is plain, quiet suppresses ordinary guided progress and its final human verdict, silent suppresses terminal evidence, and JSON carries additive calibration.verdict decisions instead of prose. Required authorization and actionable cleanup notices retain their established visibility.

The final verdict separates the attempted case from current applicable stored readiness. Its case identity includes target, launch, route, address family, native backend/version, fragcap version, target version when available, and protocol. The greatest durable row ID for each exact applicable measurement key supplies current readiness; older differing values remain history. A later exact negative measurement supersedes an earlier positive one, and a later exact positive measurement supersedes an earlier negative one. A stale or unrelated attempt does not displace an applicable current measurement. Contradictory values at the same greatest durable ID, or absent durable chronology, cannot establish readiness. A satisfied stored routing prerequisite still requires fresh launch preflight, recovery, and authorization. Remaining protocols are explicit. Resume preserves workflow intent and attempt history and obtains a new plan; one supported next command is printed with that purpose.

Connection endings and application exchanges count different populations. For example, a controlled session can report six failed connections, with five protocol failures and one idle timeout, while seven HTTP exchanges completed successfully. The timeout does not erase those exchanges. Separate fields show accepted/completed/failed/forced/live connections, retained failure categories, exchange/stream totals, bounded detail loss, record ownership, and unavailable correlation. Records observed during the observation window and later owner release remain distinguishable. Later records are retained but cannot satisfy the earlier calibration case.

v0.10.9 takes final proxy counters after cleanup and application finalization, including when the first stop attempt timed out. Earlier unavailable counters stay unavailable until an actual runtime report establishes them; a later count does not erase the timeout. The final calibration diagnosis uses these last observed counts and keeps the earliest known causal failure. v0.10.8 can report a premature zero after a stop timeout; inspect its retained application and cleanup records separately.

A finished session can have partial process evidence and readable written artifacts without proving selected-client reachability. The terminal evidence block reports manifest and process-trace completeness and exact available limitation counts independently from session finalization, writes, recipient-context access, fact writes, and cleanup. It prints the bundle root once and relative artifact names, and gives an omission reason instead of claiming an unrequested file exists. The S170 correction published in v0.10.6 verifies ordinary recipient access after writer and lifecycle reconciliation and withholds accessible analyzer-opening guidance when that verification fails. Published v0.10.6 includes this correction.

Ordinary desktop access

Same-account administrative capture retains the intended user's exact SID and ordinary access context. Private output grants that recipient, any distinct producer and SYSTEM explicitly, covering inherited files, atomic publication and independently protected sidecars. Administrator-group ownership and a successful elevated read do not establish ordinary access. Readable evidence can still be partial or fail to prove final-client reachability.

Elevation under different credentials requires an explicit --output-recipient <SID> and exact --bundle <PATH>. The waiting command emits a quoted bundle access-authorize helper command for the intended ordinary terminal. Run that exact helper within sixty seconds, then review the full session authorization plan. An unknown recipient, elevated helper, changed request or mismatched destination refuses before session output or effects. No arbitrary desktop account is guessed.

The S173 correction published in v0.10.7 establishes the same-account recipient automatically from its proven ordinary desktop shell context when the producer is elevated. No self-SID argument, explicit output destination or second terminal is required for this default. The exact account and Windows session must match, the retained token must be ordinary, and final verification follows writer reconciliation. A matching SID or successful elevated read cannot establish ordinary access. Acquisition failures identify their operation stage.

v0.10.7 (S173) retires the historical permission inspection/repair workflow shipped in v0.10.6. For inaccessible historical output, use normal Windows permission administration, then verify reads from the intended ordinary account. fragcap does not promise automatic historical repair. Different-account output keeps its explicit authenticated helper; collection, sensitive cleanup and Doctor recovery/retention keep their separate contracts.

Session retention and collection

The S171 correction published in v0.10.6 declares finite retention for newly generated Deep Capture and calibration history: 30 days from terminal manifest publication, 20 completed managed sessions and 2 GiB of eligible logical contents. Oldest eligible contents are collected first after an authorized effectful session finishes, excluding its returned bundle. The exact authorization and terminal presentation show the selected policy. Choose --retain-bundle to save generated evidence until explicit cleanup; explicit --bundle destinations and their guided attempt siblings are always retained. Historical bundles keep their previous promise. This retention policy ships in v0.10.6.

Use bundle collect to preview and authorize existing backlog reclamation. Include retained evidence only by selecting --include-retained; select custom output with --bundle. Collection validates whole-session ownership, inactive generation leases, closed manifest/journal provenance, complete recognized files and every recovery obligation. Active, malformed, unknown, unsupported, unreadable, reparse and replaced populations remain unresolved with their authority preserved. Collection never performs trust recovery.

New ownership leases are visible across Windows desktop sessions. Historical session-local ownership remains unresolved when the original process may still exist and its generation cannot be conclusively checked. The refusal preserves that bundle and reports the missing authority.

Routine collection preserves empty session container directories. Only separately explicit --purge-empty can remove proven eligible exact empty containers. Durable retirement records outside the removed contents support interrupted retries and recognize collected emptiness in read-only Doctor. Results count actual removed logical bytes, not presumed physical disk savings. Exact destructive collection requires Windows; portable inspection does not claim portable deletion. Owner AppData and real trust state are not mutated by controlled acceptance tests.

Byte and file totals describe collected bundle contents. Owner-registry metadata retirement is reported separately; external retirement metadata remains available for exact retry and empty-container recognition.

Controlled Windows tests use synthetic bundles, actual ordinary reads and explicitly labeled group-denied or unrelated-access equivalents. They compare complete fixture bytes, last-write times and sibling permissions and prove truthful denied/partial outcomes. No real game, owner-sensitive bundle, actual elevated Administrators-owned fixture or second human account was exercised. Universal field behavior and a separate release are not claimed.

Current source S169 corrects required loopback acquisition, exact listener filter continuity and stage-bound TCP endpoint orientation under #468. When accepted proxy traffic still lacks eligible final-client correlation, the result remains inconclusive. Closed reason counts distinguish absent flows, withheld or bounded history, acquisition-buffer gaps, outside-window packets and unresolved/conflicting ownership over retained observation-window records. The supported next action is fragcap doctor to inspect Npcap loopback readiness, followed by retained evidence inspection; this does not prove ownership or authorize a new measurement. Gameplay retry is not a known remedy. The route-owner action remains visible with its finite normal-shutdown deadline while the proxy is active. Successful cleanup establishes resource release only. Controlled real socket endpoints and synthesized packet frames prove the source contracts; no live driver or real-game compatibility is claimed.

Observed case evidence

Connections accepted:          6
Connections completed:         0
Connections failed:            6
HTTP/1 exchanges completed:    7
Cause protocol:                5
Cause timeout:                 1

Calibration verdict

Attempted case:                  inconclusive
Attempt reason:                  final-client-correlation-missing
Current applicable readiness:    incomplete
Next action:                     fragcap doctor (inspect loopback acquisition readiness)

This abbreviated synthetic example retains the four-space gap after the longest actual label in each block. Full reports additionally expose the exact case, independent artifact/process/cleanup fields, remaining work, and reason codes.

Advanced single-phase measurements

Compatibility calibration is the supported, explicit path from unknown local evidence toward ordinary Deep Capture eligibility. It keeps the ordinary safety gate intact and measures one declared launch case in two separate runs.

First close the selected target and, for a Steam launch, close Steam. Calibration requires a cold target and cannot use the ordinary Deep Capture warm close-and-retry option. Managed direct, cold Steam platform, and declared publisher-launcher chains are supported. Then measure scoped proxy reachability without changing certificate trust. This example uses the Steam launch case:

fragcap deep-capture sample-target --launch --inspect-scope game --calibrate reachability --calibration-protocol routing --launch-case steam-protocol-cold

For an eligible stored direct target, use --launch-case direct-exe-cold instead. Warm Steam and direct-executable targets are refused before side effects.

fragcap displays the exact target and launch authority, phase, loopback and routing policy, process-local CA identity when trust is needed, bundle and sensitive artifacts, finite deadlines, possible fact writes, cleanup obligations, refusal boundaries, and versioned plan identifier before asking once for confirmation. A shorter --wait or --duration becomes the displayed calibration bound; longer values are capped at the calibration maximum. Shutdown and cleanup enforce the displayed bounds too. JSON and prompt-free automation require --authorize-stdin; the caller reads the plan event and returns its exact identifier plus one LF in the same process.

Review the new rows with fragcap targets show sample-target. If current evidence for the same launch case says proxy-routing = reached-client, a separate TLS phase can measure CA acceptance and inspectability:

fragcap deep-capture sample-target --launch --inspect-scope game --calibrate tls --calibration-protocol https --launch-case steam-protocol-cold

Windows may show a separate Security Warning when it adds this session's CA to the current-user Trusted Root store. Compare the warning's SHA-1 thumbprint with certificate_thumbprint_sha1 in fragcap's displayed plan before deciding. The command waits while that Windows prompt is open. Declining the warning prevents the TLS measurement; after approval, fragcap must remove only the exact trust entry added by this session and report any unresolved cleanup.

Use the same exact cold launch case in both phases.

Routing and environment propagation remain separate facts. Reaching the final client does not prove how the launcher propagated proxy configuration, and fragcap records proxy-propagation = confirmed only when a separate non-invasive observation supports it. CA acceptance requires full HTTPS semantics correlated to the final client, so launcher traffic cannot establish the target's trust behavior. Silence remains inconclusive. A phase outcome such as proxy not reached, metadata only, or unsupported protocol is recorded in the local bundle and is not converted into an aggregate compatible or incompatible target verdict.

Publishing compatibility evidence

Public documentation and committed fixtures use placeholders such as sample-target and sample.exe. Do not publish local title names, account identifiers, access tokens, filesystem paths, private endpoints, host identifiers, or unreviewed free-form notes collected during compatibility work.