Nehmen wir an, ich bin ein Spiel und ich habe eine globale int* , die meine Gesundheit enthält. Die Aufgabe eines Game-Trainers ist es, diesen Wert zu modifizieren, um den Gott-Modus zu erreichen. Ich habe Tutorials über Game-Trainer nachgeschlagen, um zu verstehen, wie sie funktionieren, und die allgemeine Idee ist es, einen Memory-Scanner zu verwenden, um die Adresse eines bestimmten Wertes zu finden. Dann ändern Sie diese Adresse, indem Sie eine DLL oder was auch immer einfügen.
Aber ich habe ein einfaches Programm mit einem globalen int* erstellt und seine Adresse ändert sich jedes Mal, wenn ich die App leite, so dass ich nicht verstehe, wie Spieletrainer diese Adressen hart codieren können? Oder ist mein Beispiel falsch?
Was vermisse ich?
Dies geschieht normalerweise, indem die Zeigerkette von einer statischen Variablen bis zur Heap-Adresse verfolgt wird, die die fragliche Variable enthält. Zum Beispiel:
%Vor%Wenn Sie in diesem Fall dem Ratschlag von mikek3332002 folgen und einen Haltepunkt innerhalb der Character :: hit () -Funktion setzen und die Subtraktion ausschließen, würde dies dazu führen, dass alle Charaktere, einschließlich Gegner, unverwundbar sind. Die Lösung besteht darin, die Adresse der "Spiel" -Variable zu finden (die sich im Datensegment oder im Stack einer Funktion befinden sollte) und allen Zeigern zu folgen, bis Sie die Adresse der Statusvariablen gefunden haben.
Einige Werkzeuge, z.B. Cheat Engine, haben Funktionen, um dies zu automatisieren, und versuchen, die Zeigerkette selbst zu finden. Vermutlich müssen Sie jedoch für kompliziertere Fälle auf das Reverse-Engineering zurückgreifen.
Der Wert, den ich finden möchte, ist die Anzahl der Leben, die mein Leben davon abhalten, auf 0 reduziert zu werden und das Spiel zu beenden.
Bekam dieses Muster aus dem Programm namens tsearch
Einige verwandte Websites, die aus der Recherche zu diesem Thema gefunden wurden:
Die Art und Weise wie Gameshark-Codes erkannt wurden, bestand darin, das Speicherabbild der Anwendung zu löschen, dann eine Sache zu tun und dann zu schauen, was sich geändert hat. Es mag einige Dinge geben, die sich ändern, aber es sollte Muster geben, nach denen man Ausschau halten muss. Z.B. Dump Memory, Shoot, Dump Speicher, Shoot wieder, Dump Speicher, neu laden. Dann nach Änderungen suchen und eine Vorstellung davon bekommen, wo / wie Munition gespeichert wird. Für die Gesundheit wird es ähnlich sein, aber viel mehr Dinge werden sich ändern (da du dich zumindest bewegen wirst). Es ist jedoch am einfachsten, dies zu tun, wenn die "externen Effekte", z. Versuchen Sie nicht, während eines Feuergefechts Speicherauszüge zu unterscheiden, weil viel passiert, machen Sie Ihre Diffs, während Sie in der Lava stehen, oder fallen Sie von einem Gebäude oder etwas dieser Art.
Die Erkennung der Zugriffszeiger ist ziemlich beschwerlich und statische Speicherwerte sind schwierig an verschiedene Compiler oder Spielversionen anzupassen.
Beim API-Hooking von malloc (), free () usw. gibt es eine andere Methode als die folgenden Pointer. Die Discovery beginnt mit der Aufzeichnung aller dynamischen Speicherzuordnungen und der Speichersuche parallel. Die gefundene Heap-Speicheradresse wird dann rückwärts mit den aufgezeichneten Speicherzuordnungen abgeglichen. Sie lernen die Größe des Objekts und den Offset Ihres Wertes innerhalb des Objekts kennen. Sie wiederholen dies mit Backtracing und erhalten die Sprungcodeadresse eines malloc () -Aufrufs oder eines C ++ - Konstruktors. Mit dieser Information können Sie alle Objekte verfolgen und ändern, die von dort zugewiesen werden. Sie entladen die Objekte und vergleichen sie und finden viel interessantere Werte. Z.B. Der universelle Elite-Spieltrainer "ugtrain" macht es so unter Linux. Es verwendet LD_PRELOAD. Anpassung funktioniert durch "objdump -D" -basierte Disassemblierung und nur Suchen nach dem Bibliotheksfunktionsaufruf mit der bekannten Speichergröße darin.
Siehe: Ссылка
Ugtrain-Quelle: Ссылка
Der malloc () Haken sieht so aus:
%Vor%Wenn sich die gefundene Speicheradresse jedoch innerhalb der ausführbaren Datei oder einer Bibliothek im Speicher befindet, ist ASLR wahrscheinlich die Ursache für die Dynamik. Unter Linux sind Bibliotheken PIC (positionsunabhängiger Code) und bei den neuesten Distributionen sind alle ausführbaren Dateien PIE (positionsunabhängige ausführbare Dateien).
EDIT: Egal, es scheint, es war nur Glück, aber die letzten 3 Zahlen des Zeigers scheinen gleich zu bleiben. Vielleicht tritt ASLR ein und ändert die Basisbildadresse oder etwas?
aaahhhh, mein Fehler, ich habe% d für printf verwendet, um die Adresse und nicht% p auszudrucken. Nach der Verwendung von% p blieb die Adresse gleich
%Vor%Tags und Links pointers memory-address