Hinweis:
Dieser Artikel ist sehr alt und gibt mit hoher Wahrscheinlichkeit nicht mehr meine heutige Meinung zu diesem Thema wieder. Aus Transparenzgründen (und weil das Internet sowieso nicht vergisst), lasse ich den Text dennoch online.
Dieser Artikel ist sehr alt und gibt mit hoher Wahrscheinlichkeit nicht mehr meine heutige Meinung zu diesem Thema wieder. Aus Transparenzgründen (und weil das Internet sowieso nicht vergisst), lasse ich den Text dennoch online.
Die Idee, den Netcode eines Spiels zu knacken, schwirrt schon länger herum. Sowohl gestandene Cheat-Coder, als auch Laien schlugen dies immer wieder über die Jahre hinweg vor.
Das Konzept klingt simpel. Die Daten, die über das Netzwerk bei einem Multiplayerspiel verschickt werden, werden „einfach“ abgefangen, entschlüsselt und die interessanten Informationen (z.B. „Wo befindet sich der Gegner?“) gefiltert und dargestellt. Der große Vorteil für Hacker ergibt sich daraus, dass man das Abfangen und Darstellen der Daten komplett unabhängig vom Spiele-PC vollziehen kann – sprich kein noch so gutes Anti-Cheat Tool wäre in der Lage auch nur die geringste Spur eines Hacks zu finden.
Bisher gab es jedoch für die „großen“ Spiele, wie CS 1.6, CS:S, Quake-Ableger, Battlefield-Ableger usw., nie wirklich ernsthafte und größere Versuche den Netcode zu knacken.
Für World of Warcraft wurde dies versucht, zwecks Steuerung von Farmbots, aber auch hier waren die Ergebnisse eher bescheiden.
… bis jetzt …
Vor ein paar Monaten haben sich zwei, in der Szene sehr bekannte, Cheatcoder erneut daran versucht und vor allem auch Vorzeigbares geliefert. Konkret handelt es sich bisher wohl um einen sogenannten Parser für den Counter-Strike 1.6 Netcode mit dazugehörigem Interface, welches die entschlüsselten und gefilterten Daten auf einer Overview-Grafik der Map darstellt (ähnlich wie im Spectatormodus von CS).
Ein Großteil des „Reverse Engineerings“, sprich Knacken, des Netcodes und die Programmierung des Parsers wurde von DeepBlueSea (u.a. bekannt für das Analysetool „HookShark“ und den ring0-Hack „Dreadnought“) vorgenommen. Das Interface kam von XEPT (u.a. bekannt für die neu geschriebene Version des Demoanalyse-Hacks „X-Spec“ und den ersten VOIP-Ligahack), welcher auch bei der Analyse half.
Wie bereits erwähnt liegt die Gefährlichkeit dieser Methode darin, dass (eine ordentliche Implementierung voraus gesetzt) kein Anti-Cheat Tool in der Lage wäre, es aktiv zu detecten, da sich auf dem Rechner, wo das Spiel und auch das AC-Tool läuft, kein noch so kleines Stück „böser Software“ befindet. Kein Loader, der irgendwann mal gestartet werden musste, kein Treiber, keine DLL-Dateien – nichts!
Es ließe sich auch am Datenstrom selbst nichts messen, da dieser in keinster Weise verändert werden muss – eine perfekte Man-In-The-Middle-Attacke.
Stattdessen muss man es sich in der Praxis so vorstellen, dass z.B. auf einem Router, der den Spiele-PC mit dem Internet verbindet und über den somit naturgemäß alle Daten fließen, ein Programm installiert wird, welches die Daten entweder direkt selbst entschlüsselt und filtert oder aber einfach nur die Daten kopiert und an ein Drittgerät weiter versendet. Unabhängig davon, wo die Daten geparst werden, fände die Darstellung immer auf einem Drittgerät statt. Dies kann ein zweiter Laptop/PC oder ein Smartphone sein – ähnlich wie beim „Android-Hack“. Als Visualisierung eignet sich der bereits erwähnte Mapoverview oder aber die klassische Radarhack-Darstellung.
Zusätzlich sei noch angemerkt, dass über diese Technik keine Aimbots oder klassische Wallhacks/ESPs, die direkt auf dem Spiele-Monitor angezeigt werden, möglich sind (Letzteres zumindest nicht ohne extremen Aufwand).
Vorerst scheint jedoch keine Gefahr von dieser neuen Art von Hack auszugehen!
Die beiden Programmierer sind mit anderen Dingen beschäftigt und hatten in der Vergangenheit wenig Interesse daran, ihre durchaus qualitativ hochwertigen Programme zu Geld zu machen, da es sich bei ihnen um klassische Hacker handelt und nicht um diese neue, profitorientierte Generation von „Hacksellern“.
Wenn überhaupt ist erst einmal nur mit der Veröffentlichung eines Proof of Concepts, ohne den Quellcode (da dies meist zu billigen Copy & Paste Private Hacks führt), zu rechnen. Ob es daraufhin eine ernsthafte Reaktion seitens Valve geben wird, bezweifle ich. Dafür hätten sie sich ein aktuelleres Spiel als Ziel herauspicken müssen, was sie jedoch nicht getan haben, da der Netcode von CS 1.6 z.T. noch auf der uralt Quake-Engine aus den 90ern besteht, welche Open Source und damit zugänglicher ist, als z.B. die neuere Source-Engine.
Die beiden Programmierer sind mit anderen Dingen beschäftigt und hatten in der Vergangenheit wenig Interesse daran, ihre durchaus qualitativ hochwertigen Programme zu Geld zu machen, da es sich bei ihnen um klassische Hacker handelt und nicht um diese neue, profitorientierte Generation von „Hacksellern“.
Wenn überhaupt ist erst einmal nur mit der Veröffentlichung eines Proof of Concepts, ohne den Quellcode (da dies meist zu billigen Copy & Paste Private Hacks führt), zu rechnen. Ob es daraufhin eine ernsthafte Reaktion seitens Valve geben wird, bezweifle ich. Dafür hätten sie sich ein aktuelleres Spiel als Ziel herauspicken müssen, was sie jedoch nicht getan haben, da der Netcode von CS 1.6 z.T. noch auf der uralt Quake-Engine aus den 90ern besteht, welche Open Source und damit zugänglicher ist, als z.B. die neuere Source-Engine.
Als Gegenmaßnahme bliebe überhaupt nur den Netcode aktiver und besser zu verschlüsseln, was Valve jedoch nicht tun wird, denke ich.
Hier wären nun die Anbieter von anderen Anti-Cheat Tools, wie EasyAntiCheat, Insight, Wire Anti-Cheat, X-Ray usw. gefragt.
Neben oberflächlicheren Lösungen würde sich eine tiefgreifende Modifikation der Game-Engine anbieten. Ein Schritt, an dem EAC meiner Meinung nach am nächsten dran ist.
Andererseits steht die treibende Kraft hinter Wire Anti-Cheat in relativ engem Kontakt zu DeepBlueSea und XEPT und konnte die Entwicklung teilweise wohl sogar live mitverfolgen. (So viel übrigens zu dem Mythos, dass Anti-Cheat-Coder und Cheat-Coder zutiefst verfeindet wären – bzw. nur ich so einen guten Draht gehabt hätte, weil ich insgeheim für die Gegenseite arbeite ...)
***UPDATE***
XEPT hat sich zu meinem Artikel geäußert:1. Gab es in der vergangenheit schon voll funktionstüchtige hacks, welche nur über das senden und empfangen von paketen funktionieren. Ein Beispiel dafür wäre der clientless bot bot diablo 2
2. Bei der man in the middle attsck muss auch nichts auf dem router installiert werden. Wäre irgendwo auch wieder detectbar.
3. Sehe ich den post über den hack eher kritisch. Du weißt was für einen nervigen hype der ssh kram ausgelöst hat. Außerdem hätte ich schon geen gesehen das des gesamte ding vis zu einem möglichen release auch unbekannt bleibt... aber gut, sei es drum.
4. Die hl engine basiert zwar auf der alten quake engine.. der netcode unteracheidet sich allerdings signifikant. Der source hilft dir nur um eine grundlegende idee von dem ganzen kram zu bekommen.
Wer fehler findet darf sie behalten... hab das ganze auf nem smartphone getippt.
Dem ist an sich nicht viel hinzu zu fügen.
Welche Implementierung letztendlich die sicherste ist, darüber lässt sich natürlich Streiten. Es war zum Beispiel auch das sogenannte "ARP-Spoofing" im Gespräch (oder man nutzt im LAN einfach einen alten Hubs, statt eines Switches), um den Datenfluss umzuleiten.
Achja - und bitte keinen Hype ;)
Hier wären nun die Anbieter von anderen Anti-Cheat Tools, wie EasyAntiCheat, Insight, Wire Anti-Cheat, X-Ray usw. gefragt.
Neben oberflächlicheren Lösungen würde sich eine tiefgreifende Modifikation der Game-Engine anbieten. Ein Schritt, an dem EAC meiner Meinung nach am nächsten dran ist.
Andererseits steht die treibende Kraft hinter Wire Anti-Cheat in relativ engem Kontakt zu DeepBlueSea und XEPT und konnte die Entwicklung teilweise wohl sogar live mitverfolgen. (So viel übrigens zu dem Mythos, dass Anti-Cheat-Coder und Cheat-Coder zutiefst verfeindet wären – bzw. nur ich so einen guten Draht gehabt hätte, weil ich insgeheim für die Gegenseite arbeite ...)
***UPDATE***
XEPT hat sich zu meinem Artikel geäußert:1. Gab es in der vergangenheit schon voll funktionstüchtige hacks, welche nur über das senden und empfangen von paketen funktionieren. Ein Beispiel dafür wäre der clientless bot bot diablo 2
2. Bei der man in the middle attsck muss auch nichts auf dem router installiert werden. Wäre irgendwo auch wieder detectbar.
3. Sehe ich den post über den hack eher kritisch. Du weißt was für einen nervigen hype der ssh kram ausgelöst hat. Außerdem hätte ich schon geen gesehen das des gesamte ding vis zu einem möglichen release auch unbekannt bleibt... aber gut, sei es drum.
4. Die hl engine basiert zwar auf der alten quake engine.. der netcode unteracheidet sich allerdings signifikant. Der source hilft dir nur um eine grundlegende idee von dem ganzen kram zu bekommen.
Wer fehler findet darf sie behalten... hab das ganze auf nem smartphone getippt.
Dem ist an sich nicht viel hinzu zu fügen.
Welche Implementierung letztendlich die sicherste ist, darüber lässt sich natürlich Streiten. Es war zum Beispiel auch das sogenannte "ARP-Spoofing" im Gespräch (oder man nutzt im LAN einfach einen alten Hubs, statt eines Switches), um den Datenfluss umzuleiten.
Achja - und bitte keinen Hype ;)
