Reverse-Engineering-Analyse des Call-of-Duty-Anti-Cheats

 (ssno.cc)
1 Punkte von GN⁺ 2025-01-21 | 1 Kommentare | Auf WhatsApp teilen
  • TAC (Treyarch Anti-Cheat) in Black Ops Cold War ist ein User-Mode-Anti-Cheat ohne Ricochet-Kerneltreiber, weist aber eine Code-Struktur auf, die weitgehend der aktueller Call-of-Duty-Titel ähnelt
  • Die Schutzschichten kombinieren ausführbare Verschlüsselung, Checksummen, jmp-Verschleierung und Entry-Point-Verschleierung von Arxan mit Pointer-Verschlüsselung aus der Treyarch/IW-Familie
  • TAC führt mehrere User-Mode-Erkennungen durch, darunter Runtime-API-Hash-Lookups, Prüfungen auf API-Hook-Muster, Debug-Register-Prüfungen, Erkennung von Windows-Testsignierung, Konsolenzuweisung sowie DirectX-/Overlay-Erkennung
  • Externe Overlays erfassen Fensterstil, Position, Display Affinity und die Modulliste des Prozesses und laden diese zum Server hoch; Memory-Scanner wie Cheat Engine können über Virtual-Memory-Honeypots erkannt werden
  • Die ungewöhnlichste Technik sind verschlüsselte Custom-Syscall-Stubs, die ntdll-Hooks umgehen und die Herkunft des Syscalls wie eine andere ntdll-Funktion aussehen lassen, was Monitoring erschwert

Analyseziel und Umfang

  • Analysiert wird der User-Mode-Anti-Cheat innerhalb von Black Ops Cold War; die Bezeichnung lautet TAC (Treyarch Anti-Cheat)
  • Black Ops Cold War enthält nicht die Kernel-Mode-Komponente von Ricochet, die in Modern Warfare 2019 und späteren Titeln vorhanden ist
  • Der größte Unterschied zu aktuellen Call-of-Duty-Spielen ist der Kernel-Mode-Treiber; der Großteil des Anti-Cheat-Codes läuft im User Mode und ist TAC sehr ähnlich
  • Funktions-Pseudocode wurde rekonstruiert, da die tatsächlichen Decompilation-Ergebnisse durch Verschleierungs- und Resolver-Code komplex sind
  • Einige Inhalte wurden entfernt, um Werbung für Cheating oder Umgehung zu vermeiden

Arxan und Schutz der ausführbaren Datei

  • Arxan ist ein Obfuskations- und Schutzwerkzeug, das seit Black Ops 3 in vielen Call-of-Duty-Spielen eingesetzt wird
  • Laufzeit-Entschlüsselung der ausführbaren Datei
    • Die ausführbare Spieldatei ist gepackt und verschlüsselt
    • Arxan injiziert während des Startvorgangs Code, der die eigentliche ausführbare Spieldatei entpackt und entschlüsselt
  • Checksummen der ausführbaren Datei
    • Arxan überwacht kontinuierlich Patches an der ausführbaren Spieldatei
    • Wird ein Debugger oder eine Checksummen-Abweichung erkannt, wird der Prozess beendet
  • jmp-Verschleierung
    • Zwischen die Instruktionen einer Funktion werden zahlreiche jmp eingefügt, um statische Analyse zu erschweren
    • Wenn in große Funktionen Hunderte Sprünge eingefügt werden, bricht die IDA-Analyse und externe Werkzeuge werden nötig
  • Entry-Point-Verschleierung
    • Geschützter Arxan-Code entpackt den eigentlichen Entry Point und führt ihn aus
    • Auch in diesem Bereich kann jmp-Verschleierung enthalten sein, was das Nachverfolgen des Kontrollflusses erschwert

Pointer-Verschlüsselung

  • Wichtige Pointer werden unmittelbar vor der Verwendung verschlüsselt bzw. entschlüsselt
    • Aktuelles globales Spielobjekt
    • Entity-Array
    • Objekt-Pointer usw.
  • Für dasselbe Verschlüsselungsverfahren gibt es 16 Varianten; die aktuelle PEB-Adresse entscheidet, welche Variante verwendet wird
  • Dieses Verfahren behindert Pointer-Scans von Cheat Engine
    • In globalen Werten werden nur verschlüsselte Werte gespeichert
    • Entschlüsselte Werte existieren nur auf dem Stack
  • Um entschlüsselte Pointer zu erhalten, muss man ein Tool zum Nachverfolgen der Entschlüsselungsinstruktionen verwenden oder an einer Stelle hooken, an der das Spiel den Pointer bereits entschlüsselt hat

Runtime-API-Lookup und Hook-Erkennung

  • TAC verwendet eine inline implementierte Funktion für Runtime-API-Lookups
    • Sie nimmt einen Modul-Hash und einen API-Namens-Hash entgegen
    • Sie durchläuft die Liste geladener Module und hasht deren Namen
    • Sie durchläuft die Export-Funktionen des Moduls und vergleicht sie mit Compile-Time-Hashes
  • Die Hash-Identifikation erfolgt anhand der Liste geladener Module im Spielprozess und der Hashing-Funktion des Spiels
    • Hashes von Modulnamen und Export-Namen werden berechnet
    • Aus dem Decompilation-Ergebnis werden base hash und function hash manuell entnommen und mit der aufgerufenen API abgeglichen
  • Die Hashes sind nicht über Spielversionen hinweg identisch
  • Da Funktions-Pointer in globalen Variablen gespeichert werden, lassen sie sich auch identifizieren, indem man virtuelle Adressen mit Export-Funktionen geladener DLLs vergleicht
  • Die API-Hook-Erkennung von TAC prüft derzeit nur 7 Muster
    • Stubs aus der push/movabs/xchg/ret-Familie
    • push imm gefolgt von ret
    • call
    • jmp [rip+x]
  • Es werden nicht alle wichtigen APIs geprüft, sondern Hooks auf die von TAC selbst verwendeten APIs

Debug-Register und Erkennung von Treiber-Testsignierung

  • Debug-Register können als nicht codebasierte Patch-Hook-Methode genutzt werden, um Arxans .text-Patch-Überwachung zu umgehen
  • TAC prüft im Thread-Kontext die Werte von DR0 bis DR3
    • Ist ein Wert vorhanden, wird je nachdem, ob er innerhalb des aktuellen Prozesses liegt, ein Callback mit unterschiedlicher Meldung aufgerufen
    • Anschließend verzweigt der Ablauf zu einer Beendigungsfunktion
  • DR0 bis DR3 sind privileged registers und können daher nicht direkt mit normalem Assembler gelesen werden; sie müssen über den Windows-Kernel oder Exception-Dispatching bezogen werden
  • Der Windows-Testmodus erlaubt die Ausführung von Kernel-Mode-Treibern ohne reguläre Signatur
  • TAC prüft mit NtQuerySystemInformation, ob Testsignierung aktiviert ist
    • Diese Erkennung allein führt nicht direkt zu einem Ban, markiert aber das Konto als flagged

Prozessbeendigung

  • TAC beendet Prozesse auf zwei Arten
  • Die erste Methode löscht Register und ruft anschließend NtTerminateProcess auf
    • RCX wird auf -1 gesetzt
    • Wenn erkannt wird, dass NtTerminateProcess gehookt ist, wird diese Methode nicht verwendet
  • Die zweite Methode löscht Register und springt dann nach 0x0, wodurch der Prozess crasht
  • Beide Methoden löschen wichtige Register, was eine Wiederherstellung erschwert

Erkennung von Konsole, Visualisierung und Overlays

  • Interne Cheats können AllocConsole verwenden, um Log-Ausgaben oder Menüs umzusetzen
  • TAC erkennt Konsolenzuweisungen, indem es das Konsolenfenster oder ConsoleHandle im PEB prüft
  • Interne Visualisierungen werden meist über Grafik-API-Hooks auf den Bildschirm gezeichnet
    • Aktuelle Call-of-Duty-Spiele verwenden DirectX 12
    • Ein häufiges Hook-Ziel ist IDXGISwapChain::Present
    • In DirectX 12 wird eine command queue benötigt; ID3D12CommandQueue::ExecuteCommandLists ist ein häufiger Ansatzpunkt, um sie zu bekommen
  • OBS Studio, Streamlabs OBS, das Discord-Game-Overlay und das Steam-Game-Overlay können an ähnlichen Stellen arbeiten
    • Steam und Discord führen Zeichenvorgänge aus
    • OBS-artige Tools erfassen beim Game Capture das gerenderte Bild
  • TAC scannt derzeit nicht die DXGI-present-Funktion selbst, sondern prüft den present-Pointer in der vtable

Externe Cheats und fensterbasierte Erkennung

  • Externe Cheats erstellen mit hoher Wahrscheinlichkeit ein overlapped window, das über dem Spielfenster liegt
  • TAC durchläuft alle Fenster und prüft mit GetWindowLongA den Stil WS_EX_LAYERED
  • Danach vergleicht es mit GetWindowRect, ob sich das Fenster mit dem Spielfenster überschneidet
    • Wenn die Überlappungsquote mindestens 0.5 beträgt und weniger als 8 Einträge im Cache sind, wird das betreffende hwnd gespeichert
    • Als Beispielbildschirmgröße taucht ein Wert auf, der 1920x1080 entspricht
  • Zwischengespeicherte Fenster werden in einer separaten Funktion weiter untersucht
    • Prüfung des Fenstertexts mit GetWindowTextW
    • Prüfung des Klassennamens mit GetClassNameA
    • Prüfung der Display Affinity mit GetWindowDisplayAffinity
  • Auch Fälle, in denen SetWindowDisplayAffinity und WDA_EXCLUDEFROMCAPTURE genutzt werden, um das Fenster vor Aufnahme- und Screenshot-Tools zu verbergen, werden von TAC geprüft
  • Fensterbezogene Informationen werden in einem verschlüsselten Buffer gespeichert und zum Server hochgeladen
    • Fenstertext
    • Klassenname
    • Fensterposition und -stil
    • Display Affinity
    • Modulliste und exe-Name des Prozesses mit dem überlappenden Fenster
  • Der Prozess des überlappenden Fensters wird mit OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) geöffnet; Modulnamen werden mit K32EnumProcessModules und K32GetModuleFileNameExW gesammelt

Erkennung von Memory-Scannern wie Cheat Engine

  • Cheat Engine ist aufgrund des Verhaltens von virtuellem Speicher unter Windows leicht zu erkennen
  • Selbst wenn ein Programm mit VirtualAlloc virtuellen Speicher reserviert, wird dieser vor dem Zugriff nicht durch physischen Speicher backing
  • Das Spiel kann Speicher reservieren und anschließend ungenutzt lassen
  • Wenn Cheat Engine oder der Memory-Tab von Process Hacker diesen Bereich scannt, findet ein Zugriff statt und der Speicher wird valid
  • Ein Honeypot im TAC-Stil erkennt Memory-Scanner, indem er mit K32QueryWorkingSetEx prüft, ob auf diese virtuelle Adresse tatsächlich zugegriffen wurde

Erschwerung von Signature Scans

  • Game-Hacker nutzen häufig signature scanning, damit Cheats auch nach Updates automatisch funktionieren
  • Treyarchs Idee besteht darin, bei Funktionen, die nicht erneut aufgerufen werden, den Bereich um die return address mit PAGE_NOACCESS zu schützen
  • Ein signature scanner liest die Bytes der ausführbaren Datei von Anfang bis Ende und sucht nach Mustern
  • Da es sehr langsam wäre, für jedes Byte die Zugriffsberechtigung abzufragen, kann der Prozess crashen, sobald ein PAGE_NOACCESS-Bereich erreicht wird
  • Diese Methode ist kein vollständiger Schutz, kann aber vielen Analysten die Arbeit erschweren

Anti-Debugging

  • Die Anti-Debug-Prüfungen von TAC selbst sind einfach, Arxan stellt jedoch zusätzlich eigene Anti-Debugging-Techniken bereit
  • TAC durchläuft alle Threads des aktuellen Prozesses
    • Es verwendet CreateToolhelp32Snapshot und einen thread snapshot
    • Im TEB jedes Threads wird DbgSsReserved geprüft, um das Vorhandensein eines DebugObject zu erkennen
  • Es gibt auch eine Technik, bei der in ungültigen Speicher geschrieben wird, um eine access violation auszulösen
    • Erreicht der Code die Stelle nach der Exception, wird angenommen, dass ein Debugger die Exception behandelt oder umgangen hat
  • CheckRemoteDebuggerPresent wird ebenfalls verwendet
  • ThreadHideFromDebugger sorgt dafür, dass Exceptions nicht an den Debugger, sondern an den Prozess gesendet werden
    • Wenn der Debugger versucht, den Prozess anzuhalten, kann eine STATUS_BREAKPOINT-Exception auftreten und den Prozess beenden
    • Im User Mode kann dieses Flag nicht zurückgesetzt werden
    • Diese Taktik wird in einem TLS callback vor dem Entry Point der ausführbaren Datei ausgeführt

Überwachung des Netzwerkverkehrs

  • TAC speichert nicht alle aktiven Verbindungen, sondern sucht nur nach bestimmten Bedingungen
  • Erkannt wird die Methode, innerhalb des Spielprozesses einen lokalen Netzwerkserver zu erstellen
    • Der Cheater schreibt shellcode in den Spielprozess
    • Innerhalb des Spielprozesses wird ein Netzwerkserver gestartet
    • Eine externe Anwendung tauscht mit diesem lokalen Server Informationen aus
  • TAC holt mit GetTcpTable2 die TCP-Tabelle und erkennt die Bedingung, indem es Verbindungen des aktuellen Prozesses mit Portbeziehungen anderer Prozesse vergleicht

Verschlüsselte Custom-Syscall-Stubs

  • Viele exportierte APIs von ntdll führen intern einen syscall aus
  • Mit Custom-Syscall-Stubs lassen sich Hooks auf ntdll-Funktionen durch User-Mode-Cheats umgehen
  • Syscalls können über instrumentation callbacks sichtbar werden
    • Ein instrumentation callback wird nach einem syscall aufgerufen
    • Die Rücksprungadresse liegt direkt hinter der syscall instruction
  • TAC erschwert statische Analyse mit verschlüsselten Syscall-Stubs
  • Der Stub wird aufgebaut, nachdem ein großer Bereich in der .text-Sektion mit Schreib-/Ausführungsrechten geschützt wurde
  • In NtReadFile wird die syscall instruction gesucht, und CPU-Zeitwerte werden als Zufallselement genutzt, um die Position zu verändern
  • Für Monitoring kann es so aussehen, als käme der syscall aus einer beliebigen ntdll-Funktion
    • Der tatsächliche syscall muss nicht NtReadFile sein
    • Wenn der syscall index in eax nicht geprüft werden kann, ist schwer erkennbar, um welchen syscall es sich handelt
  • Es gibt ein Beispiel, bei dem sich die Position der syscall instruction bei erneuter Ausführung ändert

Erkennung von Umgehungen der Anti-Debugger-Verbergung

  • Um ThreadHideFromDebugger zu setzen, muss NtSetInformationThread aufgerufen werden
  • Cheater können diese API hooken und Erfolg zurückgeben lassen
    • Dann glaubt der Anti-Cheat, dass das Verbergen erfolgreich gesetzt wurde, obwohl tatsächlich nichts passiert ist
  • TAC prüft das Ergebnis von Aufrufen mit ungültigen Argumenten, um schlecht gemachte Hooks zu erkennen
    • Ein Aufruf, der wegen eines falschen Längenarguments fehlschlagen müsste, wird erkannt, wenn er erfolgreich ist
    • Es gibt Beispiele für unterschiedliche Rückgabewerte in Debugger- und ScyllaHide-Umgebungen
    • Auch Hooks, die bei einer ThreadHideFromDebugger-Anfrage mit einem Fake-Handle immer Erfolg zurückgeben, werden geprüft

Blockieren der Erstellung von Remote-Threads

  • TAC installiert einen Exception-Handler, der bei einer STATUS_PRIVILEGED_INSTRUCTION-Exception TerminateThread für den aktuellen Thread aufruft
  • Manuell gemappte DLLs benötigen eine Möglichkeit, shellcode in einem Remote-Prozess auszuführen; eine verbreitete Methode ist CreateRemoteThread
  • TLS callbacks von Windows-PE-Dateien können beim Erstellen eines Threads vor dem Thread-Entry-Point aufgerufen werden
  • TAC prüft im Kontext eines neuen Threads die Startadresse
    • Mit NtQueryInformationThread wird die Win32 start address geholt
    • Die Liste geladener Module wird durchlaufen, um zu prüfen, ob die Startadresse im Bereich eines regulären Moduls liegt
  • Liegt die Startadresse in keinem Bereich eines geladenen Moduls, wird die Erkennung gespeichert und eine privileged-instruction-Exception ausgelöst, um den betreffenden Thread zu beenden

Weitere Prüfungen und Fazit

  • Es gibt unbekannten Prüfcode, der kontrolliert, ob AllocationGranularity von NtQuerySystemInformation 0x10000 ist
    • Dies scheint virtuelle Maschinen oder angepasste Windows-Versionen zu flaggen
  • TAC hängt stark von der Liste verknüpfter Module ab und prüft daher, ob InMemoryOrderModuleList im PEB leer ist
    • Eine leere Liste zu erzeugen, würde wahrscheinlich den Prozess selbst beschädigen
  • Insgesamt ist TAC ein User-Mode-Anti-Cheat mit folgenden Funktionen
    • Runtime-API-Lookup
    • Erkennung schlecht gemachter Hooks
    • Erkennung externer Overlays
    • Erkennung interner DirectX-Hooks
    • Prüfung von Hooks auf verwendete APIs
    • Prüfung auf Debugger und Debugging-Spuren
    • Erkennung von AllocConsole
    • Erkennung von CreateRemoteThread
    • spoofed und verschlüsselte Syscall-Stubs
  • Arxan unterstützt TAC mit starker Obfuskation, Erschwerung statischer Analyse, Techniken, die IDA Pro aus dem Tritt bringen, Überwachung von .text-Änderungen und eigenen Anti-Debugging-Funktionen
  • TAC-ähnlicher Code wird auch in modernen Call-of-Duty-Spielen verwendet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-21
Meinungen auf Hacker News

  • 2021 bekam ich auf meinem Linux-CS:GO-Account Probleme mit dem Trust-Factor: Er fiel erst auf Gelb, später auf Rot. Es war keine offizielle Sperre, wirkte aber praktisch wie eine Sanktion.
    In der Folge wurde ich ständig mit Cheatern gematcht, sodass es schwierig war, Mitspieler zu finden.
    Später stellte ich fest, dass andere Linux-Nutzer mit Radeon-GPUs und mindestens 16 GB VRAM ähnliche Probleme hatten, und erstellte zur Nachverfolgung ein GitHub-Issue: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
    Bei der Untersuchung sah es so aus, als würde Valve Linux-Nutzer mit bestimmten Hardwarekonfigurationen sanktionieren, insbesondere mit damals recht neuen Radeon-Karten mit mindestens 16 GB VRAM.
    Am Ende wurde das Problem behoben, nachdem ein Nutzer gaben direkt kontaktiert hatte: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
    Ich vermute, dass Valve im Vorfeld des Steam-Deck-Launchs stärker auf die Linux-Nutzererfahrung achtete.

    • Vielleicht ist Gabe Newell einfach ein guter Mensch?
    • Mir ist nicht ganz klar, wie es die Linux-Nutzererfahrung verbessern soll, Linux-Nutzer zu sanktionieren.
      Interessant ist es trotzdem.
    • Ich frage mich, woher man wissen konnte, dass der Trust-Factor auf Gelb beziehungsweise Rot gefallen war.
      War das eine Vermutung wegen schlechterer Match-Qualität, oder gab es eine Möglichkeit, das zu überprüfen?
      Soweit ich es verstehe, ist der Trust-Factor verborgen, um Missbrauch zu verhindern.

  • Cheating ist am Ende ein menschliches Problem.
    Mit den im Artikel beschriebenen Schutzmaßnahmen und Heuristiken kann man zwar 90 % der offensichtlichen Cheater herausfiltern, und so ein Anti-Cheat ist grundsätzlich der richtige Weg.
    Anti-Cheat sollte jedoch konservativ arbeiten; letztlich müssen Spieler und Administratoren das Problem lösen.
    Online-Multiplayer-Spiele müssen zwingend auf Servern laufen, die von Menschen verwaltet werden, und während der meisten Zeit, in der Spieler verbunden sind, sollte ein Administrator anwesend sein.
    Wenn möglich, idealerweise ein Administrator, den die Spieler kennen; und wenn keiner da ist, sollten auch abgeschwächte Moderationsmittel wie Vote-Kick oder Vote-Ban möglich sein.
    Es gibt keinen grundlegenden Unterschied zwischen dem Entfernen von Cheatern und dem Entfernen von Leuten, die den Chat missbrauchen.
    Letztlich sind die einzigen praktikablen Serverformen für Online-Multiplayer-Spiele meiner Ansicht nach private Server oder Community-Server.
    Der Umgang mit Cheatern und Missbrauchstätern darf nicht über ein Meldesystem erfolgen, das asynchron abgearbeitet wird; Spieladministratoren müssen schnell kicken oder bannen können.
    Wenn Online-Spiel nur über Matchmaking-Server des Publishers möglich ist und der Umgang mit Cheatern oder Chat-Missbrauch nur aus Meldungen per Webformular besteht, sollte man solche Spiele nicht kaufen oder spielen, sondern mit dem Geldbeutel abstimmen.

    • Die Forderung, dass Online-Multiplayer-Spiele zwingend auf von Menschen verwalteten Servern laufen müssen, ist angesichts der Größenordnung ziemlich absurd.
    • Das klingt eher so, als wolle man für jedes Spiel einen für alle sichtbaren Schiedsrichter einsetzen und bei jedem Verstoß eine Videoüberprüfung durchführen lassen.
      Man könnte sogar noch eine eigene Organisation schaffen, die nur die Schiedsrichter überwacht, aber man kann auch einfach das Spiel spielen.
    • Ich verstehe nicht, warum menschliche Verwaltung die einzig mögliche Lösung sein soll.
      Apex Legends funktioniert mit einem starken Melde- und Anti-Cheat-System gut, und auch bei Rocket League arbeitet die weitgehend automatisierte Moderation effektiv.
    • Im Großen und Ganzen stimme ich zu, aber es gibt auch andere Ansätze.
      Möglich wären etwa Telefonnummern, manuelle Verifizierung per Foto, 10 Stunden Spielzeit vor Ranked-Matches, Empfehlungen anderer Spieler oder zusätzlich zu solchen Bedingungen ein einmaliger Game Pass für 5 Dollar.
      Falls du sie noch nicht gesehen hast: Ich empfehle Valves AI-Anti-Cheat-Präsentation.
      Die Arbeit ist ziemlich interessant, und sie behaupten, 99 % der Cheater zu erwischen.
      Natürlich gibt es weiterhin sehr subtile Cheating-Methoden.

  • Ich habe einen zweijährigen Rechtsstreit geführt, um eine falsche permanente Sperre von Activision rückgängig zu machen, und Activision verlor, weil sie keinerlei Beweise für Cheating vorlegen konnten: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

    • Mir ist bei League of Legends genau dasselbe passiert.
      Ich habe nie gecheatet, wurde ohne Erklärung gesperrt, und obwohl ich regelmäßig drei Accounts spiele, wurden die anderen beiden nicht gesperrt.
      Der Kundensupport sagte immer nur: „Nach Prüfung ist die Sperre korrekt“, gab mir aber keinerlei Informationen darüber, was ich falsch gemacht haben sollte, damit ich es hätte ändern können.
      Ich besitze einige der seltensten Skins im Spiel, spiele seit 2009 mit Tausenden von Stunden und spiele nur ARAM; es ergibt keinen Sinn, dass ich in einem der lockersten Modi einen Account mit großem emotionalem Wert für Cheating aufs Spiel setzen würde.
      Nichts im Zusammenhang mit Spielen hat mich je mehr gestresst, und nur weil ein Bekannter aus der Branche intern nachsehen ließ, wurde die Sperre ohne Angabe von Gründen aufgehoben.
      Ich spiele zwar noch, aber fast jedes Mal denke ich an diese falsche Sperre, und League wird wohl das letzte kompetitive Multiplayer-Spiel sein, in das ich Zeit investiere.
      Ein Teil von mir will gar nicht mehr spielen, aus Angst, dass so etwas wieder passiert.
    • Ich wurde ebenfalls fälschlich dauerhaft gesperrt.
      Auf Konsolen ist Cheating fast unmöglich, ich habe ewig gebraucht, um im Ranked gerade einmal ein durchschnittliches Gold 1 zu erreichen, und ich hatte für keinerlei Verhalten je eine Warnung oder Meldung erhalten, wurde aber ohne Erklärung dauerhaft gesperrt.
      Statt wie der Autor zu kämpfen, habe ich beschlossen, nie wieder Geld für Activision-Produkte auszugeben, und ich finde, das sollten alle tun.
    • Die Stelle, dass jemand, wenn man im Spiel gut ist, das Profil ansieht, die Spielzeit prüft und dann sofort ein rotes Label „Ich bin ein Cheater“ sieht, lässt mich fragen, ob dieses Label als Verleumdung gelten könnte.
      In den USA wäre das vermutlich schwieriger, aber im Vereinigten Königreich beziehungsweise in England muss meines Wissens der Beklagte beweisen, dass die Aussage wahr ist.
    • Schrecklich, dass man so einen Kampf führen musste.
      Ich bin froh, dass ich kaum Multiplayer-Shooter spiele, und es wäre wirklich übel, meine riesige Steam-Bibliothek zu verlieren.
    • Allein dieser Artikel wäre schon eine eigene Einreichung wert und ist sehr interessant.

  • Jump-Obfuskation macht mich sehr neugierig
    Es wäre schön, wenn jemand antworten könnte, der mehr Reverse Engineering betrieben hat
    Ich frage mich, ob unbedingte Sprünge so häufig sind, dass sie sich nur schwer anhand bestimmter Vorbedingungen herausfiltern lassen, und ob es möglich wäre, da das Ende einer Funktion wegen des Returns leicht zu finden scheint, den Stack zu analysieren, herauszufinden, wohin die Funktion zurückkehrt, und dann den Call direkt vor der Rücksprungadresse zu suchen
    Da ich nicht viel x86-Assembler programmiert habe, könnte ich die Funktionsweise auch falsch verstanden haben

    • Es gibt elegante Techniken, mit denen man per symbolischer Ausführung in Emulatoren wie angr oder https://github.com/cea-sec/miasm Control-Flow-Graph-Flattening rückgängig machen kann
      Auch mit Intels PIN-Framework lassen sich interessante Analysen durchführen
      Hilfreiche Beiträge dazu gibt es hier: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
    • Unbedingte Sprünge sind sehr verbreitet, und x86-Assembler nach der Optimierung ist insgesamt ziemlich unübersichtlich
      Viele Funktionen enden nicht mit ret
    • Dieses Video, in dem Teile von Guitar Hero 3 per Reverse Engineering analysiert werden, könnte interessant sein, weil es ähnliche Techniken behandelt, die zur starken Obfuskation von Spielcode verwendet wurden: https://www.youtube.com/watch?v=A9U5wK_boYM
    • Es gibt einige häufige Probleme
      Manche Sprünge sind Fake, manche Sprünge landen mitten in Instruktionen
      Decompiler kommen nicht damit zurecht, wenn es an derselben Stelle zwei Instruktionen gibt
      Zum Beispiel indem man bei jmp 0x1234 den jmp-Opcode überspringt und 0x1234 als gültige Instruktion annimmt
      In manchen Branches ist der Stack kaputt, aber das kann beabsichtigt sein, um absichtlich eine Exception auszulösen
      Man kann also Instruktionen wie lea RAX, [rsp + 0x99999999999] durch nop ersetzen, um die Dekompilierung zu reparieren, könnte dabei aber auch eine beabsichtigte Exception übersehen
      IDA kommt damit nicht gut zurecht, deshalb nutze ich eine Binary-Ninja-Lizenz, und man kann leicht Skripte schreiben, die Funktionen für den Decompiler inlinen
      Meiner Ansicht nach kann IDA Code-Blöcke zwischen Sprüngen nur genau einer Funktion zuordnen und hat deshalb Schwierigkeiten, Situationen korrekt zu behandeln, in denen Sprünge Code-Blöcke gegenseitig wiederverwenden
      Binary Ninja scheint weniger genutzt zu werden, weil es bei Blizzard-Spielen einen Bug gab, der aber vor etwa einem Jahr durch einen Bug-Report behoben wurde
    • Diese konkreten Sprünge scheinen sich ziemlich leicht herausfiltern zu lassen
      Das ist Obfuskation, die gängige Standard-Tools, insbesondere Nutzer von IDA Pro, nerven soll
      Die meiste Obfuskation zielt nur darauf ab, Leute so weit zu nerven, dass sie zu anderen Projekten wechseln

  • Dass einem nach dem Verkauf Produktfunktionen entzogen werden, sollte gesetzlich verhindert werden, selbst wenn es im Vertrag oder in der EULA steht
    Eine Sperre darf nicht den Besitz des Spiels selbst entziehen, und wenn doch, muss erstattet werden
    Wenn erst ein Urteil nötig ist, um eine Erstattung zu erzwingen, sollte es zusätzlich zu Lizenzkosten, Anwaltskosten und Gerichtskosten auch dreifachen Schadensersatz geben
    Zum Beispiel sollte es rechtlich unmöglich sein, auf Steam gesperrt zu werden und dadurch alle Käufe ungültig zu machen
    Selbst wenn die Kontoanmeldung blockiert wird, sollten Items und Inventar handelbar bleiben, weil zahlende Kunden dafür tatsächlich Zeit investiert haben
    Wenn man in Multiplayer-Spielen Verhaltensregeln durchsetzen will, darf man entweder kein Geld für das Spiel verlangen, oder zahlende Nutzer müssen Rechte in Bezug auf Sperren haben
    Sperren müssen dem Grundsatz der Verhältnismäßigkeit folgen, es muss ein Berufungsverfahren mit menschlicher Beteiligung und Aktenlage geben, dessen Kosten auf den Lizenzpreis begrenzt sind und nur bei Unterliegen anfallen

    • Wegen Cheating wird man nicht von Steam gesperrt
      Im schlimmsten Fall bekommt das Konto bei VAC-Spielen eine öffentliche Schandmarkierung
      Menschen spielen Multiplayer-Spiele, um Spaß zu haben und mit anderen zu interagieren; wenn also Cheating oder anderes Fehlverhalten andere beeinträchtigt, sollte die Nutzung des Multiplayer-Dienstes gesperrt werden
    • Ich sehe nicht, was daran anders ist als zu schnell zu fahren
      Wenn man der Gesellschaft zur Last fällt, zahlt man den Preis dafür; das ist ein ziemlich allgemeines Prinzip
    • Ich finde es in Ordnung, wenn Cheater es ordentlich abbekommen
      Meiner Meinung nach dürfen sie auch echtes Geld verlieren
      Versehentliche Sperren sind allerdings ein anderes Problem
      Und gesperrt wird doch nicht das gesamte Steam-Konto, sondern das jeweilige Spiel, das man dann nicht mehr spielen kann, oder?
    • Man könnte ihnen stattdessen einfach das Label Cheater geben und sie nur noch mit anderen Cheatern spielen lassen
    • Wenn man cheatet oder anderen Spielern das Spiel ruiniert, verdient man es, den Zugriff zu verlieren
      Die anderen Spieler haben schließlich auch bezahlt

  • In COD muss man eigentlich gar nicht cheaten
    Es gibt so viele Bugs, dass das Spiel das für einen übernimmt
    Im Ranked-Modus lädt es manchmal eine Waffe statt eines Messers; offenbar gibt es in der Prüfung der Ranked-Waffenausrüstung ein eindeutig falsches case oder if-else, wodurch das möglich ist, und wenn die im Ausrüstungswähler angezeigte Waffe nicht erlaubt ist, scheint standardmäßig die XM4 gewählt zu werden
    Es ist fast das einzige Spiel, das ich kenne, bei dem die Ranked-Version kaputter ist als die Casual-Version

  • Ich frage mich, wo man so etwas lernt.
    Ich würde gern mehr lernen, wenigstens genug, um die Hälfte des Artikels zu verstehen, weiß aber nicht, wo ich anfangen soll.

    • Vor etwa 15 Jahren habe ich viel gelernt, indem ich Eldad Eilams Reversing: Secrets of Reverse Engineering gelesen habe.
      Das Buch ist alt, aber hervorragend, und führt einen durch verschiedene Techniken und Übungen.
      Die modernen Tools haben sich seitdem etwas verändert, aber der x86-Befehlssatz und Assembly im Allgemeinen haben sich nicht grundlegend geändert.
      Einer der größten Gewinne war für mich, crackme kennenzulernen.
      Das sind kleine Challenge-Binaries, die zum Lernen von Reverse Engineering gemacht sind, so etwas wie Übungsschlösser in der Lockpicking-Community.
      Soweit ich mich erinnere, lagen dem Buch mehrere davon auf CD-ROM bei, und online findet man ebenfalls viele.
      Solche Übungen selbst zu machen, ist der Weg, es zu lernen.
      Man sollte nicht gleich versuchen, COD reverse zu engineeren, sondern es Schritt für Schritt aufbauen.
    • Früher habe ich mit den Lena151-Tutorials angefangen: https://github.com/kosmokato/Lena151
    • Früher hätte ich gesagt: Geh zu Gamedeception und häng dort herum, aber es scheint vor ein paar Jahren verschwunden zu sein.
      Grüße an alle, die UnknownCheats, cs.rin.ru usw. gelesen haben.
    • UnknownCheats ist einer der besten Orte für Material dieser Art.
      Ich bin dort auch aktiv und interessiere mich besonders für Anti-Cheat im Linux-Userspace, insbesondere dafür, wie VAC funktioniert.
    • https://pwn.college ist hervorragendes Lehrmaterial.

  • Ich habe ein beliebtes Horde/Alliance-basiertes MMO ein wenig reverse engineered, und es folgte fast denselben Schritten, einschließlich FNV32-Export-Hashes.
    Weil ich gesehen habe, dass sehr ähnliche Tricks verwendet werden, wirkt es fast wie derselbe Ansatz.
    Ich frage mich, ob es mit derselben Schutztechnik gepackt wurde.

    • Die Source-2-Engine verwendet ebenfalls fnv zum Hashen von Schemas, also Entity-Properties.
    • Wenn sie Warden nach der Fusion für Activision-IP wiederverwendet haben, ergibt das Sinn.

  • Signature Scanning ist wirklich mächtig.
    Für mich ist es auch einer der süchtig machendsten Teile des Reverse Engineering.
    Es macht Spaß, eine Liste von Signaturen zu erstellen und Bindings für eine Skriptsprache zu schreiben, damit man diese Funktionszeiger aufrufen kann.
    Das ist auch die Grundlage vieler Third-Party-Modding-Plattformen, weil sie Moddern sinnvolle APIs bereitstellen müssen, die der First-Party-Entwickler nicht freigelegt hat.

    • Ich weiß nicht, was Signature Scanning ist, habe aber für Interessierte eine Quelle gefunden: https://www.unknowncheats.me/forum/general-programming-and-r...
    • Genau.
      Soweit ich weiß, nutzen einige Source-Engine-Plugins diese Methode bei Bedarf ebenfalls.
      Allerdings scheinen die meisten stattdessen Offsets von Pointern auf virtuelle Funktionstabellen zu verwenden.

  • Ich frage mich, ob es möglich oder sinnvoll wäre, den Spielzustand regelmäßig digital zu signieren oder irgendeinen Proof of Work einzubauen, um Cheating zu verhindern.
    Mir wird allmählich klar, dass Cheating ein extrem schwer zu verhinderndes Problem ist.
    Ich entwickle einen kleinen, günstigen Online-FPS und denke eher daran, die Nutzer einander vertrauen und Cheater selbst finden zu lassen, oder wie Valve AI einzusetzen, statt Anti-Cheat-Software einzubauen.
    Vermutlich werde ich Spieler ihre eigenen Server verwalten und betreiben lassen.
    Man könnte Bedingungen wie das Verknüpfen einer Telefonnummer, Reputationspunkte von anderen Spielern, Ausweis oder andere starke Authentifizierungsmethoden, manuelle Verifizierung per Foto wie bei Dating-Apps oder 10 Stunden Spielzeit vor Ranked-Matches einführen.
    Ich denke, Hardcore-Spieler würden solche Verfahren gern durchlaufen, um die Zahl der Cheater zu verringern.

    • Wenn man einigermaßen viel Online-Games gespielt hat, weiß man, dass Spieler schon bei sehr wenigen Belegen unaufhörlich Cheating-Vorwürfe erheben.
      Dazu kommt sozialer Missbrauch, bei dem man Spieler meldet, die man nicht mag, um sie sperren zu lassen.
      In so einem System gäbe es weit mehr False Positives als bei jedem Anti-Cheat.
    • Auf hoher Ebene betrachtet könnte man ein cheatfreies Spiel simulieren, dieses signieren und Cheats separat behandeln.