So funktionieren Kernel-Anti-Cheat-Systeme

• Moderne kernelbasierte Anti-Cheat-Systeme gehören unter Windows zu den komplexesten Sicherheitssoftwares und überwachen während des Spiels Speicher und Systemereignisse auf Kernel-Ebene.
• Um die Grenzen des User-Mode-Schutzes zu überwinden, nutzen sie Kernel-Treiber und überwachen in Echtzeit Prozess- und Thread-Erstellung, das Laden von Images sowie Registry-Änderungen.
• Wichtige Systeme wie BattlEye, EasyAntiCheat, Vanguard, FACEIT AC arbeiten mit einer dreistufigen Struktur aus Kernel-Treiber, Service und Spiel-DLL; das beim Booten geladene Vanguard besitzt dabei die stärkste Kontrolle.
• Sie kombinieren mehrschichtige Abwehrmechanismen wie Speicherscans, Hooking-Erkennung, Treiber-Integritätsprüfung, Schutz vor DMA-Angriffen und verhaltensbasierte Erkennung, um Cheats zu blockieren.
• Letztlich entwickeln sich TPM-basierte Remote-Attestierung und Hardware-Vertrauensprüfung zur zentralen Grundlage der Spielesicherheit.

---

1. Grenzen des User-Mode-Schutzes und der Wechsel zum Kernel

• User-Mode-Prozesse stehen unterhalb der Kernel-Rechte und werden daher von Cheats auf Kernel-Treiber- oder Hypervisor-Ebene leicht umgangen.
  • Beispiel: Aufrufe von ReadProcessMemory können durch Kernel-Hooking gefälscht werden.
• Cheats im Kernel-Mode können den Spielspeicher direkt manipulieren und User-Mode-Erkennung umgehen.
• Als Reaktion darauf verlagert sich Anti-Cheat auf Kernel-Ebene, um mit denselben Rechten zu überwachen.

2. Das „Wettrüsten“ zwischen Cheat und Anti-Cheat

• Das Rechte-Eskalationsrennen von User-Mode → Kernel → Hypervisor → DMA geht weiter.
• Anti-Cheat reagiert mit Treiber-Blockierung, Hypervisor-Erkennung und IOMMU-basierter DMA-Abwehr.
• Dieser Prozess erhöht Kosten und Schwierigkeitsgrad der Cheat-Entwicklung und erschwert normalen Nutzern den Zugang.

3. Wichtige Kernel-Anti-Cheat-Systeme

• BattlEye: Fokus auf den Kernel-Treiber BEDaisy.sys, Registrierung von Callbacks für Prozesse, Threads und Image-Ladevorgänge.
• EasyAntiCheat(EAC): Gehört Epic Games und nutzt eine ähnliche 3-Schichten-Struktur.
• Vanguard: Lädt vgk.sys beim Booten und bietet mit einem Treiber-Whitelist-Modell starke Kontrolle.
• FACEIT AC: Erreicht hohe Vertrauenswürdigkeit durch Überwachung auf Kernel-Ebene.
• Die ARES-2024-Arbeit hält fest, dass diese Systeme eine rootkit-ähnliche technische Struktur haben, ihr Zweck aber Verteidigung ist.

4. Die 3-Schichten-Struktur von Kernel-Anti-Cheat

• Kernel-Treiber: Führt System-Call-Hooking, Speicherscans und Zugriffskontrolle aus.
• User-Mode-Service: Zuständig für Netzwerkkommunikation, Ban-Verwaltung und Telemetrie-Übertragung.
• Spiel-DLL: Führt Prüfungen innerhalb des Spielprozesses aus und kommuniziert per IPC mit dem Service.
• Die gegenseitige Kommunikation erfolgt über IOCTL, Named Pipe und Shared Memory.

5. Unterschied zwischen Boot-Load und Runtime-Load

• BattlEye/EAC: Laden den Treiber beim Spielstart und entladen ihn beim Beenden.
• Vanguard: Wird beim Booten geladen und überwacht alle danach geladenen Treiber.
  • Dadurch ist ein Systemneustart erforderlich, dafür ist Schutz schon ab der Boot-Phase möglich.

6. Überwachung auf Basis von Kernel-Callbacks

• ObRegisterCallbacks: Kontrolliert den Zugriff auf Prozess-Handles und blockiert Speicherzugriffe externer Prozesse.
• PsSetCreateProcessNotifyRoutineEx: Blockiert die Erstellung von Cheat-Prozessen.
• PsSetCreateThreadNotifyRoutine: Erkennt auffällige Threads im Spielprozess.
• PsSetLoadImageNotifyRoutine: Erkennt das Laden nicht erlaubter DLLs.
• CmRegisterCallbackEx: Überwacht Registry-Änderungen.
• Minifilter-Treiber: Blockieren auf Dateisystemebene den Zugriff auf Cheat-Dateien.

7. Speicherschutz und Scanning

• Einschränkung des Handle-Zugriffs blockiert externes Lesen und Schreiben von Speicher.
• Hash-Prüfung von Code-Sektionen erkennt Code-Patches.
• Traversal des VAD-Baums erkennt manuell gemappten ausführbaren Speicher.
• Anonymer ausführbarer Speicher, manuell gemappte DLLs und Shellcode werden heuristisch identifiziert.

8. Injektions-Erkennung

• Erkennung verschiedener Injektionsmethoden wie CreateRemoteThread, APC, NtMapViewOfSection, Reflective DLL.
• Stack-Frame-Analyse (RtlWalkFrameChain) prüft, ob anomaler Code ausgeführt wird.

9. Hooking-Erkennung

• IAT-Hooking: Erkennt Manipulationen der Import Address Table.
• Inline-Hooking: Prüft anhand von JMP-Befehlen am Funktionsanfang, ob Patches vorliegen.
• Integritätsprüfungen von SSDT, IDT und GDT verhindern Hooking auf Kernel-Ebene.
• Erkennung direkter Syscall-Nutzung blockiert Umgehungsversuche an ntdll vorbei.

10. Schutz auf Treiber-Ebene

• Erkennt unsignierte Treiber und den Test-Signing-Mode.
• Führt Blocklisten gegen BYOVD-Angriffe (Missbrauch verwundbarer Treiber).
• Überwacht Kernel-interne Strukturen wie PiDDBCacheTable, MmUnloadedDrivers und BigPool, um manuell gemappte Treiber zu erkennen.

11. Anti-Debugging und Schutz vor Analyse

• NtQueryInformationProcess prüft das Vorhandensein eines Debuggers.
• Die Variable KdDebuggerEnabled erkennt Kernel-Debugger.
• Das Flag ThreadHideFromDebugger erkennt versteckte Threads.
• Zeitmessungen auf Basis von RDTSC, Hardware-Breakpoints und das Vorhandensein eines Hypervisors blockieren Analyseumgebungen.

12. DMA-basierte Cheats und Gegenmaßnahmen

• PCIe-DMA-Geräte lesen Speicher ohne Beteiligung der CPU.
• Die IOMMU begrenzt DMA-Zugriffe, kann aber bei Deaktivierung oder Fehlkonfiguration wirkungslos werden.
• Das Tarnen von FPGA-Geräten als legitime Geräte erschwert die Erkennung.
• Secure Boot und TPM 2.0 können durch Prüfung der Boot-Integrität teilweise Abhilfe schaffen.

13. Verhaltensbasierte Erkennung und Machine Learning

• Analyse von Mauseingaben unterscheidet menschliche Bewegungen von Auto-Aim.
• CNN- und Transformer-Modelle werden zur Erkennung von Triggerbots und Aimbots eingesetzt.
• Graph Neural Networks erkennen teambasierten Betrug wie Wallhacks und Kollusion.
• Telemetrie-Pipeline: Kernel-Input-Erfassung → verschlüsselte Übertragung → serverseitige ML-Analyse → Ban-Entscheidung.

14. Virtuelle Umgebungen und Umgehung von Analyse

• Erkennt VMs über das CPUID-Hypervisor-Bit und Vendor-Strings.
• Prüft Registry- und Geräte-Spuren von VMware, VirtualBox und Hyper-V.
• Doppelte Virtualisierungsumgebungen lassen sich an Verzögerungen bei der Befehlsausführung erkennen.

15. Hardware-Identifikation und Durchsetzung von Sperren

• Erzeugt HWIDs aus SMBIOS, Festplatte, GPU, MAC und MachineGuid.
• HWID-Spoofing wird über Registry-, Treiber- und physische Manipulation versucht,
  kann aber durch abweichende Identifikatoren oder ungewöhnliche Formate erkannt werden.

16. Zukünftige Trends und technischer Wandel

• Nach DMA folgt als nächste Stufe firmwarebasierter Cheat, was die Erkennung maximal erschwert.
• KI-basierte Hardware-Aimbots sind schwer von menschlicher Eingabe zu unterscheiden.
• TPM-basierte Remote-Attestierung und Cloud-Gaming gewinnen als langfristige Alternativen an Bedeutung.
• Kernel-Anti-Cheat bleibt zwar die praktische Frontlinie,
  doch Hardware-Vertrauensprüfung und serverseitige Validierung werden als die eigentliche Zielrichtung gesehen.

[GN⁺]

Hacker-News-Kommentare

• Kurz gesagt: Moderne Cheats umgehen Anti-Cheat mit Hypervisoren, BIOS-Patches oder DMA-Geräten.
  Je stärker der Schutz auf Hardware-Ebene wird, desto weiter entwickeln sich auch die Cheat-Entwickler.
  Mit dem Aufkommen von KI-basierter Spielanalyse zeigen jedoch Methoden Wirkung, die die Cheater selbst erkennen.
  Letztlich liegt die Zukunft eher bei Anti-Cheat im User-Mode und Gameplay-Analyse als im Kernel-Modus.

  • Dass BIOS-Patching „sehr populär“ sei, klingt übertrieben.
    Eher wirkt es wie ein Beleg dafür, dass Anti-Cheat tatsächlich gut funktioniert.
    Früher reichte es, einfach ein Programm herunterzuladen, um sofort zu cheaten, aber heute ist die Einstiegshürde so hoch, dass viele es gar nicht erst versuchen.
    Allerdings hieß es im ersten Teil des Artikels auch, dass solche Abwehrmaßnahmen neutralisiert werden können, weshalb sich die Frage stellt, ob sie dann überhaupt vertrauenswürdig sind.
  • Ich spiele WoW, und es gab viele Beschwerden darüber, dass Blizzard unschuldige Nutzer gebannt habe.
    Mir wurden auch zwei Accounts gesperrt, aber der Kundensupport hat das wieder aufgehoben.
    Da KI offenbar im Support eingesetzt wird, dürfte es viele ungerechte Bans geben.
    Solche verhaltensbasierten Ban-Systeme bergen das Risiko, sogar engagierte Nutzer fälschlich zu bestrafen, weshalb ihnen schwer zu trauen ist.
  • Die von dir genannten Techniken erhöhen die Angriffskosten.
    Das heißt: Nicht mehr jeder kann einfach Cheats entwickeln, also ist Anti-Cheat in gewissem Maß erfolgreich.
    Gameplay-Analyse erwischt allerdings wahrscheinlich nur offensichtliche Cheater und übersieht einfache ESP-Arten eher.
  • Verhaltensanalyse kann „heimliche Cheater“ nicht erkennen.
    Gerade solche Cheater sind gefährlicher, weil sie eine Community langsam zersetzen.
  • ActiBlizz ist fast das einzige Unternehmen, das regelmäßig rechtlich gegen kostenpflichtige Cheat-Entwickler wie Bossland oder EngineOwning vorgeht.

• Am Kernel herumzufummeln heißt, das gesamte Sicherheitsmodell des OS zu ignorieren.
  Es gab tatsächlich Fälle, in denen fehlerhafte Anti-Cheat-Software zur Übernahme von Root-Rechten ausgenutzt wurde.
  Eigentlich sollte man die Sandbox-Funktionen des OS und die Vertrauenskette beim Booten nutzen.

  • Das PC-Ökosystem nimmt Sicherheit in der Boot-Kette nicht so ernst wie Smartphones.
    Deshalb ist es schwer, sich nur auf OS-Funktionen zu verlassen, und auch Attestation ist in der Praxis nur begrenzt anwendbar.
    Selbst wenn es nicht perfekt ist, hat es einen Wert, wenn sich die Zahl der Cheater statistisch senken lässt.
  • Echte Sicherheit bedeutet nicht, den Client abzuriegeln, sondern nur serverseitig erlaubtes Verhalten zu validieren.
  • Da fragt man sich, ob das heißen soll: „Sollen wir verriegelte PCs verkaufen, auf denen nur verifizierte Software installiert werden kann?“
  • Die Behauptung, es sei sinnlos, den Schaden zu begrenzen, nachdem ein Angreifer bereits eingedrungen ist, trifft auf die Cybersicherheit insgesamt nicht zu.
  • Cheats verhindern zu wollen, indem man allen die Freiheit nimmt, beliebige Software auszuführen, geht zu weit.

• Ich würde gern ein Spiel mit einem optionalem Anti-Cheat-Matchmaking-System sehen.
  Dann würden nur Spieler mit aktiviertem Anti-Cheat miteinander gematcht, während Spieler ohne Anti-Cheat durch Selbstregulierung der Community organisiert würden.
  So ein Experiment könnte wohl nur ein Unternehmen von der Größe Valves umsetzen.

  • CS2 von Valve nutzt offenbar etwas Ähnliches, aber soweit ich gehört habe, ist die Cheat-Rate höher als bei Valorant.
  • FACEIT erfüllt diese Rolle bereits.
    Gemeinschaftliche Selbstregulierung ist im großen Maßstab aber nie wirklich effizient.
  • Es gab auch die Reaktion: „Ist das nicht einfach PlaySafe ID?“
  • Ich mag diese Idee ebenfalls.
    Persönlich denke ich, wenn Cheater dabei sind, ist es besser, das Spiel einfach zu schließen und mal raus an die frische Luft zu gehen.
    Bevor ich mir ein Anti-Cheat auf Kernel-Ebene installiere, das wie Malware wirkt, spiele ich lieber auf der Konsole.

• Cheater zeigen ihrem Wesen nach abnormale Verhaltensmuster, daher müsste man sie erkennen können, wenn man serverseitig alle Eingaben protokolliert und ML-basierte Anomalieerkennung anwendet.
  Außerdem kann man „Honeypot“-Objekte erstellen, auf die nur Cheater reagieren.

  • Allerdings kann man nicht allein anhand statistischer Ausreißer sicher sagen, dass jemand cheatet.
    Wie bei p-hacking kann man zufällige Schwankungen fälschlich für ein bedeutungsvolles Signal halten.
  • Ich vertrete schon lange ein statistisches Honeypot-Modell.
    Tatsächlich hat Dota 2 alle Accounts gebannt, die anomale Datenbereiche im Client ausgelesen haben.
    Zugehörige Patch-Mitteilung
  • Valve nutzt zwar ebenfalls ML-Modelle, trotzdem gibt es in Counter-Strike weiterhin viele Cheater.
    Das Problem löst sich nicht dadurch, dass man einfach nur ML darauf wirft.
  • Honeypots sind nützlich, aber nicht ausreichend.
    Verhaltensanalyse hat es schwer, mit der Geschwindigkeit des Wandels in der Community mitzuhalten.
  • In CS2 lassen sich schon anhand der Statistik zur „time-to-damage“ viele Cheater unterscheiden.
    Cheater reagieren gewöhnlich etwa 100 ms schneller als Profis.

• Ich bin zwar kein Gamer, aber das Problem der Cheat-Verhinderung in Online-Spielen erscheint mir technisch als ein hochinteressantes schwieriges Problem.
  Der Ratschlag „verlagert einfach alles auf den Server“ ist nicht realistisch.

  • Cheat-Verhinderung ist praktisch unmöglich.
    Spiele sind nicht die Olympischen Spiele, sondern eher eine lokale Hobbyliga, daher ist Spaß wichtiger als perfekte Fairness.
    Wenn Cheater untereinander gematcht werden, sinkt der Einfluss auf normale Nutzer.
  • Die effektivste Methode sind aktive Server-Administratoren, die direkt beobachten und bannen.
    Große Spielefirmen beschäftigen dafür aber kein solches Personal.
  • Technisch gesehen sind Cheater immer im Vorteil, weil sie die Maschine kontrollieren, auf der das Spiel läuft.
    Anti-Cheat erhöht nur die Eintrittshürde.
  • Vielleicht wäre auch eine verteilte Struktur möglich, bei der Server wie bei Netflix in die Nähe der ISP rücken.
  • Die grundlegendste Lösung ist ein kultureller Wandel in der Wahrnehmung.
    Es braucht ein Klima, in dem Menschen, die online cheaten, als Loser gelten.

• Kernel-Level-Anti-Cheat versucht, den Client so weit wie möglich abzuriegeln, trotzdem gibt es weiterhin Cheater.
  Das heißt letztlich, dass der Server dem Client nie vollständig vertrauen kann.

  • Das ist nicht nur eine Kostenfrage, sondern auch eine Frage von Latenz und unterschiedlichen Zeitpunkten.
    Auch mit Netzwerkcode lässt sich das nicht vollständig lösen.
  • Ein entschlossener Cheater könnte Eingaben auch mit einer Kamera und einem separaten Computer automatisieren.

• Die heutige Kultur in kompetitiven Spielen ist eine Struktur, in der Unternehmen Nutzer dazu bringen, statt mit Freunden mit Fremden zu konkurrieren.
  Aber man fragt sich schon, ob das wirklich nötig ist.

  • Trotzdem genießen viele Menschen den Wettbewerb an sich.
    Sich wie im Sport oder Schach mit anderen zu messen, ist ein zutiefst menschliches Bedürfnis.

• Die Formulierung, Kernel-Anti-Cheat sei „die ausgefeilteste Software“, klingt übertrieben.
  Systemaufrufe abzufangen, ist keine besonders außergewöhnliche Technik.

  • Die Aussage, man scanne Speicherstrukturen, die „die meisten Programmierer ihr Leben lang nie anfassen“, ist etwas lächerlich.

• Viele hier scheinen nie kompetitive Spiele gespielt zu haben.
  Kernel-level anti-cheat (KLAC) wirkt in der Praxis tatsächlich.
  Gegenüber VAC/VACNet ist die Cheat-Rate bei Kernel-Lösungen wie FACEIT oder Vanguard deutlich geringer.
  Perfekt ist das natürlich nicht, aber die Einstiegshürde steigt massiv.
  Allein DMA-Geräte kosten mehrere Hundert Dollar, und fortgeschrittene Cheats sind als Abo teuer.
  Spiele sind eine freiwillige Entscheidung; wer KLAC nicht will, muss sie nicht spielen.
  Wer es aber ablehnt, muss dann eben eine von Cheatern dominierte Umgebung in Kauf nehmen.

• Ich hatte gehört, dass mit TPM-basierter Boot-Messung und UEFI Secure Boot auch Remote-Attestation möglich sei, daher überrascht es mich, dass Angreifer das manipulieren können sollen.

  • Als Beispiel erklärt tee.fail, wie sich Remote Attestation aushebeln lässt.
    Wir sollten die Freiheit haben, volles Eigentum an unseren Geräten zu behalten, ohne deshalb benachteiligt zu werden.
  • Die Kommunikation zwischen Mainboard und TPM-Chip ist nicht verschlüsselt, sodass sich Werte per MITM-Angriff verändern lassen.