Der Werdegang von HearthstoneCalc hat einen eigenen Post verdient, in welchem dann weitere Ansätze (Monte Carlo Tree Search) vorgestellt werden. In diesem Blogeintrag geht es allerdings um das Injecten und Daten abrufen aus Hearthstone. Denn ohne Daten aus dem Spiel müssen wir HearthstoneCalc garnicht mehr weiterentwickeln.

Uns wird es zum Glück leicht gemacht. Hearthstone ist mit der Engine Unity3D geschrieben. Für Blizzard hat das den großen Vorteil, das Spiel einfach auf mobile Geräte (Tables und Smartphones, Android und iOS) portieren zu können. Für uns hat es den großen Vorteil, dass Unity .NET (genauer gesagt: Mono) verwendet. Und da die Binaries noch nicht einmal obfuscated vorliegen, haben wir ein relativ einfaches Spiel.

Der für Unity relevante Code wird in der Assembly-CSharp.dll gespeichert. Die Anzahl der Klassen überschreitet alles, was ich bisher gesehen habe. Dementsprechend fällt es am Anfang schwer, uns zurecht zu finden. Auch muss man sich zunächst an die Unity-Eigenarten gewöhnen: Jedes Objekt ist eine Entity, die wiederrum mehrere Unterentities haben kann. Oftmals haben Klassen Unterklassen, enthalten viel zu viel Renderlogik oder scheinen nie erzeugt zu werden.

Daher gilt zu klären: Welche Daten müssen wir alle Abrufen? Die Daten aus dem Spiel müssen in die Strukturen von HearthstoneCalc gebracht werden. Die wichtigste und größte Struktur ist hierbei die GameState-Klasse (Links). Sie enthält das Spielfeld mit den Monstern, die Karten des Spielers und die Infos über die jeweiligen Helden. Natürlich haben die Helden weitere Unterklassen, wie z.B. die ausgerüstete Waffe oder die gesetzen Geheimnisse. Auch Monster sind inzwischen komplexer geworden, denn sie können verschiedene Buffs besitzen und auf andere umliegende Minions Einfluss ausüben.

Die Klassen aus Hearthstone können wir nicht einfach übernehmen, denn sie enthalten viel zu viele Informationen. Diese Klassen sind nicht dafür ausgelegt, Millionen möglicher Boardzustände zu speichern. Zu diesem Problem werde ich nächsten Post über HearthstoneCalc noch mehr sagen.

Der große Vorteil von Mono ist natürlich, dass wir realtiv einfach .NET Code ausführen können. .NET Code in einem Programm ausführen? Klingt doch sehr nach CLR-Hosting!? Leider ist das nicht so einfach, denn die Unity-Klassen mögen es nicht, wenn sie außerhalb von mscorlib.dll Thread aufgrufen werden. Versucht man eine Unity-Funktion direkt aufzurufen, so erhält man folgende Fehlermeldung zu gesicht:

Weiterlesen

6 people like this post.

Like

Unlike

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.

Weiterlesen

8 people like this post.

Like

Unlike

Die GUI! Wofür interssierten wir uns überhaupt für die GUI? Die GUI mag zwar ein Randaspekt sein, aber 3 Gründe sind genug, dass wir eine Analyse vornehmen:

• Wir wollen später eine eigene Lobby schreiben, und dabei wenn möglich diese GUI Elemente wie Buttons verwenden
• Viele Werte, wie z.B. der nachher besprochene Mapname, tauchen zunächst nur in der GUI auf.
• Die GUI ist die Brücke zwischen Benutzer und Programm. Wenn wir wissen wollen, welche Funktion aufgerufen wird wenn ein bestimmter Button gedrückt wird, müssen wir wissen wie die Eventhandler für diesen Button aussehen. Und danach landen wir genau in der gesuchten Funktion (Beispiel: Neues Spiel Button -> Direkt beim Game-Konstruktor)

Anhand der GUI kann man schön sehen, wie OOP verwendet wurde. Alle Menüs erben von einem “Grundmenü”. Die Menüs implementierren die Funktionen wie zeichnen und handeln von Benutzereingaben, so dass eine schöne Kapselung entsteht. Und zum Wechseln des Menus wird einfach der Zeiger des aktuellen Menus aktualisiert, schon wird das nächste Menu angezeigt.

Beginnen wir mit etwas Code, der das Menu wechselt:

v4 = (int)this; // v4 ist das Register EBX
this->CurrentMenuIndex = a2; // Im Argument 2 wird übergeben, welche ID das neue Menu hat
v5 = v4->lpActualScreen; // Zeiger auf das aktuelle Menu Element
if ( v5 ) if (lpActualScreen != null)
{
    v7 = (int)((char *)&v5->dword4 + *(_DWORD *)(v5->dword4 + 4)); // dynamsichen Funktionszeiger holen
    (**(void (__thiscall ***)(_DWORD, _DWORD))v7)(v7, 1); // und aufrufen
}

Auch wenn der von IDA Pro erzeugte Code schrecklich aussieht, so kann man daraus einiges rauslesen. Fangen wir mit der ersten komischen Zeile an. Wieso speichert das Programm den this-Pointer in einer lokalen Variable (bzw genauer gesagt einem Register?). Da der This-Pointer in ECX übergeben wird, aber weitere Funktionen mit einem vielleicht anderen This-Pointer aufgerufen werden, wird der This-Pointer in EBX gespeichert. Das ist für die Funktionsscope nun der gesicherte This-Pointer. Nun wird das aktuelle Menu überprüft (lpActualScreen != null). Wenn ein Menu gesetzt ist, so wird in v7 ein Funktionszeiger geladen, der sich aus Werten des aktuellen Menus zusammensetzt. Im Anschluss wird die Funktion aufgerufen, und dies passiert dynamisch. Per IDA Pro kann man solche Calls nicht zurückverfolgen, per Debugger allerdings schon. In diesem Falle wird eine “Uninitialize”-Methode aufgerufen, die ein paar Aufräumarbeiten erledigt. Da jedes Menu andere Aufräumarbeiten zu leisten hat, ist auch die Funktion jeweils anders.

Weiterlesen

4 people like this post.

Like

Unlike

Grau, teurer Freund, ist alle Theorie, und Grün des Lebens goldner Baum. (Mephisto)

Diese Thorie wird, so leid es mir auch tut, den gesammten folgenden Artikel durchziehen. Man braucht ein paar Grundlagen, auf die man später zurückgreifen kann, wenn es richtig spassig wird. Diese Grundlagen sind zu vergleichen mit einem Bauplan: Woher sollten wir wissen, an welchen Schrauben wir drehen müssen und wie diese Aussehen, um ein bestimmtes Ziel zu erreichen?

Fangen wir mit den COM-Objekten, bzw genauer mit Interfaces und ihren “Virtual Tables” (VTables) an. Ein Objekt das von einem Interface erbt, ist gezwungen, die im Interface definierten Methoden zu implementieren (die Methoden zu “überladen”). Dabei kommen sog. Funktionszeiger zum Einsatz, die auf eine Funktionsaddresse zeigen. Von dieser Funktion ist der Prototype bekannt, also wird diese Adresse angesprungen, nachdem die bekannten Argumente auf den Stack gepushed wurden. COM-Interfaces sind spezielle Interfaces, die alle von IUnknown erben. Konkret bedeutet das, dass jedes COM-Objekt die 3 in IUnknown deklarierten Methoden “QueryInterface”, “AddRef” und “Release” implementiert. QueryInterface erstellt ein Interface, das einer IID entspricht. Im Post CLRHosting Reloaded wurde z.B. ein Interface vom Typ “IID_CLRRuntimeHost” erstellt, das uns wiederrum bestimmte Funktionen bereitgestellt hat. AddRef erhöht den Referenzcount, Release erniedrigt den Referenzcount und löscht das Objekt, falls dieser Null wird. Wichtig ist hier zu erwähnen, dass die VTable eines Interfaces, wenn es erstellt und gelöscht wurde, sich noch immer an der selben Stelle im Speicher befindet. In OllyDbg sieht ein solches Interface folgendermaßen aus:

Hier haben ein direkten Call eines Interfaces. Es handelt sich dabei (wie bei allen Interface Calls) um die sog. Thiscall-Convention, heißt im Register ECX wird ein THIS_POINTER übergeben, sonst werden die anderen Argumente normal auf den Stack gepushed. Nun wird CALL [ECX+80h] aufgerufen, was einem Funktionsaufruf in der VTable entspricht. Genauer gesagt die Funktion (80h / 4), also 20h oder 32. Im Dump-Window habe ich hier ECX geladen, was direkt der VTable entspricht. Die ersten 3 markierten Funktionen Funktionen ensprechen den Funktionen aus IUnknown (QueryInterface, AddRef, Release), in Orange ist die aufgerufene Funktion “Unlock” markiert. Schauen wir doch mal in die ddraw.h, in welcher alle unsere Interfaces deklariert sind.

Weiterlesen

11 people like this post.

Like

Unlike