SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-anti-cheat

re-anti-cheat

Data & analytics

View repository

Updated 10-15 21:35

About this skill

Anti-cheat adversarial analysis (EAC / BattlEye / memory integrity checks)

When to use / when not to use

  • Use: analyze how anti-cheat components (EAC / BattlEye / Vanguard, etc.) drivers and services, and detection mechanisms work
  • Use: after a game process is rejected/kicked by anti-cheat, understand "what was detected" (defensive and research perspective)
  • Use: static reverse engineering of anti-cheat drivers (DriverEntry, IRP, memory integrity check logic) and kernel debugging observation
  • Do not use: creating or distributing cheat programs / implementing bypasses in a real game environment (explicitly prohibited, see authorization boundary）
  • Do not use: just the game's own logic (memory modification, CE) → [[re-game]]
  • Do not use: ordinary driver analysis ([[re-kernel]]); user-mode anti-debugging ([[re-evasion]])
  • Authorization boundary (required reading): This skill is limited to authorized research—own devices, own game accounts, lab environments, security research with written permission. Prohibited: creating/distributing cheat software, using bypass methods in online games to gain unfair advantages, using detection mechanism analysis for disruption. All dynamic experiments are conducted within an isolated sandbox ([[re-analyze/platform-tips]] highest principle); analysis conclusions are produced from a defensive and research perspective (understanding the detection surface → improving detection), and no actionable bypass tools are produced.

Tool preparation

Anti-cheat analysis = driver reverse engineering + kernel debugging, all within an isolated sandbox ([[re-analyze/platform-tips]] highest principle). Verify all tools before use.

Driver analysis foundation ([[re-kernel]])

  • Driver static: DriverEntry / IRP dispatch / callback reconstruction methods see [[re-kernel]] "Operation steps"
  • Decompilation: [[re-ghidra]] (default, after importing .sys load kernel types via Data Type Manager)
  • Verification: after importing the EAC/BE driver .sys, DriverEntry can be decompiled

Kernel debugging ([[re-windbg]])

  • Two-machine/VM serial (COM Named Pipe) or KDNET configuration see [[re-windbg]] "Tool preparation"
  • Kernel debugging is the primary means of observing the kernel-side execution path of anti-cheat drivers—it is not the only dynamic means for the entire anti-cheat system (user-mode components have other observation surfaces, see pitfall 1)
  • Verification: kernel session lm can see the target anti-cheat driver module,.reload /f <驱动名> load symbols

User-mode quick triage ([[re-x64dbg]] / [[re-windbg]])

  • [[re-x64dbg]]: quick inspection of auxiliary components (loaders, server side) outside protected processes
  • The target may have PPL protection butnot necessarily—first check the actual protection level before determining (GetProcessInformation(..., ProcessProtectionLevelInfo, ...) / Process Explorer / WinDbg), only non- PROTECTION_LEVEL_NONE is PPL (see pitfall 1)
  • Verification: x64dbg can open an ordinary target exe

System tools (service/driver enumeration)

  • Windows built-in:sc query / driverquery / fltmc(file system filter driver list)
  • Sysinternals (Microsoft official website): Process Explorer (process explorer view protected process flags), Sysmon
  • Verification: driverquery outputs the driver list;sc query EasyAntiCheat(EAC service name changes by version)

Operation steps

Execute in order; for each step's artifact (component list, IRP table, verification logic notes), record the evidence path + sha256 (see [[re-triage]]) for citation in the report.All steps are performed within the authorized scope and sandbox(for authorization boundaries see "When to Use").

  1. Anti-cheat component identification (driver / service)：

    driverquery /v | findstr /i "anti cheat easy battle"     # 驱动层组件
sc query | findstr /i "anti cheat easy battle vanguard"  # 服务层组件
fltmc                                                    # 文件系统过滤驱动（完整性校验常在此）
    • Typical components: EAC (EasyAntiCheat.sys + user-mode loader), BE (BEDaisy.sys + user-mode service), Vanguard (vgk.sys driver + resident service); each vendor also has update services/anti-tamper guards
    • Record: component list (driver name/service name/install path) + driver file sha256 (version anchor, see Pitfall 3) + self-protection status (check the actual protection level, do not assume PPL by default)

  2. Driver verification analysis (memory scanning / integrity)：

    • Static reconstruction ([[re-kernel]] method): DriverEntry → IRP dispatch table (IRP_MJ_DEVICE_CONTROL , etc.) → user-mode IOCTL interaction interface; focus on finding:
      • Integrity verification: periodic/triggered hashing of the game process's code and data segments (MmCopyVirtualMemory/KeStackAttachProcess -class reads the target process memory and then computes)
      • Memory scanning: scanning game process memory by signature (looking for modified code/injected modules)
      • Callback registration:PsSetCreateProcessNotifyRoutine(monitor process creation),PsSetLoadImageNotifyRoutine(monitor module loading) — the trigger entry points for verification logic
    • User-mode components: loader and service ([[re-binary-core]] decompilation) — heartbeat, reporting channel, update check
    • Artifacts: detection mechanism list (trigger point → verification content → disposition action)

  3. Detection evasion ideas (research within authorized scope)：

    • Study "how the detection mechanism works" (defensive perspective), organized as: detection surface list (integrity verification / memory signatures / behavioral timing / driver-layer monitoring)
    • Analysis output for each detection surface: detection conditions, trigger frequency, reporting channel (who receives the alert, in what format)
    • Not performed: evasion in a real game environment, development of bypass tools, cheat distribution — beyond the authorized boundary (Pitfall 2)
    • Suggested analytical uses: detection improvement (for vendors/defenders), rule writing ([[re-ioc]] approach: driver signatures, behavioral patterns)

  4. Kernel confrontation ([[re-kernel]] linkage)：

    • Kernel debugging session ([[re-windbg]]): set breakpoints on callback functions / verification functions to observe trigger timing and parameters
    • Anti-cheat driver countermeasures against debuggers: detect debug port / clear debug registers (!dr)/ bluescreen decoys — record the countermeasures during analysis (a component of the "detection surface" from a defensive perspective); all responses must be in a sandbox + snapshot ([[re-analyze/platform-tips]] highest principle)
    • Bluescreen risk: perform all breakpoint/trigger experiments inside a debugging VM, take a snapshot before operating ([[re-kernel]] Pitfall 4)
    • Artifacts: debugging session record + countermeasure list

  5. Analysis report (compliance boundary)：

    • Report structure: authorization scope statement → component list (version/hash) → detection mechanisms (trigger point/content/action) → countermeasures → defensive recommendations
    • Compliance points: The report indicates the authorized environment and purpose; it does not contain actionable bypass steps; it does not publish driver keys/signing materials; sensitive conclusions go through responsible disclosure (vendor security team/vulnerability reward)
    • Artifact: Report archive (sha256)

Cross-domain federation

  • [[re-kernel]]: Driver reverse engineering methodology foundation (DriverEntry / IRP / callbacks) + kernel debugging coordination — this skill is a fixed dependency
  • [[re-windbg]]: Kernel debugging session,!analyze -v, breakpoints and live-scene restoration (the primary means of observing kernel driver execution paths)
  • [[re-x64dbg]]: Fast localization of user-mode auxiliary components (loader/service)
  • [[re-game]]: Game-side memory modification / CE approach — the "detected object" of detection mechanisms, for comparative understanding
  • [[re-evasion]]: User-mode anti-debugging / anti-analysis countermeasure framework (contrast with driver-layer countermeasures)
  • [[re-ioc]]: Detection signatures → YARA rules / behavior pattern output (defensive perspective)
  • [[re-sandbox]] / [[re-analyze/platform-tips]]: Isolated sandbox + snapshot as the highest principle (blue screen and sample risks)

Common pitfalls and traps

  • Judging every attach failure as PPL: Symptom — x64dbg/WinDbg user-mode attach to the target is rejected ("unable to attach") or the process exits immediately/blue-screens after attaching, so it is recorded as "the target is PPL"; Cause —PPL is Windows' own process protection mechanism, with clear protection level and signer semantics（PROCESS_PROTECTION_LEVEL_INFORMATION Distinguish PROTECTION_LEVEL_NONE= unprotected,PROTECTION_LEVEL_PPL_APP= a third-party application enabled process protection, etc.),there is no universal rule such as "an anti-cheat driver is loaded ⇒ the game automatically becomes PPL"— anti-cheat can absolutely do access filtering, object callbacks, integrity checks, and anti-debugging only on the kernel side while the target process remains an ordinary process;attach rejection is only a symptom and cannot be used to infer PPL; Countermeasure — first checkthe real protection level（GetProcessInformation(..., ProcessProtectionLevelInfo, ...), Process Explorer's Protection column, WinDbg reading EPROCESS.Protection), and only non- PROTECTION_LEVEL_NONE counts as PPL; when attaching to an ordinary process fails, investigate separately: anti-cheat handle access filtering / object callbacks (ObRegisterCallbacks stripping debug privileges), user-mode anti-debugging, self-termination policies, debugger detection (debug port, debug registers,NtQueryInformationProcess debug state)
  • "Kernel debugging is the only dynamic means": Symptom — because user-mode attach does not work, the entire analysis is restricted to kernel debugging alone, skipping other observable surfaces; Cause — equating "driver kernel side" with "the entire anti-cheat system"; Countermeasure —when analyzing the internal execution path of a kernel driver, prioritize kernel debugging in an isolated environment(two machines/VM, [[re-windbg]], target inside the VM, debugger on the host, breakpoints set in kernel callbacks/check functions rather than in the game process, everything within a sandbox + snapshot, roll back on blue screen); however, user-mode service/launcher, IPC, file and registry activity, ETW/system events, network interaction, process and module lifecycleeach have corresponding dynamic observation methods, and do not become invalid just because attach does not work
  • Legal boundaries (authorized research environments only): Phenomenon — the analysis is used to create cheats / online cheating / sell bypass tools, triggering legal action and countermeasures from game vendors (bans, lawsuits); Cause — anti-cheat analysis is naturally close to cheat technology, and using bypass methods in a real game environment constitutes infringement/breach of contract; Countermeasures — strictly limit the authorized scope (own devices, own accounts, laboratories with written permission); reports should be defense-oriented only (how the detection mechanism works, how to improve detection); do not publish actionable tools, do not disclose driver-sensitive materials; take "understanding the detection surface" as the boundary, and do not produce "successful bypass" as an output
  • Frequent anti-cheat updates (conclusions become outdated): Phenomenon — the function addresses/offsets/detection points analyzed last week all become invalid, and the report conclusions are "outdated"; Cause — EAC/BE releases a version every few days, and driver packing/obfuscation and structural changes are frequent; Countermeasures — analysis must be anchored to a version: record the driver sha256, file version number, and analysis time (Step 1); the report should note the version and date; analysis methods (IRP reconstruction, callback enumeration, IOCTL decoding) are reusable across versions, while specific addresses/offsets are not reusable across versions
  • Escalation of bypass technology confrontation (misdirected analysis): Phenomenon — the "weaknesses" identified are quickly fixed or trigger new detections, falling into point-by-point confrontation; Cause — anti-cheat is a continuous confrontation engineering effort, and single-point bypass will inevitably escalate; Countermeasures — position the analysis as "understanding the detection surface" (system perspective) rather than "creating vulnerabilities" (single-point perspective); organize outputs by detection surface (integrity/memory/behavior/driver layer) and provide defense recommendations; the cases of confrontation escalation are themselves defense research material (record comparisons of old and new detection mechanisms)
  • CSAuth3 heartbeat protocol is self-contained and can be reproduced offline (GameGuard): Phenomenon — the anti-cheat heartbeat packet (header KDF + payload transformation + double CRC) is error-prone to black-box guessing, and static reverse engineering has no starting point; Cause — CSAuth3 is the heartbeat challenge-response loop between the GameMon client and the peer (the peer sends a challenge packet, the client returns a heartbeat packet),all cryptographic material is hardcoded constants(Blowfish K=0x91284712, public π table), and only the counter and prev_size change per session — the first packet has seed=0 (counter=0, K=0x91284712, payload is 8 bytes all zero, and an empty payload is not scrambled); Countermeasures — restore layer by layer in the order "header KDF decryption → CRC1 → Blowfish inverse transformation → CRC2";scramble/descramble are the same function(Blowfish encryption/decryption symmetry: the sender's plaintext TLV is run through bf_dec to become the on-the-wire ciphertext, and the receiver runs it through bf_dec to restore it); when constructing packets, you mustscramble first and then compute CRC2(CRC2 verifies the payload after descramble); the key schedule is determined offline → a pure offline heartbeat is feasible
  • The error code table is the black-box accelerator for heartbeat replay: Phenomenon — a constructed heartbeat packet is rejected by the peer, and you do not know which verification layer it is stuck at; Cause — CSAuth3 returns different error codes for each type of verification failure (0xBAE first-packet flag normal, 0xCE9 CRC1 mismatch, 0xCE8 CRC2 strict mismatch, 0xBB8 CRC2 mapping mode base value, 0xCE5 seq>5, 0xCEA magic≠0x1E, 0xCEF/0xCEC size out of bounds, 0xD4A body not 8-aligned, 0xD52 message count mismatch, 0xD913 message type 1 hash failure, etc.); Countermeasures — infer the failed layer from the error code (errors ≥0xBB8 set the error flag → subsequent Check falsely passes, Get stops sending); hooking the client's callback handler that processes the challenge packet can directly reveal what should be sent, and forwarding it is enough
  • CR3 encryption (EAC-type kernel anti-cheat): Phenomenon — reading _KPROCESS.DirectoryTableBase What you get is the wrong CR3, and traversing process memory is completely garbled/access exceptions occur; the reason—the anti-cheat takes over kernel exceptions and writes the wrong value to DirectoryTableBase; when operations such as attaching/reading the process that need to access this field trigger an exception, the true value is only repaired in the exception callback after the takeover; countermeasure—common methods to obtain the real CR3:The page frame ListEntry.Flink points to the encrypted process K/EPROCESS structure pointer, traverse MmPfnDataBase compare page frame by page frame whether the Flink decrypted value is the target process structure; if it matches, the real CR3 is obtained; note version differences: the encryption algorithm of Win11 24H2 and some higher versions of Win10/11 (MiSetPageTablePfnBuddy visible) differs from other versions and must be adapted by version; before analysis, first confirm the target system version (see [[re-kernel]] pitfalls of structures changing with versions)