A defensive Windows anti-cheat research platform with a narrow, auditable trust boundary.
Demand-start kernel protection · Restricted service authority · Source-bound release metadata
Architecture · Security · Capabilities · Build · Contribute
OAC combines a Windows kernel driver, a restricted control service, and a standard-user launcher. It explores how much useful protection can be achieved without turning the driver into a second operating system: identity, signatures, policy, reporting, and blocking operations remain in user mode, while the kernel retains only the responsibilities that genuinely require kernel authority.
| Boundary | Design |
|---|---|
| Kernel | Narrow session authority, creation-time target binding, callbacks, bounded endpoint scans, snapshots, and retained alerts |
| Service | Signed authorization, endpoint trust admission, backend lease, suspended launch, target-job ownership, policy, and evidence delivery |
| Backend | Mutual-TLS admission, signed-policy delivery, durable lease/evidence/replay state, and authoritative game decisions |
| Release | Exact public/lab allowlists, deterministic metadata, SPDX SBOM, checksums, and private-symbol separation |
Important
OAC is an engineering reference, not a production-ready anti-cheat release. The repository does not provide production driver signing, a supported hardware and Windows compatibility matrix, a managed multi-region backend deployment, or game-specific adjudication policy. Never install the disposable test package on a workstation or production system.
flowchart LR
Player["Standard-user client"] -->|"status or launch"| Launcher["OAC Launcher"]
Launcher -->|"identity-checked local IPC"| Service["Restricted OAC service"]
Manifest["Signed game manifest"] -->|"exact build"| Service
Policy["Signed policy"] -->|"scope and rules"| Service
Backend["OAC backend"] -->|"mutual TLS, policy, lease"| Service
Service -->|"typed evidence"| Backend
Service -->|"one-use ticket"| Driver["Demand-start OAC driver"]
Driver -->|"bounded preflight and frozen module inventory"| Service
Service -->|"create suspended"| Target["Protected process tree"]
Driver -->|"bind at creation"| Target
Service -->|"assign before resume"| Job["Kill-on-close job"]
Job --> Target
Driver -->|"retained alerts and events"| Service
Game["Authoritative game server"] -->|"OAC game adapter"| Backend
Backend -->|"canonical movement events"| Detector["Reference behavior detector"]
Replay["Replay identity and offset"] --> Detector
Backend -.->|"endpoint risk"| Detector
Detector -->|"typed risk decision"| GamePolicy["Game policy and adjudication"]
A launch is deliberately serialized. The service authenticates the local client, locks and verifies the requested executable, checks its signed manifest and the active signed policy, arms a bounded driver ticket, creates the process suspended under the caller's token, confirms the exact process handle, assigns the process tree to a service-owned job, and only then resumes the first thread. Separately, the portable game interface lets an authoritative server bind movement observations to one build, backend session, match, player pseudonym, and replay before applying deterministic server-side rules.
- Narrow authority. Standard users never receive a privileged driver handle. Production driver access is bound to the restricted service identity, creator process object, exact file object, random session identifier, and monotonic generation.
- Early process binding. The driver matches a one-use ticket in the process-creation callback; it does not infer authority later from a reusable process identifier.
- Authenticated inputs. Canonical game manifests and policy records use detached signatures, protected signer pins, explicit scope and expiry, and persistent rollback state.
- Fail-closed endpoint admission. Before accepting launch requests, the service arms the production load gate, requires a complete current-state kernel scan, verifies every reported loaded driver against trust and vulnerable-driver policy, uploads the resulting evidence, and waits for acknowledgement.
- Deterministic lifetime. The target tree belongs to an unnamed kill-on-close job. Service failure, graceful revocation, handle cleanup, and a live-target tombstone have explicit outcomes.
- Bounded kernel work. Callbacks and processor sampling remain allocation-conscious and IRQL-appropriate. Filesystem access, certificate validation, policy evaluation, and reporting stay in the service.
- Evidence with provenance. High-priority alerts are retained until acknowledged, operational event gaps are counted, inventories use immutable paged snapshots, and policy decisions consume typed fields rather than display strings.
- Server-authoritative behavior. Canonical movement records carry monotonic server ticks, sequence, and replay identity. The reference detector rejects replay and combines explicit movement findings with, but does not replace them by, endpoint risk.
The current source includes:
- strict production negotiation, claim, status, launch-arm, cancel, confirmation, evidence-read, and snapshot messages;
- identity-checked launcher IPC and one serialized caller-token launch transaction;
- signed game-build authorization with exact executable hash and signer checks;
- production endpoint admission with explicit scan completeness, a frozen loaded-driver snapshot, embedded-or-catalog trust checks, exact vulnerable-driver hashes, conservative family policy, and an armed post-start load gate;
- runtime module authorization against the signed manifest, plus typed target findings for executable non-image and writable-executable memory, unbacked PE images, direct system-call stubs, thread start and instruction ownership, hardware debug registers, stack backing, and instrumentation callbacks;
- signed rule policy with deployment mode, build and channel scope, bounded validity, component compatibility, replay protection, explicit rollback authorization, and emergency revocation;
- a production WinHTTP transport with normal TLS validation, exact server pins, a strong client-certificate identity, bounded I/O, signed remote-policy delivery, and crash-safe local policy caching;
- a separate .NET 8 backend with role-separated mutual TLS, durable lease/replay/evidence state, certificate rotation, revocation, and restart recovery;
- a typed .NET game-server adapter and portable C event contract with canonical movement events, replay-safe state, a bounded movement and velocity invariant, and explainable durable decisions;
- creation-time target binding, exact-handle confirmation, pre-resume job assignment, and target process-tree containment;
- retained alerts, operational events, loss accounting, and frozen kernel-module snapshots;
- deterministic Observe, Enforce, and Strict policy evaluation with typed confidence and actions;
- a cancellation-aware service worker for bounded memory-region and thread sampling, typed observations, deduplication, explicit skipped-work metrics, and fail-closed queue exhaustion;
- a fail-closed disposable-VM installer, package validator, protocol suite, and Driver Verifier campaign; and
- an unsigned release-candidate pipeline with exact artifact boundaries, source/toolchain metadata, SPDX 2.3 inventory, hostile validation, and private-symbol separation.
The separate OAC Client is an elevated laboratory scanner. It covers process, module, driver, handle, memory, thread, stack, service, callback, hardware-identity, debugger, virtualization, and kernel-integrity observations. It is unavailable unless the disposable test environment explicitly enables diagnostic mode, and it cannot become the production controller.
See the capability reference for the complete matrix and the limitations of each observation.
OAC does not claim universal detection, a driver-load veto, or protection against a hostile kernel, DMA device, hypervisor, or compromised firmware. Work still required for a deployable product includes:
- managed database and multi-region deployment of the included single-node backend, per-device credential enrollment, service discovery, observability, backup automation, and operational SLOs;
- a game-engine-specific integration and adjudication policy beyond the included typed server adapter and reference movement invariant;
- manifest signer rotation and revocation metadata;
- a tuned module, middleware, overlay, child-process, and approved-JIT policy for a real game; the current manifest supports exact module hashes and an explicit trusted-Windows-module class;
- create-time job assignment and complete file-identity binding for the launch transaction;
- Microsoft driver certification, protected production signing, an authenticated release/update service, approved privacy operations, and a representative platform certification matrix.
The hardening plan describes those work packages. Roadmap text is a design target, not evidence that a feature already exists.
| Path | Responsibility |
|---|---|
OAC/ |
C17 WDM driver: sessions, callbacks, integrity checks, module/process scans, and telemetry |
OAC-Service/ |
Restricted controller, signed authorization, launch ownership, and scheduling |
OAC-backend/ |
.NET admission server, durable state, remote policy, tests, and game adapter |
OAC-Launcher/ |
Standard-user status and launch client |
OAC-Client/ |
Elevated laboratory scanner and diagnostic reports |
shared/ |
Wire contracts, game/server records, policy rules, strict validators, and common Windows support |
config/release-profile.json |
Release, driver, compatibility, SDK, and exact artifact contract |
tests/unit/ |
Driver-free layout, validation, transition, and policy regression tests |
tools/ |
Integration tests, packaging, installation, and repository checks |
tools/vm/ |
Networkless Hyper-V and Driver Verifier acceptance workflow |
| Guide | What it explains |
|---|---|
| Architecture | Components, trust boundaries, launch ownership, and scanner organization |
| Security model | Threat assumptions, enforced invariants, and deliberate limitations |
| Production protocol | Typed messages, session states, correlation, evidence, and snapshots |
| Game integration | Authoritative events, replay state, movement rules, and risk decisions |
| Capabilities | Production controls and the detailed laboratory-scanner matrix |
| Release engineering | Candidate format, metadata, SBOM, symbols, certification, signing, updates, and rotation |
| Support scope | Tested configurations, unsupported platforms, and admission criteria |
| Privacy | Data minimization, retention, access, deletion, and appeal requirements |
| Operations | Promotion, rollback, outage, key-compromise, and incident runbooks |
Exact campaign hashes, work-package bookkeeping, historical baselines, and maintainer decisions are kept separately in the development records.
You need Visual Studio 2022, the x64 C++ toolchain, Windows SDK/WDK 10.0.26100.0,
and the .NET 8 SDK.
msbuild .\OAC.sln /m /t:Rebuild `
/p:Configuration=Release /p:Platform=x64 `
/p:PreferredToolArchitecture=x64 /p:Inf2CatUseLocalTime=true
.\x64\Release\OAC-Protocol-Unit.exe
dotnet restore .\OAC-backend\tests\OAC.Backend.Tests.csproj --locked-mode
dotnet build .\OAC-backend\tests\OAC.Backend.Tests.csproj -c Release --no-restore
dotnet run --project .\OAC-backend\tests\OAC.Backend.Tests.csproj -c Release `
--no-build --no-restoreThe build intentionally produces an unsigned driver. Do not weaken a development workstation to load it and do not use a vulnerable-driver mapper. Use an authorized production signing pipeline, or follow the disposable-VM guide for isolated development testing.
The Release job also constructs an exact unsigned candidate. Its public, private-symbol, and lab boundaries are documented in release engineering; public CI never uploads the private symbols.
The full contributor build, analysis, and change-specific gates are documented in CONTRIBUTING.md.
Inside the isolated test deployment, a standard user can query status or request one exact executable launch:
OAC-Launcher.exe --status
OAC-Launcher.exe --launch "C:\Games\Example\Game.exe"The launch request accepts one absolute local executable path and no arguments. It requires an
authorized adjacent game manifest, a matching active policy, and a healthy backend lease. It is not
a general-purpose launcher. Disposable-VM tests use the deterministic mock transport; production
mode uses the mutually authenticated admission backend in OAC-backend/.
The current accepted implementation has passed clean Debug and Release builds, driver-free regression tests, PREfast, solution-wide static analysis, package and signing checks, and a networkless Windows 11 build 26100 campaign under standard Driver Verifier. The release profile, candidate reconstruction, SPDX schema, and hostile artifact mutations have separate validation. The managed backend additionally has Debug/Release restart, durability, replay, revocation, certificate-role, rotation, and real loopback mutual-TLS tests. Runtime claims are limited to the exact commit and environment recorded in the test matrix; they are not a general Windows, HVCI/VBS, hardware, or game-compatibility certification. The portable game/server contract is covered by the driver-free suite and does not extend that Windows runtime claim.
OAC is defensive software. The project does not accept vulnerable-driver loading, kernel hiding, Code Integrity or PatchGuard bypasses, exploit delivery, anti-forensics, or private loader hooks. Please report vulnerabilities privately through SECURITY.md.
Licensed under the Apache License 2.0.