CSGO-Cheater mit IdentityLogger ausgebremst

• Invex Gaming betrieb von 2014 bis 2019 in Australien und Neuseeland basierte CSGO-Community-Server; durch wiederholte Ban-Umgehungen wuchs die Belastung für Administratoren durch manuelle Demo-Prüfungen
• Bisherige Bans verfolgten IP-Adresse und Steam ID gemeinsam, doch wenn Cheater beides gleichzeitig änderten, konnte der Server nur schwer erkennen, ob es sich um denselben Spieler handelte
• IdentityLogger nutzte persistente Cookies des in CSGO eingebauten VGUI-Browsers, um eine Tracking ID zu speichern, und verwendete IP-Adresse, Steam ID und Tracking ID gemeinsam als Fingerprint
• Nach der Einführung auf allen Servern im Februar 2017 wurden auch Spieler, die sowohl Steam ID als auch IP-Adresse geändert hatten, über die Tracking ID wiedererkannt und sofort gesperrt
• Diese Methode funktionierte, bis Valve im Oktober 2017 zur Verbesserung der Sicherheit den VGUI-Browser entfernte; anschließend wurden die Technik und das Plugin veröffentlicht

---

Betrieb von Invex Gaming und der Aufwand im Kampf gegen Cheater

• Invex Gaming war ein von 2014 bis 2019 betriebener, in Australien und Neuseeland basierter CSGO-Community-Server
• Der Betrieb umfasste ein breites Spektrum: Pflege von Forum und Server-Infrastruktur, Kosten- und Sponsoring-Management, Hinzufügen von Spielermodellen, Korrektur von Hitboxen, Automatisierung des VIP-Systems, Schreiben eigener Plugins, Patchen von Game-Exploits und Bugs, DDoS-Abwehr sowie Bearbeitung von Meldungen
• Am langweiligsten und kräftezehrendsten war dabei die wiederholte Identifizierung und Sperrung von Cheatern
• Für die automatische Erkennung gab es serverseitigen Code und Methoden wie Valve Anti-Cheat, doch wegen des ständigen Hin und Hers zwischen Cheat-Entwicklern und Anti-Cheat-Entwicklern war es schwierig, alle Cheats automatisch zu erkennen
• Als letztes Mittel blieb schließlich die manuelle Analyse von CSGO-Demos, bei der Administratoren selbst beurteilen mussten, ob ein Spieler cheatete

Wo Bans über IP-Adresse und Steam ID scheitern

• Übliche Bans funktionieren, indem identifizierbare Informationen gespeichert werden, um den Zugriff auf einen Dienst zu verhindern
• Die Server von Invex Gaming nutzten hauptsächlich zwei Identifikatoren
  • IP-Adresse: eine vom ISP oder Serveranbieter vergebene Internetkennung
  • Steam ID: eine eindeutige, an ein Steam-Konto gebundene Kennung
• Wurde ein Spieler gesperrt, wurden IP-Adresse und Steam ID in der Ban-Liste gespeichert; meldete er sich später mit derselben IP-Adresse oder Steam ID an, wurde er vom Server geworfen
• Kam jemand nur mit geänderter Steam ID, aber derselben IP-Adresse zurück, konnte die neue Steam ID dem bestehenden Ban zugeordnet und erneut gesperrt werden
• Auch wenn nur die IP-Adresse geändert und dieselbe Steam ID verwendet wurde, wurde die neue IP-Adresse mit dem bestehenden Ban verknüpft
• Das Problem entstand, wenn Cheater Steam ID und IP-Adresse gleichzeitig austauschten
  • Aus Sicht des Servers war es eine bisher unbekannte Kombination aus IP-Adresse und Steam ID
  • Es gab keine Möglichkeit, sie mit einem bestehenden Ban zu verknüpfen, sodass sie wieder spielen konnten
  • Selbst nach einer erneuten Sperre konnten sie beide Identifikatoren gemeinsam ändern und den Ban umgehen
• Auch das Pflegen von Listen beliebter VPNs und zugehöriger IP-Adressen wurde geprüft, war dem Betriebsteam wegen des dauerhaften Wartungsaufwands aber nicht sympathisch
• Eine spätere Analyse zeigte, dass der berüchtigtste Cheater Zugriff auf geografisch verteilte IP-Adressen und mehr als 87 Steam-Konten mit gekauftem CSGO hatte

Fehlalarmrisiken durch IP-Adress-Fingerprints

• Die Steam ID identifiziert einen Spieler eindeutig, eine IP-Adresse ist jedoch kein eindeutiger Identifikator
• Wenn zwei Geschwister im selben Haushalt auf den Server zugriffen und nur eines cheatete, konnten durch dieselbe IP-Adresse die Fingerprints beider Personen miteinander verknüpft werden, sodass beide gesperrt wurden
• Auch in gemeinsam genutzten Netzwerken, etwa an Universitäten, in denen sämtlicher ausgehender Traffic über eine einzige IP-Adresse läuft, gab es Probleme
  • Eine Person wurde im Campus-Netzwerk wegen Cheatens gesperrt
  • Dadurch konnten auch die Steam ID und die Heim-IP-Adresse anderer Spieler im selben Netzwerk verknüpft und zu Unrecht gesperrt werden
• Invex Gaming entwickelte für solche seltenen Fälle ein Ausnahmesystem und riet dazu, nicht in nicht vertrauenswürdigen Netzwerken zu spielen

VGUI-Browser-Cookies als dritter Identifikator

• Anfang 2017 verschärfte sich das Problem der Ban-Umgehung auf den Servern deutlich, sodass Administratoren weiterhin Demos manuell prüfen mussten
• Die Kernaufgabe bestand darin, denselben Spieler auch dann zu erkennen, wenn Steam ID und IP-Adresse gleichzeitig wechselten
• CSGO verfügte über einen eingebauten In-Game-Webbrowser, mit dem Serverbetreiber beim Verbinden eine MOTD anzeigen konnten; dieser wurde VGUI-Browser genannt
• Der VGUI-Browser erlaubte Serverbetreibern, beliebige Websites auf dem Bildschirm des Spielers zu öffnen, und das Fenster konnte auch versteckt werden
• Dieser Browser war mit Steam-Cookies vorab authentifiziert und konnte automatisch bei Steam-Domains eingeloggt sein; außerdem erlaubte er die clientseitige Ausführung von JavaScript, das vom Serverbetreiber ausgeliefert wurde
• Der Kern von IdentityLogger war, dass der VGUI-Browser Cookies unterstützte und diese auch über Sitzungen hinweg erhalten blieben
  • Tests zeigten, dass über den VGUI-Browser gespeicherte Cookies auch nach dem Beenden und Neustarten von CSGO erhalten blieben
  • Es schien auch keine Begrenzung für das Ablaufdatum von Cookies zu geben; selbst Cookies mit Ablaufdaten von mehr als zehn Jahren ließen sich speichern
  • Die Cookie-Daten wurden in einer Datei im Steam-Installationsverzeichnis des Spielers gespeichert
• So konnte jedem Spieler ein dritter Identifikator namens Tracking ID zugewiesen werden
• Um wie ein neuer Spieler zu wirken, hätten Steam ID, IP-Adresse und Steam-Installationsordner gewechselt werden müssen; man ging davon aus, dass Spieler den Steam-Installationsordner nicht ändern würden

Implementierungsablauf von IdentityLogger

• IdentityLogger ist ein integriertes System, das Spieler anhand von IP-Adresse, Steam ID und Tracking ID fingerprintet
• Wenn ein Spieler dem Server beitritt, wird zunächst in der Datenbank eine Ban-Prüfung durchgeführt
  • Geprüft werden IP-Adresse, Steam ID und Tracking ID
  • Liegt ein bestehender Ban vor, wird der Spieler vom Server geworfen und neue Identifikatoren werden mit dem bestehenden Ban verknüpft
• Bei nicht gesperrten Spielern wird über ein verstecktes VGUI-Browser-Fenster eine geheime Webseite geöffnet
• Die Anfrage wurde mit einem geheimen Wert authentifiziert; VGUI-Browser-Anfragen entstehen zwar clientseitig, der Traffic wird jedoch per HTTPS verschlüsselt
• Ein PHP-Skript prüft, ob bereits ein Tracking-ID-Cookie vorhanden ist
  • Falls nicht, wird eine neue Tracking ID erzeugt und gespeichert
  • Die Tracking ID ist eine 64 Zeichen lange zufällige alphanumerische Zeichenkette wie TeStsCOhZO1TQsumJkDUOdMMo13ReRLEngrQTg7S49LKT2rBvgPhauzSYbegscOT
  • Das Cookie wird letztlich in der Datei vgui.browser.cookies.dat im Steam-Installationsverzeichnis des Spielers gespeichert
• Steam ID, IP-Adresse und Tracking ID werden jedes Mal in der Datenbank gespeichert, wenn ein Spieler dem Server beitritt
• Diese Datenbank wurde in ein Webpanel integriert, mit dem Administratoren Spieler-Fingerprints untersuchten, sowie in ein modifiziertes SourceBans-Plugin auf Basis einer Ban-Management-Software für Source-basierte Spiele

Wie Ban-Umgehung verhindert wird

• Wenn sich ein Spieler zum Beispiel erstmals mit der IP-Adresse 198.51.100.1 und der Steam ID STEAM_1:1:1111 verbindet, wird eine neue Tracking ID erzeugt
• Wird dieser Spieler wegen Cheatens gesperrt, landen IP-Adresse, Steam ID und Tracking ID gemeinsam in der Ban-Datenbank
• Verbindet sich derselbe Spieler später mit der IP-Adresse 100.64.50.74 und der Steam ID STEAM_1:1:3333, bestehen die neue IP-Adresse und die neue Steam ID die Ban-Prüfung
• Die bereits gespeicherte Tracking ID ist jedoch mit dem früheren Ban verknüpft, sodass die Ban-Prüfung fehlschlägt
• Das System sperrt den Spieler sofort erneut und verknüpft die neue IP-Adresse und die neue Steam ID mit dem bestehenden Ban
• Danach wird dieser Spieler unabhängig von verwendeter IP-Adresse oder Steam ID wegen derselben Tracking ID direkt beim Verbinden gesperrt

Ergebnisse der Einführung 2017 und Veröffentlichung

• Nach Tests führte Invex Gaming IdentityLogger im Februar 2017 auf allen CSGO-Servern ein
• Direkt nach der Einführung stieg die Zahl der Cheater-Bans deutlich
• Es stellte sich heraus, dass auch einige langjährige und vertrauenswürdige Community-Mitglieder auf geheimen Konten gecheatet hatten
• Manche Cheater fragten direkt nach, warum sie trotz geänderter Steam ID und IP-Adresse als Ban-Umgeher erkannt worden waren
• Auch andere Serverbetreiber zeigten Interesse an dem Plugin, einige boten sogar Geld dafür
• Da sich die Methode bei breiter Bekanntheit schon durch das Löschen der Cookie-Datei hätte umgehen lassen, blieb die Implementierung innerhalb des Administratorenteams geheim
• Die Methode funktionierte bis Oktober 2017, als Valve im Zuge der Verbesserung der Spielsicherheit den VGUI-Browser vollständig entfernte
• Nach der Entfernung des VGUI-Browsers wurde die Technik offengelegt und das Plugin als Open Source veröffentlicht

[GN⁺]

Meinungen auf Hacker News

• In UT2004 kann man Spieler zwar über die GUID (Hash des CD-Keys) oder die IP sperren, aber nachdem Epic das Spiel sich selbst überlassen hat, sind viele Key-Generatoren aufgetaucht, wodurch GUID-Sperren wirkungslos wurden. Und heute bekommt man VPNs schon für 2 Dollar, sodass auch IP-Sperren stark begrenzt sind.
  Die wichtigste Lösung, die wir derzeit nutzen, ist neben IP-Sperren, alle bekannten VPN-Subnetz-Datenbanken in die Firewall einzupflegen und so VPN-Sperren umzusetzen, außerdem eine ähnliche Fingerprinting-Technik, die bestimmte Systemordnerstrukturen durchsucht.

  • Wenn „IP-Sperren wegen VPNs begrenzt sind“, dann wurde https://redman.xyz/doku.php/schachtmeister2 genau dafür gebaut, solche Leute auszusperren.
    Es entstand für Tremulous (einen ioquake3-Fork), weil Leute IP-Sperren ständig umgangen haben, lässt sich aber auch für andere Spiele verwenden. Es ist nicht mein Projekt, aber ich kenne den Autor, und wenn Bedarf besteht, könnte man es für ein bestimmtes Spiel oder allgemein passend forken und anpassen.
    In schachtmeister2 kann man auch Heuristiken wie whois -10 "Hosting", whois -13 "VPN", whois +7 "residential" verwenden.
    Nachtrag: Ich habe den Administrator kontaktiert, nachdem ich gesehen habe, dass das Git-Repository 502 zurückgibt.
  • Ich würde gern bei der Wartung von UT2004 helfen. Ich liebe dieses Spiel wirklich.
    Online spiele ich nicht mehr, weil ich vom Skill her nicht mehr mithalten kann, aber wenn ich etwa 30 Minuten übrig habe und schnell eine Runde gegen die KI spiele, macht es immer noch Spaß.
  • Auf einem Counter-Strike-1.6-Server, bei dessen Betrieb ich helfe, tauchen gelegentlich ebenfalls Cheater auf. Überraschend oft sind es „Ragehacks“, bei denen sie gar nicht versuchen, es zu verbergen, etwa No-Scope-Scharfschützen-Headshots mitten in der Luft.
    Der Serverbesitzer erlaubt Verbindungen von Non-Steam-Accounts (Raubkopien), daher können wir uns nicht wie bei Unreals GUID auf SteamID-Sperren verlassen. Eine gefälschte ID zu ändern ist zwar etwas umständlich, weil sie irgendwo tief im Installationsordner liegt, aber möglich ist es. In Nordafrika, im ehemaligen Baltikum und den umliegenden Regionen sowie in Nord- und Westasien ist das Spiel ziemlich beliebt; ohne diese Spieler wäre der Server leer.
    Also nutzen wir Zuckerbrot und Peitsche. Steam-Spieler bekommen nahezu sofortiges Nachladen, sind von einigen aggressiven automatischen Admin-/Kick-Funktionen ausgenommen und erhalten reservierte Nicknames sowie ein „VIP“-Tag. Für den Preis einiger VPN-Keys bekommt man damit legitime Vorteile und den Besitz des Spiels, und die Einmalzahlung geht direkt an den Entwickler. Oder man kann es auch kostenlos bekommen, wenn man fünf Wochen lang jede Woche mindestens ein Spiel spielt und das Admin-Team über Social Media kontaktiert.
    Auf der Peitschen-Seite kicken oder sperren wir nicht einfach, sondern machen es absichtlich lästig, um zu zeigen, dass sie wirklich nicht willkommen sind, sodass sie nicht wiederkommen wollen. Zum Beispiel entwaffnen und ihnen die schlechteste Waffe geben, sie zufällig außerhalb der Map oder im Boden feststeckend teleportieren, mit wiederholtem amx_rocket ein Feuerwerk erzeugen, mit amx_drug den Blickwinkel maximal erhöhen und einen Rauscheffekt geben oder sie als schlechten Loser verspotten, der nur Spaß hat, wenn eine KI für ihn spielt.
    Es gibt auch amx-Plugins und Befehle, die als „illegal“ gelten. Normalerweise meidet man sie, weil sie sehr leicht missbraucht werden können, aber in solchen Situationen sind sie nützlich. Besonders amx_exec ist ziemlich beängstigend, weil es Admins direkten Zugriff auf die In-Game-Konsole des Clients gibt und beliebige Befehle oder Einstellungen ausführen lässt.
    Mit Befehlen wie rate 1000, name iCaNtAiM, unbind all, bind y quit, fps_max 50 kann man zum Beispiel die Netzwerkgeschwindigkeit ruinieren, den Namen ändern, alle Keybindings löschen, die Standard-Chat-Taste mit dem Beenden des Spiels belegen und die maximale FPS-Zahl so weit senken, dass es nicht sofort auffällt, aber nervt. Die Standardwerte lassen sich durch Löschen der Konfigurationsdatei leicht wiederherstellen, aber ohne Backup der Einstellungen kann das sehr frustrierend sein.
    Interessanterweise verkaufen viele Server VIP-Vorteile für bis zu 20 Dollar im Monat. Anfangs war ich schockiert, aber dann habe ich erfahren, dass es eine Art schattiges Kartell gibt, bei dem man recht viel bezahlen muss, um in Drittanbieter-Serverbrowsern an einer brauchbaren Position sichtbar zu sein, und dass ein erheblicher Teil der Einnahmen für „Boosts“ ausgegeben wird.
    Als unser Serverbesitzer zwei Monate lang aufgehört hat, für „Boosts“ zu zahlen, fiel die durchschnittliche Spielerzahl von 14/32 auf 3/32, und die maximale Auslastung, die an Wochenenden normalerweise bis 28/32 ging, lag an einem Freitagabend mit Glück noch bei 12/32. Sobald er wieder zahlte, sprang die Spielerzahl nach oben; das Verrückte daran ist, dass es 180 Dollar im Monat kostet.
    Bevor ich am Betrieb beteiligt war, dachte ich, ein unterhaltsamer Deathmatch-Modus, gute Moderation, niedrige Latenz, ein leistungsstarker Server und eine Exklusiv-Remake/-Remix-Version der zweitbeliebtesten Map des Spiels würden reichen, um beliebt zu sein. Aber offenbar muss man den bestehenden Gatekeepern überhöhte Gebühren zahlen, um für die meisten Spieler sichtbar zu sein.
  • Ich verstehe nicht, warum das Sperren von Cheatern so ein Problem ist. Sperrt sie nicht, sondern markiert sie im Hintergrund als Cheater und lasst sie nur noch auf Cheater-only-Server. Dann hören sie schnell auf.
    Das ist ähnlich wie Web-Scrapern mitzuteilen, dass ihre IP gesperrt wurde: Mit so einer Strategie gewinnt man nichts. Besser ist es, Scraper-IPs im Hintergrund zu markieren und ihnen nur noch Müll-Daten zu liefern, die zufällig in die Seite eingemischt sind.
    Bei Cheat-Erkennung sehe ich es genauso. Wenn man sperrt, verliert man nur den strategischen Vorteil, und das Wechseln von IP, CD-Key oder Account ist für Cheater nur eine kleine Unannehmlichkeit.
  • Diese Methode wird von Cheatern, die Mobile-Data-Tethering und Proxys verwenden, weiterhin umgangen. Ich frage mich, ob ihr fortgeschrittenere Netzwerkanalyse in Betracht gezogen habt.
    Das ist beruflich wie privat ein Feld, das mich interessiert; falls ihr Vorschläge braucht, kann ich helfen.

• Mir gefällt, dass der Autor als Beispiel-IPv4-Adresse die TEST-NET-2-Adresse aus RFC5737 verwendet hat: „An example of an IPv4 IP address is 198.51.100.1.“
  https://www.rfc-editor.org/rfc/rfc5737

  • Ich mag es sehr, für Beispiele reservierte Bezeichner zu verwenden. In Dokumentationen nutze ich immer TEST-NET-2-IPs und example.com.
  • Interessant wird es, wenn Dokumentation reservierte Adressen mit Tippfehlern verwendet. Zum Beispiel 189.51.100.1 oder 198.15.100.1; tatsächlich gibt es mehrere RFCs mit solchen Fehlern.

• Irgendwann in meiner Karriere möchte ich mich unbedingt mit rein serverseitigem Anti-Cheat beschäftigen. Dieses feindliche Wettrüsten wirkt, als wäre es wirklich spannend, lange und gründlich darüber nachzudenken.

  • Das Problem ist, dass viele Unternehmen die Kosten dafür nicht tragen wollen. Es ist „Tretmühlenarbeit“: Egal wie viele Leute und wie viel Geld man hineinsteckt, am Ende kommt es wieder zurück.
    Weil es viel mehr Spieler als Entwickler gibt, ist das ein verlorener Kampf.
  • Das ist der Bereich, in dem ich gerade arbeite. Das eigentliche Problem ist, dass es hohe Performance-Kosten verursacht, wenn man alle wichtigen Abläufe auf dem Server erledigen will, und Entwickler faul geworden sind und zu viel Arbeit auf den Client abgeschoben haben, bis sich das wie ein Standard verfestigt hat.
    Alle wichtigen Aktionen auf den Server zu verlagern, ist weder einfach noch billig, aber es ist eine umfassendere Methode, Cheats zu verhindern.
    Wenn man dazu noch ein Spiel mit viel Physik, 120 Tickrate (nach weiteren Tests vielleicht noch höher), präziser steuerungsbasierter Action-Kampfmechanik und dem Ziel, auf MMORPG-Größe zu skalieren, nimmt, wird es wirklich schwierig.
  • Der Stand der Technik ist ziemlich langweilig, und User-Command-Payloads kann man an einem Nachmittag lernen.
    Inzwischen gibt es YOLO-basierte Aimbots, wodurch die Welt deutlich komplizierter geworden ist, und die realistische Schlussfolgerung ist, dass Anti-Cheat am Ende geknackt werden kann.
    Auf Client-Seite kann man ein privates Binary erstellen, dessen Hash bei den großen Anti-Cheat-Diensten nicht registriert ist, und auf Server-Seite sieht man nur das, was nach den Spielregeln erlaubt ist.
    Es gibt keinen Mechanismus, um übermenschliche Reaktionszeiten zu verhindern, und wahrscheinlich sollte es auch keinen geben; damit wird das Problem nicht mehr lösbar.
    Deshalb braucht es Community-Urteile, aber auch das ist langweilig. Dass gute Spieler in Counter-Strike als Cheater beschuldigt werden, ist ein altes und zugleich interessantes Problem.
  • Diese Arbeit verbessert auch das Leben der Leute ziemlich stark. Ganze Online-Spiele können durch Cheater zu Niemandsland werden.
    Vor ein paar Jahren habe ich mehrere Battlefield-Spiele gekauft, aber einige waren wegen Speedhack- und Aimbot-Cheatern unspielbar. Es wirkte, als ließe sich das serverseitig leicht erkennen, und ich fragte mich, warum niemand etwas dagegen tut.
  • Ich habe das nur bei Minecraft gemacht, aber es war ziemlich unterhaltsam.

• Wenn die Website down oder langsam ist und man den Artikel lesen möchte, gibt es einen Screenshot der ganzen Seite: https://i.imgur.com/SPp6IHX.jpeg
  Ich hätte nicht gedacht, dass der Artikel so viel Traffic bekommt.

• In diesem Artikel geht es nicht darum, Cheater zu stoppen, also nicht um Cheat-Erkennung, sondern darum, Ban-Umgehung zu verhindern, bei der gebannte Cheater immer wieder zurückkommen.
  Gerade heute, wo es sogar Hardware-Cheats wie DMA gibt, ist Cheat-Erkennung ein völlig anderes Spiel. Persönlich halte ich eine der wirksamsten Methoden gegen Ban-Umgeher darin, für das Spiel tatsächlich Geld zu verlangen.

  • Zur Zeit des Vorfalls im Blog war CS:GO nicht kostenlos, und trotzdem gab es Cheater, die offenbar Zugriff auf mehr als 80 Accounts hatten.
  • Cheater sind nicht preissensibel. In einem kleinen Kiddie-Pool den König zu spielen, ist ihre bevorzugte Unterhaltung, daher kümmert es sie nicht, jeden Monat 60 Dollar für neue Accounts oder Game-Keys auszugeben.
    CS:GO-Leute stört es kaum, wenn ein Account mit Skins im Wert von Hunderten Dollar gebannt wird. Entweder haben sie den gestohlenen Account eines anderen für etwa 5 Dollar gekauft, oder sie zahlen ohnehin 30 Dollar im Monat für einen Cheat-Service.
    Zwischen regelmäßigen Cheatern und Pay-to-win-Walen dürfte es eine riesige Überschneidung geben.
    Eine verlässlichere Methode, Cheater in einem Spiel zu reduzieren, ist ein Cheater-Honeypot. Statt Cheater zu bannen und sie nach dem Kauf eines neuen Accounts erneut zu verfolgen, steckt man sie stillschweigend nur noch in Matchmaking mit anderen Cheatern, absichtlich nervigen Bots, künstlicher Latenz und gelegentlich ignorierten Tasteneingaben.
    Wenn man ihnen den Spaß verdirbt, hören sie auf, das Spiel zu verderben. Dann dreht sich der Informationskrieg um: Um zu wissen, ob sie einen neuen Account kaufen müssen, müssen sie erst herausfinden, ob sie regelmäßig mit Cheatern oder Bots spielen.
  • Auch Bans auf TPM-Basis machen Umgehung ziemlich teuer. Ab diesem Punkt muss der Cheater ein neues Mainboard kaufen oder einen neuen TPM-Chip auf das Mainboard löten.
    Natürlich könnte irgendwann ein schlampiger Anbieter TPM-Schlüssel leaken, sodass Fälschungen möglich werden.

• Spieler aus großen Ländern übersehen leicht das Community-Gefühl, das es in kleineren Ländern gibt.
  Wenn es nur drei oder vier Server voll Leute gibt, die täglich spielen, lernt man sich schnell kennen, und das macht die Witze und den Spaß deutlich größer.

  • Ich habe dieses Gefühl ein wenig bei älteren Multiplayer-Spielen mit kleiner Spielerbasis erlebt.
    Das ist viel besser als Spiele mit Millionen Spielern, bei denen man jemanden, mit dem man eine Runde gespielt hat, nie wieder sieht. Aus demselben Grund mag ich auch Spiele mit von der Community betriebenen Servern.
  • Wer etwas älter ist, erinnert sich vielleicht daran, Server in Gamespy als Favoriten gespeichert zu haben.
    Man ist immer wieder auf dieselben Server gegangen, je nachdem, wer online war und vor allem wie gut die eigene Verbindung war.

• Die Methode „Wenn jemand mit einer anderen Steam-ID verbindet, aber eine bereits gebannte IP-Adresse nutzt, wird er wieder gebannt“ funktioniert nur so lange gut, bis man merkt, dass man wegen CGNAT und IP-Adress-Rotation unschuldige Spieler bestraft.
  Cheater wissen meist, wie sie ihren Router dazu bringen, eine neue IP anzufordern, und diese IP wird später jemand anderem zugewiesen.

  • Genau solche Fälle gab es tatsächlich, und wir haben sie jeweils einzeln geprüft, um Nutzer zu entbannen oder Ausnahmen zu erstellen.
    Allerdings war das ziemlich selten; über mehrere Monate hinweg wurden nur eine Handvoll Fälle gemeldet. Wäre der Server beliebter gewesen, wäre das viel häufiger passiert.
  • Im Abschnitt „Problematic cases of IP address fingerprinting“ des Artikels wurde dieses Problem behandelt.
  • In solchen Situationen hätte ich mich vermutlich auf geheime Cookies verlassen, um False Positives zu reduzieren.

• Wenn es heißt, „wir haben die Lösung und die Techniken nur mit einem anderen Serverbetreiber in Großbritannien geteilt, dem wir vollständig vertrauten“, dann waren das vermutlich wir.
  Am Ende haben wir es mit anderen Fingerprinting-Signalen kombiniert, aber der Ansatz über VGUI war überraschend effektiv. Ich meine, der Webbrowser wurde um 2018 herum entfernt, was schade war. Man konnte damit benutzerdefinierte Skill-Trees oder unterhaltsame Integrationen bauen, die mit dem Server zusammenarbeiteten, und das war sehr mächtig.

• Dass „der Traffic selbst per HTTPS verschlüsselt ist, sodass man selbst mit Packet-Sniffing-Tools wie Wireshark keine Roh-Tokens finden kann“, stimmt nur bedingt: Wenn der eingebettete Browser den System-Proxy und die Liste der Systemzertifikate verwendet hat, ist es sehr einfach, HTTPS mit Tools wie Fiddler oder Burp Suite zu entschlüsseln.

  • Entscheidend ist, wie auffällig das Problem ist, wenn man Wireshark laufen lässt. Weil es nicht auffällt, braucht es deutlich mehr Arbeit, um herauszufinden, was tatsächlich passiert.
    Die Anfrage versteckt sich ganz unauffällig zwischen anderen Requests, und diese Requests sind erwartbar. Ein MOTD-Request ist normalerweise selbstverständlich und wirkt daher nicht verdächtig.
    In einer Situation, in der die Umgehung viel einfacher ist – etwa eine lokale Datei zu löschen –, hat das hier ausreichend gut funktioniert, statt den tatsächlichen Request zu finden und Fiddler oder Burp Suite einzurichten.
    Man muss es nicht übermäßig konstruieren.
  • Die Zielgruppe, die der Autor im Kopf hatte, waren vermutlich nicht HN-Leser, sondern durchschnittliche Script Kiddies.
  • In Firefox einen geheimen Schlüssel zu exportieren und in Wireshark zu importieren, ist ebenfalls ziemlich einfach.
    Das sind nur ein paar Klicks; je nach verwendetem TLS muss man es eventuell pro Verbindung machen, aber wirklich schwierig ist es nicht.

• „Man hätte es patentieren sollen“ ist natürlich als Witz gemeint, aber hätte man ein Patent angemeldet, hätte man die Technik offenlegen müssen, und sie wäre sofort nutzlos geworden.
  Trotzdem schmälert das den Artikel überhaupt nicht. Er war unterhaltsam zu lesen.