Document what an anti-cheat kernel driver monitors, collects and exposes, with evidence you can check, for software you are authorized to audit. Start with a free assessment.
Anti-cheat driver auditing is an authorized review of what an anti-cheat kernel driver does on a Windows machine: which system events it watches, which identifiers and data it reads, what other software can ask it to do and where it conflicts with other drivers. Devirt documents each behavior with the evidence behind it, for studios, anti-cheat developers, security researchers and privacy or compliance reviewers who own the driver or are authorized to analyze it.
Family recognition is an intake decision, not a guarantee for every build. Custom behavior and multiple protection layers can require a separate assessment.
A binary does not need virtualization to be in scope. Devirt can reverse ordinary compiled programs, map their behavior and interfaces, and surface risk indicators for your authorized review.
The delivery pairs readable output with a full ledger for the agreed scope. Proven, runtime-dependent, unresolved, and permanently bounded units remain distinguishable, including units that were never virtualized.
See how the checks workA kernel-level anti-cheat driver runs in kernel mode, the processor privilege level Windows itself uses, often called Ring 0, while games and ordinary programs run in user mode, Ring 3. Microsoft documents the difference: each user-mode application runs in isolation, but all kernel-mode code shares a single address space, so a kernel-mode driver is not isolated from other drivers or from the operating system.
From kernel mode, an anti-cheat driver can ask Windows to notify it when processes and threads start, when executable images load and when one program opens a handle to another, and it can inspect the memory and code of the game it protects. Which of these a particular driver uses, and when, depends on its code, not on the category it belongs to.
That position is why an anti-cheat driver matters beyond the game. Microsoft notes that a kernel-mode driver crash takes down the entire operating system, and in August 2022 Trend Micro documented a ransomware actor abusing a code-signed anti-cheat driver to stop endpoint protection processes. An audit records what one driver does, whatever your view of kernel-level anti-cheat.
Devirt audits anti-cheat drivers for teams that own the driver or hold its owner's authorization to analyze it:
An anti-cheat driver audit turns the driver into a written account of its behavior. If the driver's code is obfuscated or virtualized to resist analysis, the free assessment first checks whether Devirt's deobfuscation and devirtualization paths cover that protection, so the audit reads the logic the driver runs rather than the protection around it.
Devirt documents six areas:
An anti-cheat driver audit is delivered in Devirt's full reverse engineering report format: architecture, behavior, identity surfaces and an executive summary. The written offer can add the recovered code as an IDA database, annotated pseudocode, LLVM IR or API JSON, the other four of Devirt's five output formats.
Every delivery carries its coverage ledger, a proof summary and the remaining limits, so a studio, a researcher or a compliance reviewer can check each conclusion against its evidence.
Eligible operations receive formal checks. Counterexamples and timeouts stay visible and are not counted as proof, so the report never presents unproven behavior as proven.
Devirt's coverage ledger records every unit of the audited driver in one of four states, so a reviewer can tell proven behavior from behavior that still depends on the machine it runs on:
Devirt audits anti-cheat drivers only for their owners and for reviewers the owner has authorized. You must own the driver or be authorized to analyze it, and if a vendor licenses the driver to you, the authorization has to cover it. Devirt can decline a job, or ask for the scope or the authorization to be clarified, before any analysis starts.
Devirt never helps build cheats, bypass or disable anti-cheat, evade bans or hide software from detection. It declines any request with that aim, including requests described as research.
One recovered program. Different ways to work with it. Inspect a teaching example, switch formats, and follow the link back to its evidence.
; Authored teaching VM, not vendor bytecode
00 LOAD32 r0, input.size
01 PUSH r0
02 PUSH 0x10
03 UGE
04 STORE p0
05 LOAD32 r1, input.magic
06 PUSH r1
07 PUSH 0x44565254
08 EQ
09 LOAD p0
10 AND
11 RET
#include <stdbool.h>
#include <stdint.h>
bool validate_record(uint32_t size, uint32_t magic) {
const uint32_t header_size = 16u;
const uint32_t expected_magic = 0x44565254u;
if (size < header_size) {
return false;
}
return magic == expected_magic;
}
Drag the divider to reveal the difference. Or choose a view above. Keyboard: arrow keys, Home and End.
Check the declared size. Check the type marker. Accept only when both checks pass.
Readable code explains the behavior. The ledger explains how far you can rely on it.
Original teaching material, not customer output. The IDA view illustrates a database's contents; it is not a downloadable .i64. No measured proof or service benchmark is claimed by these examples.
Every anti-cheat driver audit starts with the free assessment: Devirt reviews the driver and the scope you are authorized for, then sends a written offer, and nothing is charged unless you accept it.
Start a free assessmentKernel-level anti-cheat is a trade-off: its driver runs with the highest privilege on the machine, so a flaw or an overreach affects the whole system. A peer-reviewed study at the ARES 2024 conference examined four widespread kernel-level anti-cheat systems and found rootkit-like behavior in two of them. Whether a particular anti-cheat is acceptable depends on what its driver does, and an audit answers that with evidence.
No. Devirt does not build cheats or help anyone bypass or disable anti-cheat, evade bans or hide software from detection, and it turns those requests down. Its anti-cheat work is authorized auditing of what a driver does, and nothing else.
Yes, when the authorization covers the driver. A studio that licenses anti-cheat from a vendor should confirm that its agreement, or the vendor's written permission, allows the analysis, and Devirt may ask to see the scope and the authorization before it starts.
Devirt reports it. Units that cannot be proven stay in the ledger as runtime-dependent, unresolved or permanently bounded; they are not hidden. The free assessment estimates coverage before any paid work, and any revised scope and price need your approval.
Yes. Analysis runs in isolation, files are not shared between customers, uploads are not used for training, and your file is used only for the work you requested. Confidentiality, EU requirements and exclusivity can be agreed before transfer, and released output is retained for 72 hours by default or 30 days on Team.
Isolated analysis. No sharing between customers. No training on your upload. Your file is used only for the work you requested.
Read the data-handling policyIsolated processing
Not yet released
Recording the work
Input deletion follows delivery. This timeline shows the default 72-hour output window. Team outputs are kept for 30 days. Audit records have a separate 90-day window.
Policy illustration, not a live deletion certificate. Deletion is confirmed from provider receipts. Assessment inputs, unpaid jobs, and account/billing records have their own rules in the policy.
Start in your account. If your upload needs manual work, we review it and email you a written scope and quote before paid work begins.
Create an account, verify your email and upload your file. We review custom work and email your scope and quote.