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.
Vor ein paar Tagen gab es einen kleinen Aufruhr in der Cheatcoderszene.
Ein sehr aktiver Coder namens „wav“, welcher sich 2010 bereits einen guten Ruf durch diverse Beiträge zum Thema VAC2 erarbeitet hatte, veröffentlichte eine kurze Analyse über einen möglichen Nachfolger vom oft geschmähten Valve Anti-Cheat.
Ich möchte nun eine Zusammenfassung seiner Ergebnisse in einer für den normalen, aber technisch versierten, Spieler liefern.
 |
| Das mutmaßliche VAC3-Modul im Disassembler |
Zuerst sei einmal gesagt, dass VAC3 wohl schon seit November aktiv im Hintergrund läuft. Dies wurde auch von x22 und einigen Anderen bestätigt.
Ob es bereits Delayed Bans, sprich Sperren, die erst nach ein paar Wochen in Kraft treten, gegeben hat, steht nicht sicher fest, auch wenn es dazu bereits Berichte gab.
Ob es bereits Delayed Bans, sprich Sperren, die erst nach ein paar Wochen in Kraft treten, gegeben hat, steht nicht sicher fest, auch wenn es dazu bereits Berichte gab.
Richtig aktiv ist VAC3 allerdings wohl nur bei aktuellen Spielen, die auf der Source-Engine basieren oder zur neueren Call of Duty-Reihe gehören. Counter-Strike 1.6 muss wohl ohne den neuen Schutz auskommen, was jedoch nicht verwundert, wenn man weiß, dass bereits bei VAC2 die besseren Scanroutinen nur bei aktuellen Spielen zum Einsatz kamen.
Über die Gründe dafür lässt sich nur spekulieren. Der gesunde Menschenverstand sagt einem, dass Valve es wohl einfach nicht für nötig hält, ein runde zehn Jahre altes Spiel, das man für unter 10 Euro erwerben kann, aufwendig abzusichern.
Über die Gründe dafür lässt sich nur spekulieren. Der gesunde Menschenverstand sagt einem, dass Valve es wohl einfach nicht für nötig hält, ein runde zehn Jahre altes Spiel, das man für unter 10 Euro erwerben kann, aufwendig abzusichern.
Die größte technischere Neuerung ist die Art und Weise, wie das Modul ausgeliefert wird.
Früher lief es so ab, dass eine normale DLL-Datei übertragen, in den Temp-Ordner (mit „.tmp“-Endung, statt „.dll“) gelegt und von dort mit einem Standard-Windows-Aufruf namens „LoadLibrary“ geladen wurde.
Eine ähnliche Technik kam lange Zeit auch bei ESL Aequitas zum Einsatz. Da diese Technik aber leider viel Angriffsfläche bietet, bin ich damals auf eine direktere Übertragung und sogenanntes Manual Mapping übergegangen.
Dies bedeutet, dass der Code direkt übertragen und nirgends fest abgespeichert wird, sondern direkt in den Prozess „verpflanzt“, wo er laufen soll. Man umgeht damit gewissermaßen diverse Windows-Aufrufe, die allesamt leicht abzufangen wären. Zudem ist der Programmcode auch nicht ganz so offensichtlich als eigenständiges Modul „sichtbar“, wenn man es einigermaßen geschickt anstellt.
Genau so scheint VAC3 jetzt auch vorzugehen, wobei der Code von einer Steamkomponente über eine sichere Verbindung geholt wird.
Früher lief es so ab, dass eine normale DLL-Datei übertragen, in den Temp-Ordner (mit „.tmp“-Endung, statt „.dll“) gelegt und von dort mit einem Standard-Windows-Aufruf namens „LoadLibrary“ geladen wurde.
Eine ähnliche Technik kam lange Zeit auch bei ESL Aequitas zum Einsatz. Da diese Technik aber leider viel Angriffsfläche bietet, bin ich damals auf eine direktere Übertragung und sogenanntes Manual Mapping übergegangen.
Dies bedeutet, dass der Code direkt übertragen und nirgends fest abgespeichert wird, sondern direkt in den Prozess „verpflanzt“, wo er laufen soll. Man umgeht damit gewissermaßen diverse Windows-Aufrufe, die allesamt leicht abzufangen wären. Zudem ist der Programmcode auch nicht ganz so offensichtlich als eigenständiges Modul „sichtbar“, wenn man es einigermaßen geschickt anstellt.
Genau so scheint VAC3 jetzt auch vorzugehen, wobei der Code von einer Steamkomponente über eine sichere Verbindung geholt wird.
Eine weitere Neuerung, die teilweise bereits bei Aequitas zum Einsatz kam und von der bei Aequitas 2.0 exzessiv gebraucht gemacht wurde (bzw. gemacht werden sollte), sind „Direct Syscalls“.
Dazu muss man wissen, dass Windows im Endeffekt zwei Schichten hat. Die normale Usermode-Schicht (auch ring3 genannt), wo alle normalen Prozesse laufen und die Kernelmode-Schicht (auch ring0 genannt), in der die Treiber laufen. Wenn man im Usermode etwas falsch macht bei der Programmierung, dann stürzt im Normalfall nur der Prozess ab (oft sogar nicht mal das, da man viele Mittel hat, Fehler abzufangen). Im Kernelmode hingegen ist jeder Fehler tödlich und führt zu einem Bluescreen (auch BSOD – Bluescreen Of Death genannt).
Früher (bei Windows 9x & ME) war es nun so, dass es diese saubere Trennung nicht gab. Ein normales Programm konnte recht schnell einen Bluescreen erzeugen – zum Teil schon bei ganz normalen Windows-Aufrufen.
Daher entschied sich Microsoft dazu einen ähnlichen Weg zu gehen, wie die Unix-Betriebssysteme (z.B. Linux, BSD-Varianten etc.) und zwischen normalen Programmen und wichtigen Treibern + dem Windowskern, der auch die Funktionen für die Windows-Aufrufe bereitstellt, zu trennen.
Dazu muss man wissen, dass Windows im Endeffekt zwei Schichten hat. Die normale Usermode-Schicht (auch ring3 genannt), wo alle normalen Prozesse laufen und die Kernelmode-Schicht (auch ring0 genannt), in der die Treiber laufen. Wenn man im Usermode etwas falsch macht bei der Programmierung, dann stürzt im Normalfall nur der Prozess ab (oft sogar nicht mal das, da man viele Mittel hat, Fehler abzufangen). Im Kernelmode hingegen ist jeder Fehler tödlich und führt zu einem Bluescreen (auch BSOD – Bluescreen Of Death genannt).
Früher (bei Windows 9x & ME) war es nun so, dass es diese saubere Trennung nicht gab. Ein normales Programm konnte recht schnell einen Bluescreen erzeugen – zum Teil schon bei ganz normalen Windows-Aufrufen.
Daher entschied sich Microsoft dazu einen ähnlichen Weg zu gehen, wie die Unix-Betriebssysteme (z.B. Linux, BSD-Varianten etc.) und zwischen normalen Programmen und wichtigen Treibern + dem Windowskern, der auch die Funktionen für die Windows-Aufrufe bereitstellt, zu trennen.
Wenn man nun eine Funktion von Windows nutzen möchte, hat man immer noch seine normalen Windows-DLLs, die im Usermode laufen - aber in diesen DLLs stecken die eigentlichen sogenannten Syscalls, die nur das Tor in Richtung Kernelmode sind, wo die eigentliche Windows-Funktion abläuft. Praktischerweise ist es dem Kernelmode egal, ob der Syscall aus einer Windows-DLL kam oder von einem unserer Programme, so dass man in der Theorie auch auf die offiziellen Windows-DLLs verzichten und seine eigenen Syscalls „simulieren“ kann.
Dabei gibt es aber das große Problem, dass diese Syscalls von Windows Version zu Windows Version verschieden sind und selbst innerhalb einer Windows Version bei unterschiedlichen Service Packs verschieden sein können. Oder anders formuliert: Die TOTALE Kompatibilitätshölle!
Der große Vorteil hingegen liegt darin, dass das ganz klassische „Hooken“ von Windows-Funktionen im Usermode nicht mehr mehr so einfach funktioniert. Wer sich also in eine Windows-Funktion reinhängen möchte, um z.B. Screenshots oder das Auslesen vom Speicher abzufangen, der kommt nicht mehr daran vorbei, einen Treiber zu schreiben, der die Syscalls direkt im Kernelmode abfängt. Und einen stabilen Treiber zu schreiben, der dann auch noch solche „bösen, ungeplanten“ Dinge im Windows-Kern durchführt, ist absolute Schwerstarbeit und doch mit einigem Know-How verbunden!
Dabei gibt es aber das große Problem, dass diese Syscalls von Windows Version zu Windows Version verschieden sind und selbst innerhalb einer Windows Version bei unterschiedlichen Service Packs verschieden sein können. Oder anders formuliert: Die TOTALE Kompatibilitätshölle!
Der große Vorteil hingegen liegt darin, dass das ganz klassische „Hooken“ von Windows-Funktionen im Usermode nicht mehr mehr so einfach funktioniert. Wer sich also in eine Windows-Funktion reinhängen möchte, um z.B. Screenshots oder das Auslesen vom Speicher abzufangen, der kommt nicht mehr daran vorbei, einen Treiber zu schreiben, der die Syscalls direkt im Kernelmode abfängt. Und einen stabilen Treiber zu schreiben, der dann auch noch solche „bösen, ungeplanten“ Dinge im Windows-Kern durchführt, ist absolute Schwerstarbeit und doch mit einigem Know-How verbunden!
Daher war es für mich damals eine klare Entscheidung, das in Aequitas 2.0 umzusetzen und ich bereue auch nicht wirklich, darin viel Zeit gesteckt zu haben. Wenn ich mir anschaue, dass VAC3 auch Direct Syscalls nutzt, dann weiß ich, dass ich auf dem richtigen Pfad war.
Diese beiden Techniken scheinen aber erst einmal nur dazu zu dienen, sich gegen Angriffe besser schützen zu können. Von wirklich neuen Scanmethoden war bisher nichts zu sehen. Jedoch sollte es Valve jetzt etwas leichter fallen VAC-Updates einfacher und unbemerkter einzuspielen.
Bei Aequitas war es mir möglich diese Methode inkl. Detectionupdates über mehrere Jahre hinweg unbemerkt zu nutzen.
Leider wird es ihnen wohl nicht möglich sein, einen Treiber unbemerkt zu laden. Mittlerweile halte ich einen Treiber mit ein paar grundlegenden Funktionen für absolut unabdingbar, wenn man ein modernes und effektives Anti-Cheat Tool betreiben möchte.
Bei Aequitas war es mir möglich diese Methode inkl. Detectionupdates über mehrere Jahre hinweg unbemerkt zu nutzen.
Leider wird es ihnen wohl nicht möglich sein, einen Treiber unbemerkt zu laden. Mittlerweile halte ich einen Treiber mit ein paar grundlegenden Funktionen für absolut unabdingbar, wenn man ein modernes und effektives Anti-Cheat Tool betreiben möchte.
So gesehen ist VAC3 zwar aus technischer Sicht definitiv interessant, aber definitiv nicht der ganz große Sprung nach vorne, wie es zum Beispiel Wire Anti-Cheat für die ESL ist.
Das ist an sich Schade, da Valve eine riesige Reichweite hat und die Cheaterwelt wirklich auf den Kopf stellen könnte.
Das ist an sich Schade, da Valve eine riesige Reichweite hat und die Cheaterwelt wirklich auf den Kopf stellen könnte.
Die „großen“ Private Hacks, wie z.B. Immunity von Organner oder auch die x-Reihe von x22 werden damit jedenfalls keine ernsten Probleme haben, denke ich.
Hinweis:
Ich selbst habe nur kurz über die Rohdaten geschaut. Die eigentlichen Infos über VAC3 stammen, wie bereits erwähnt, von „wav“ und ich habe sie nur noch einmal (hoffentlich) verständlicher aufgearbeitet und in den Kontext gerückt.
Ich selbst habe nur kurz über die Rohdaten geschaut. Die eigentlichen Infos über VAC3 stammen, wie bereits erwähnt, von „wav“ und ich habe sie nur noch einmal (hoffentlich) verständlicher aufgearbeitet und in den Kontext gerückt.
So gesehen – all credits to wav!
PS:
Ja, eigentlich wollte ich bis Ende Januar nichts mehr schreiben und mir in Ruhe nen neuen Job suchen. Aber bei solch interessanten Themen kann man mal ne Ausnahme machen ;)
*** Update #1 ***
Der Titel auf Readmore lautet "T-Man analysiert möglichen VAC2-Nachfolger" - ich möchte festhalten, dass ich mich zwar über solch eine direkte Erwähnung freue, ich die News aber unter einem anderen Titel ("Eine VAC3-Analyse" oder so) eingereicht habe.
Faktisch habe auch nicht ich VAC3 analysiert, sondern wav! Von mir kam wie gesagt nur die Erklärung und der Hintergrund.
PS:
Ja, eigentlich wollte ich bis Ende Januar nichts mehr schreiben und mir in Ruhe nen neuen Job suchen. Aber bei solch interessanten Themen kann man mal ne Ausnahme machen ;)
*** Update #1 ***
Der Titel auf Readmore lautet "T-Man analysiert möglichen VAC2-Nachfolger" - ich möchte festhalten, dass ich mich zwar über solch eine direkte Erwähnung freue, ich die News aber unter einem anderen Titel ("Eine VAC3-Analyse" oder so) eingereicht habe.
Faktisch habe auch nicht ich VAC3 analysiert, sondern wav! Von mir kam wie gesagt nur die Erklärung und der Hintergrund.
