- In Magic: The Gathering Arena konnte man den Gegner zum gewünschten Zeitpunkt zur Aufgabe zwingen und sich so in Matchmaking-Spielen einen Zustand verschaffen, in dem man nicht verlieren konnte
- Kartenspiele eignen sich normalerweise gut für eine serverautoritativ aufgebaute Architektur, in der der Server den vollständigen Zustand verwaltet, doch der MTGA-Botgegner Sparky war als Logik im lokalen Client implementiert
- Der auf C# basierende MTGA-Client erlaubte über Reflection den Zugriff auf Laufzeitobjekte und private Felder, und im dekompilierten Code ließen sich Namen wie
JoinMatch,ConnectAndJoinMatchundHeadlessClienterkennen - In Bot-Matches wurde eine Struktur verwendet, bei der mit derselben
PersonaIDund demselben JWT beide Sitzplätze verbunden wurden; übertrug man das auf normale Matches, konnte man einen Headless-Client an den gegnerischen Sitz hängen und danachConcedeGame()aufrufen - Der Server wurde später so gepatcht, dass in Matchmaking-Spielen nicht mehr beide Sitzplätze dieselbe Kontoidentität und dasselbe JWT verwenden können; der Fall zeigt, wie sich die Grenze zwischen clientseitiger Bot-Implementierung und Sitzplatz-Authentifizierungsprüfung direkt auf die praktische Sicherheit auswirkt
Warum es schwer ist, Kartenspiele zu hacken
- Kartenspiele sind rundenbasiert, und zwischen Client und Server werden nicht viele Informationen ausgetauscht, daher passen sie gut zu einer serverautoritativen Architektur
- Der Server verwaltet den vollständigen Spielzustand und schickt dem Client nur die benötigten Informationen
- Nicht öffentliche Informationen wie die Hand oder das Deck des Gegners existieren lokal nicht
- Versuche, die Deckreihenfolge zu ändern oder die nächste gezogene Karte zu manipulieren, sind schwierig, weil der Server die Aktion ausführt und nur das Ergebnis mitteilt
- Anders als bei Ego-Shootern sind die Aktionen der Spieler in Kartenspielen begrenzt und treten zu festgelegten Zeitpunkten auf
- In FPS können Informationen wie Gegnerpositionen vorab im Client-Cache liegen, was Formen wie Wallhacks ermöglicht
- Riots Anti-Wallhack-Blog behandelt einen Ansatz, clientseitige Positionsdaten von Spielern zu reduzieren
- Auch fehlerhaftes Verhalten lässt sich vergleichsweise leicht erkennen
- Eine Karte spielen, die man nicht auf der Hand hat
- Eine Aktion ausführen, obwohl man nicht am Zug ist
Ausgangspunkt der Analyse: Netzwerk und C#-Client
- Als Ausgangspunkt für das Game-Hacking wurde der Ansatz gewählt, sich die Netzwerkkommunikation anzusehen
- Manfreds DEF-CON-Vortrag über MMO-Hacking zeigt, dass Reverse Engineering von Netzwerkprotokollen für die Analyse vieler Bugs zentral ist
- Da MTGA in C# geschrieben ist, konnten Laufzeitobjekte manipuliert werden, statt Funktionen für das Senden und Empfangen von Traffic zu hooken
- Mit .NET-Reflection ist auch der Zugriff auf private Felder und Methoden möglich
- Als grundlegendes Beispiel ist das Tutorial zum Reflection-Hacking in Unity-Spielen verlinkt
- Nicht obfuskierte .NET-Assemblies erlauben es dank Metadata-Token, Funktions-, Variablen- und Klassennamen in menschenlesbarer Form zu sehen
- Dadurch kommt das Dekompilat praktisch einem Source-Code-Review sehr nahe
Die in JoinMatch entdeckte Sparky-Struktur
- Bei der Suche nach relevanten Funktionsnamen für die Initialisierung des Match-Beitritts wurde die Funktion
JoinMatchgefunden JoinMatchwar eine lange Funktion mit mehr als 200 Zeilen, und im unteren Bereich ließ sich ein Aufruf vonConnectAndJoinMatcherkennen- Diese Funktion wirkte wie der Ablauf, der Match-Konfigurationsinformationen entgegennimmt und eine Verbindung zum Gameserver herstellt
- Im selben Codepfad gab es Verzweigungen für
MatchType.NPEundMatchType.FamiliarNPEsteht vermutlich für ein Tutorial-ähnliches Match im Rahmen der New Player ExperienceFamiliarist das reguläre Bot-Match
- Die in diesem Zweig aufgerufene Logik war mit Sparky, dem Botgegner von MTGA, verbunden
- Sparky ist der maskottchenartige Gegner von MTGA in Tutorial- und Bot-Partien
- In Bot-Matches lief die Bot-Logik innerhalb des Spielclients auf dem lokalen Rechner
Lokaler Bot und HeadlessClient
- Der eigentliche Logik-Handler des Bots befand sich in der Klasse
HeadlessClient HeadlessClientist ein Headless-Client, der das Spielbrett nicht rendert, sich aber mit dem Server verbindet und die Partie spielt- Der lokal erzeugte Bot-Client nutzte dieselben Benutzerauthentifizierungsdaten wie der Spielclient
PersonaIDals Benutzer-ID- Das nach dem Login dem Spiel zugewiesene JSON Web Token
- In Bot-Matches war die Struktur so angelegt, dass der Server es nicht als Problem ansah, wenn derselbe Client faktisch beide Seiten des Matches verband
- Ein Sitzplatz (Seat) dient im Spiel dazu, zu unterscheiden, welcher Spieler man ist
- In Bot-Matches konnten mit denselben Authentifizierungsdaten verschiedene Sitzplätze belegt werden
Wie normale Matches übernommen wurden
- Es wurde getestet, ob sich die Bot-Match-Logik auf normale Matches übertragen lässt, um beide Sitzplätze zu verbinden
- Die nötigen Informationen wurden aus Laufzeitobjekten des Spiels geholt
- aktuelle Match-Konfiguration
- Host und Port des Match-Servers
controllerFabricUrimatchIdPersonaIDJwt- Kartendatenbank
- Match-Manager
- Asset-Lookup-System
- Ausgehend vom eigenen Sitzplatz wurde der gegnerische Sitzplatz berechnet
- Im Code wurde mit
man.LocalPlayerSeatId % 2U + 1Uder andere Sitzplatz bestimmt
- Im Code wurde mit
- Mit
UnityFamiliar.SpawnFamiliar_DEBUG(...)wurde ein Bot mit dem gegnerischen Sitzplatz verbunden - Anschließend wurde das erzeugte
UnityFamiliar-Objekt gefunden undcheatbot.Client.Gre.ConcedeGame()aufgerufen, um es sofort aufgeben zu lassen
Ergebnis und Patch
- Diese Methode funktionierte auch in normalen Matches
- Sie funktionierte sogar dann, wenn der Gegner bereits verbunden war und das Spiel lief
- Da es sich um Matchmaking-Spiele handelte, erhielt man Belohnungen, als hätte man einen menschlichen Gegner besiegt
- Der Kern der Schwachstelle war, dass der normale Match-Server die Situation zuließ, dass beide Sitzplätze mit demselben Konto und demselben JWT verbunden wurden
- Der Server wurde später so gepatcht, dass in Matchmaking-Spielen beide Sitzplätze nicht mehr dasselbe Konto und dasselbe JWT verwenden können
- Der
InstaWin-Code im Anhang implementiert als Unity-MonoBehavioureine GUI-Schaltfläche; beim Klick sammelt sie die aktuellen Match-Informationen, hängt einen Bot an den gegnerischen Sitzplatz und lässt ihn dann aufgeben
1 Kommentare
Hacker-News-Kommentare
Der erste Anlass, mich wirklich intensiv mit Linux zu beschäftigen, war ShowEQ für EverQuest, mit dem ich mir den Netzwerkverkehr angesehen habe.
Damals war der Traffic nicht verschlüsselt und enthielt viele nützliche Informationen. Über einen Hub spiegelte ich den Traffic auf eine Linux-Maschine, zeichnete eine Echtzeitkarte der Zone, zeigte Monster-, NPC- und Spielerpositionen an und sogar die Beute, die Monster bei sich hatten, sodass man gezielt bestimmte Monster jagen konnte. Der Vorteil war, dass es manuell lief und daher nicht erkennbar war; schließlich bekam SOE es mit und begann, den Traffic zu verschlüsseln.
Daraufhin führt die Gegenseite keybasierte Signaturen ein, man versucht wieder, die Keys aus dem Client zu stehlen und die Verschlüsselung zu brechen, und später kommen Anti-Cheat-Systeme dazu – so beginnt das Katz-und-Maus-Spiel.
War es den Vorteil im Spiel wert? Nein. Ich habe nicht ernsthaft gespielt, also habe ich zwei Wochen mit der Einrichtung verbracht und es dann etwa eine Woche genutzt, aber als Lernerfahrung war es großartig.
Zum Beispiel die Existenz von hell levels, dass nicht Menschen, sondern Halblinge einen Erfahrungsbonus bekamen und es tatsächlich Unterschiede bei der Erfahrung je nach Volk/Klasse gab, sowie dass die frühe Shaman-Alchemie tatsächlich kaputt war. Und ich glaube, daraus ist dann eqemulator.org hervorgegangen.
Die heutigen Besitzer von EQ scheinen sich nicht besonders darum zu kümmern, daher kann man es ziemlich problemlos nutzen. Allerdings hat keine der beiden Apps je die Beute von Monstern angezeigt, abgesehen von sichtbarer Ausrüstung. Im Lauf der Jahre haben sich auch einige Daten geändert: Früher wurde die exakte Monster-Gesundheit übertragen, heute wird nur noch ein Prozentwert gesendet.
Ich verstehe den Teil nicht ganz, dass „ein nahezu vollständiger Bot, der beliebige Partien Magic: The Gathering spielen kann, klein genug ist, um auf einer lokalen Maschine zu laufen“.
Wenn eine MTG-KI zu schwergewichtig wäre, um sie auf Kundenmaschinen laufen zu lassen, würde man sie vermutlich auch nicht auf Servern betreiben. Bot-Partien in Kartenspielen werden normalerweise nicht pro Partie abgerechnet, also würden die Kosten stark steigen. Server sind auch keine Magie, sondern verwenden meist dieselben x86-CPUs wie lokale Maschinen, oft mit niedrigerem Takt als Desktops. Um Bot-Züge gegenüber lokaler Ausführung zu beschleunigen, müsste man deutlich mehr Kerne einsetzen als der Kunde hat; bei 8–16 zugewiesenen Kernen pro Spieler wäre das zu Spitzenzeiten bei gleichzeitigen Logins ein Albtraum. Wenn der CPU-Spieler kein Multicore unterstützt, müsste die lokale Ausführung ohnehin schneller sein.
Es heißt, dass die Regel-Engine des Bots klein genug ist, um in den Speicher eines älteren iPhones oder Android-Geräts zu passen. Auf einem Server könnte man viele Zustandsmaschinen oder Regel-Engines im Speicher halten, und für das Ausführen einer bestimmten Anfrage wäre möglicherweise kaum Rechenleistung nötig.
Daniel, nochmals Glückwunsch zum Top-Beitrag. Nachdem dieser Artikel erschienen war, habe ich mich auch am Hacken von MTGA versucht und auf GitHub ein wenig darüber gesprochen [0].
Für Interessierte: Ich arbeite derzeit inaktiv an einem inoffiziellen MTGA-Client, der bislang kaum Funktionen hat. Ziel ist es, das Spielen von Ranked-Partien zu automatisieren und stärkere Bot-Gegner bereitzustellen. In letzter Zeit ist das wegen anderer Dinge liegen geblieben, und ich weiß auch noch nicht, wie ich eine gute, klar erkennbare UI bauen soll; daher kann ich nicht einmal abschätzen, wann es mindestens nützlich wird. Darüber hinaus interessieren mich weiterhin Daniel s und anderer Leute Geschichten über Game-Hacking. Ich würde gern mehr darüber hören, wie man solche Bugs findet, wie man sich nach dem Hacken keine Sorgen über Bans macht, wie man Bugs öffentlich macht, wie @aethros es angesprochen hat, oder wie man inoffizielle Kartenspiel-Clients strukturiert.
[0] https://github.com/MayerDaniel/mayerdaniel.github.io/issues/...
Zu sagen, man hätte erwartet, dass es viel Overhead verursacht, für ein komplexes Spiel wie MTG einen KI-Gegner zu bauen, ist eine ziemlich große Untertreibung.
Das Spiel ist nahezu Turing-vollständig, und selbst wenn man Endlosschleifen ausklammert, spielen Leute viel damit herum. Trotzdem dürfte es zur KI-Strategie-Seite bereits einiges an Forschung geben. Und da der Autor den Beitrag selbst gepostet hat, könnte der Titel wohl „Show HN:“ tragen.
Für Bot-Autoren scheint Letzteres das schwierige Problem zu sein.
Zum Beispiel, indem man mit Eintritts-/Austritts-/Enttapp-Effekten Token-Kreaturen erzeugt und sterben lässt. Solche Schleifen fügen auch nicht immer einer Seite Schaden zu.
Ich habe MTG nie gespielt, aber diese Behauptung klingt so, als sei es technisch möglich, wenn man absichtlich eine zustandsbehaftete Struktur baut – nicht, weil man damit gewinnen will.
Es macht wirklich Spaß, mit meinem Sohn Oldschool Magic 93/94 mit physischen Karten zu spielen.
Jedes Jahr fahren wir nach Madrid, um an der 7pts-Singleton-Weltmeisterschaft teilzunehmen. Diesen Sommer wurde mein Sohn Neunter, worauf ich sehr stolz bin. 7pts Singleton ist ein großartiges Format, das vielfältige Deckkonstruktionen ermöglicht und für vergleichsweise überschaubare Kosten ausgewogenes Gameplay bietet (https://7pts-singleton.com)
Auch wenn man in 7pts Singleton nicht alle davon spielen kann: Schon eine einzige dieser Karten kostet Tausende bis Zehntausende Dollar. Trotzdem schön, dass du mit deinem Sohn das Spiel genießt, und Glückwunsch zur Platzierung.
Reine clientseitige Spiellogik, wirklich? Als ich früher ein kleines Spiel gebaut habe, musste ich für die Reaktionsfähigkeit manchmal Spiellogik in den Client legen, aber nichts hindert einen daran, dieselbe Logik auf dem Server erneut auszuführen, also habe ich das so gemacht.
Bei Echtzeitspielen wie FPS oder RTS kann das schwierig sein, aber bei einem Kartenspiel gibt es dafür keine Ausrede. Bei so einem Kartenspiel sollte der Client nicht mehr Informationen erhalten, als ein realer Spieler sehen kann. Also etwa nicht die Karteninhalte der gegnerischen Hand senden, sondern nur die Anzahl der Karten. Auch Aktionen, die an den Server geschickt werden, sollten sich nur auf einen selbst beziehen; man sollte also nicht die Aufgabe des Gegners erklären können. Wenn ich „Ich gebe auf!“ sage, sollte der Server das so interpretieren, dass ich aufgebe.
Die Schwachstelle bestand darin, dass man einen zweiten Client starten und sich in der laufenden Partie auf den Platz des Gegners einloggen konnte. Sobald das gelang, konnte man Aktionen des Gegners senden, einschließlich der Aufgabe.
Was der Autor ausnutzte, war nicht clientseitige Spiellogik, sondern ein Problem in der Autorisierung und im Code für den Spielbeitritt. Die Aussage „man sollte nicht anstelle des Gegners aufgeben können“ wiederholt im Grunde genau, wie der vom Autor gefundene Exploit funktionierte.
In League of Legends gab es bei einer bestimmten Kombination aus Champion und Items einen Division-durch-null-Bug, durch den der Server alle Spieler hinauswarf und dann abstürzte.
Weil der Ausnutzer zuletzt herausgeworfen wurde, wurde dessen Team als Sieger gewertet, während das gegnerische Team statt eines normalen Ergebnisses Loss Prevented erhielt.
An diesem Artikel gefallen mir die zugänglichen und zugleich aufschlussreichen Details.
Was ich allerdings nicht verstehe, ist der Fall, dass während einer laufenden Partie ein Bot verbunden wird. Warum erlaubt das Spiel einen Beitritt mitten in der Partie, und warum wird es als Aufgabe des Gegners gewertet, wenn der Bot aufgibt? Wenn man ein Spiel für drei Spieler erstellt, sollte die Aufgabe von Spieler 3 nicht auch bedeuten, dass Spieler 2 aufgegeben hat.
Der Code ermittelt den Sitzindex meines Kontos und lässt den Bot dann mit dem anderen Sitzindex beitreten. Das Problem ist, dass nicht geprüft wird, ob der beitretende Nutzer der korrekte Nutzer für diesen Platz ist. Man könnte auch denken, dass eine erneute Verbindung zu einem bereits verbundenen Platz nicht erlaubt sein sollte, aber wenn ein Spiel auch Mobilgeräte unterstützt, möchte man den Timeout bei Verbindungsabbrüchen wohl ziemlich lang halten. Man will ja keinen Spieler blockieren, der kurz die Verbindung verliert und sich wieder verbindet, bevor der Timeout die alte Verbindung als tot erkannt hat. Ich habe auch in anderen Spielen gesehen, dass beim erneuten Verbinden etwa 10 Sekunden lang „Beitritt zu laufendem Spiel nicht möglich“ erscheint und man erst später wieder verbunden wird. Als Analogie: Man erscheint bei einem MTG-Turnier im örtlichen Kartenladen, schiebt jemanden vom Stuhl, setzt sich hin und ruft „Ich gebe auf!“, und der Judge akzeptiert das als Aufgabe von Spieler B, weil die Person auf diesem Stuhl es erklärt hat.
Deshalb konnte er offenbar an dessen Stelle aufgeben. Vielleicht haben die Entwickler schlicht nicht gedacht, dass jemand einen Grund hätte, so etwas überhaupt zu versuchen, und deshalb keine Prüfung eingebaut.
Das erinnert mich an die Diablo-2-Zeit, als man dasselbe Login-Paket wiederverwenden konnte, um einen Open-Server-Charakter (LAN) mit den offiziellen bnet-Internetservern zu verbinden.
Da die Open-Server-Daten vollständig lokal gespeichert waren, konnte man alle möglichen Items erstellen, die eigentlich nicht existieren dürften, und die offiziellen Server akzeptierten sie trotzdem.
Ich bin vor Kurzem über MTGA wieder in MTG eingestiegen. Es ist ein Unity-Spiel und nicht il2cpp, also habe ich es schnell dekompiliert; selbst wenn es il2cpp gewesen wäre, wäre das wohl kein großer Schutz gewesen, und ich habe ein paar ziemlich interessante Dinge gefunden.
Darunter waren Schlüssel für den Epic-Launcher-Build und undokumentierte APIs. Ich will das nicht zum Cheaten nutzen; ich hätte nur gern ein Kampfprotokoll. Also etwa welche Matches man gewonnen und verloren hat und eine Möglichkeit, den Board-State beendeter Spiele noch einmal anzusehen. Diesen Artikel werde ich mir auch ansehen, und ich hoffe, dass er bald gepatcht wird.
Wenn du Protokolle ansehen möchtest, schau dir https://untapped.gg/en an. Ich habe mich ein wenig mit ihnen unterhalten, und im Grunde machen sie genau das, was du willst. Die meisten Informationen stammen aus dem MTG-Debug-Log im MTGA-Anwendungsverzeichnis, du kannst dir also auch selbst einen Tracker bauen, wenn du möchtest. Die Seite erklärt das ebenfalls: https://help.hearthsim.net/en/articles/3620440-how-do-i-supp...
Ich erinnere mich, dass es einige Apps gab, die mithilfe dieses Logs Tracking betrieben haben.