Egal ob Browsergame oder Multiplayer PvP, Onlinespiele sind in der heutigen Zeit sehr gefragt. Es macht einfach mehr Spass, gemeinsam mit Freunden zu Spielen, statt sich mit einer pseudoklugen KI an der Seite herrum zu schlagen. Der Trend geht klar Richtung Onlinespiele, was wiederrum auch Gamehacker anlockt. In dem heutigen Artikel werden Grundlagen besprochen, auf die man beim Programmieren achten sollte. Anschaulich wird das ganze durch Beispiele erklärt.

Das Spektrum von Hacks, über Bots und Exploits ist zu groß, als dass man es alles in einem Artikel abdecken könnte. Daher werden primär nur Echtzeit-Onlinespiele betrachtet. Diese Techniken lassen sich aber beliebig auf andere Multiplayer-Spiele übertragen. Und noch kurz zu den verwendeten Begriffen in diesem Artikel:

• Server: Dabei handelt es sich um einen zentralen (!) Server, der das eigentliche Spiel hostet. Er nimmt Daten von anderen Spielern entgegen und verteilt die “Änderungen” im Spiel an alle verbundenen Clients. In machen Spielen wird der Server auch als “Host” bezeichnet, was im Prinzip nichts anderes bedeutet.
• Client: Ein Spieler, der mit dem Server verbunden ist und aktiv Stati (Schießen, Laufen) an den Server sendet

Der wohl bedeutenste Grundsatz dürfte sein: Traue nie den vom Client empfangenden Daten. Der Client schickt, wie schon oben erwähnt, in regelmäsigen Abständen Daten wie seine eigene Position und seine Attribute an den Server. Wenn ein Gamehacker die Welt-Position des Clients verändert, wird diese auch zum Server gesendet. Wenn der Server diese Daten nun ungeprüft übernimmt, haben wir einen sog. Teleport-Hack. Solche Teleport-Hacks befanden sich u.a. in großen Onlinespielen wie Metin 2.

Während sich der entstehende Vorteil durch Teleportierungen noch in Grenzen hält, hört der Spass bei sog. Masskill-Hacks auf. Dabei sendet der Client die Nachricht “Ich habe XX Schaden am Gegner Y gemacht”. Der Server übernimmt dieses ungeprüft und tötet den Gegner Y. In Battlefield 3 ist dieser Hack inzwischen gefixxt, die Kollisionserkennung ist allerdings immernoch Clientseitig. So sind “Instant Kills” möglich, indem man einfach den Schaden, den eine Waffe verursacht, ins unendliche erhöht. Daher die Regel Nummer 2: Auf Plausibilität prüfen! Im Falle einer clientbasierten Kollisionserkennung kann man durch Wände schießen. Wenn der Server nun einmalig prüft, ob Spieler X den Spieler Y überhaupt treffen kann, wären solche Hacks schon verhindert. Warum das nicht gemacht wird? Weil solche Checks relativ viel Rechenleistung brauchen und einen Server mit 64 Spielern überfordern würde.

Weiter geht es mit Waffen-Spawn-Hacks. Das Prinzip dahinter ist wieder einfach. Der Client sendet “Ich habe die Waffe XX vom Boden in mein Inventar aufgenommen” an den Server. Der Server prüft nicht, ob die Waffe wirklich davor auf dem Boden lag und übermächtige Waffen landen im Waffenarsenal des Spielers. Das ganze Spiel kann man weiterstricken, indem man nur Clientseitig die Nachlade und sogar Feuerzeit einer Waffe prüft. So kann ein Spieler 100 Kugeln pro Sekunde feuern, 0.1 Sekunden nachladen und danach fröhlich weiter machen. Ihr versteht worauf es hinausläuft: Plausibilitätsprüfung!

Regel Nummer 3, die mehr auf rundenbasierte Spiele und Browsergames auslegt ist: Dem Client nur das Schicken, was er auch sieht. Nehmen wir als Beispiel das Online-Kartenspiel Hearthstone. Die Karten des Gegenübers zu kennen wäre ein enormer Vorteil. In diesem Fall wählt Blizzard den richtigen Weg und sendet dem gegnerischen Client erst dann die Karte, wenn sie auch wirklich ausgespielt wurde. Die Kartendecks werden nur Serverseitig hinterlegt und auch der Kartenstapel, von welchem Karten gezogen werden, liegt sicher verwahrt auf dem Server. Im Übrigen könnten so auch Wallhacks und zum Teil Aimbots vermieden werden: Wenn der Client keine Ahnung hat, wo auf der Karte sich die anderen Spieler befinden, kann auch kein Wallhack stattfinden. Das Online-Panzerspiel World of Tanks hat dieses Prinzip im übrigen übernommen. Um noch ein Negativbeispiel zu nennen: Das schon in einem anderen Beitrag kritisierte HackEx Android-Browsergame, welches fast alle der oben genannten Regeln ignoriert.

Noch ein paar letzte Worte zu Bots in Online-Spielen: Verhindere, dass die selbe Request 2 mal gesendet werden kann! Sonst kann der Gamehacker einfach die Request mitschneiden und im Anschluss erneut absenden. So können langweilige Aufgaben (Bei diversen Onlinespielen ist das z.B. die Angel auswerfen, 20 sek Fischen und das Spiel von vorne) sehr leicht automatisiert werden. Daher gilt: Verschlüssele die Requests und schicke einen Hash (basierend auf den Parametern und der Zeit) mit. Die Sache mit den Hash hat HackEx ganz gut gemacht.

Wer sein eigenes Spiel sehr gewissenhaft vor Modifikationen schützen möchte, kann dieses über einen sog. Heartbeat-Server erreichen. Dabei sendet der Server immer wieder die Anfrage an den Client, ein Hash aus dem geladenen Speicherabbild zu erstellen. Dieser Hash wird Serverseitig mit dem “originalen Hash” verglichen und bei einer Unregelmäsigkeit der Spieler gekickt. Diese Anti-Cheat-Systeme sind erfolgreich von AlterIWNet und Wolfteam (Siehe die Artikel über Apex) eingesetzt wurden. Doch auch hier ist es nur eine Sache des Aufwands, diese Kommunikation zu entschlüsseln und mit eigenen Heartbeats zu ersetzen.

Gamehacking ist immer ein Katz-und-Maus Spiel. Mal denken sich die Spieleentwickler kreative Anstätze zum Erkennen von Hackern aus (Screenshots ) und mal kommen die Hacker und umgehen das System (vor jedem Screenshot den Hack kurz ausschalten). Mit den oberen Grundregeln im Hinterkopf können euch Hacker nicht mehr ganz so viel Schaden anrichten!

Easy