Home of Gamehacking - Archiv

Hi,

ich hab nochmal ne Frage die zZ desöfteren auftritt:

Nachdem ich erfolgreich den Punkt zum Injecten gefunden hab und meine Codecave ansetzen will bemerk ich immer wieder mal, dass meine "Address" nicht im gewohnten "Module+Hexoffset" Format aufzufinden ist, auch bei aktivierter "Show module addresses" Option.
Wie ist dann hierbei das weitere Vorgehen um den Relativen Offset zu erhalten?

Beispiel:


Danke im Vorraus

bliZZarD

PS:
Nach einigem Googlen das hier gefunden:
http://www.cheatengine.org/forum/viewtop...?p=5191328

Alsooo keine Möglichkeit das zu "fixieren"?

Aus der Ferne würde ich jetzt einfach mal drauf tippen das dass Offset bzw. deine Adresse sich in einem reservierten Speicherbereich befindet. Da dieser nicht innerhalb der EXE oder einer DLL referenziert ist gibts dazu natürlich auch keinen Modulnamen...
Die letzten Spiele von denen ich weiß die mit "Allocated Memory" arbeiten waren:
- Hell Yeah! Wrath of the Dead Rabbit
- Cities in Motion 2
- Demantium II HD


EDIT//
Um welches Spiel handelt sich denn überhaupt?

Solche Spiele sind wahnsinnig beliebt bei Trainer Codern. Wenn du Glück hast, dann setzt das Spiel nur auf Mono / Unity Engine. In diesem Fall musst du die Stelle bei jedem Start erneut suchen (Stichwort: Aobscan). Da der Code allerdings ist 99% der Fälle auch noch automatisch erstellt wird, darfst du erst nach den Array of bytes suchen, wenn der Code erstellt wurde (musst du ausprobieren. Bei Funktionen die werte schreiben [find out what writes to] muss der Beitrag aller warscheinlhckeit nach mindestens 1x geschrieben worden sein).

Wenn du richtig Pech hast bekommst du es mit abhängigen Frameworks zu tun (C# als Beispiel). Der Code wird hier in Abhängigkeit des installierten Frameworks erstellt. Hier kannst du selbst den Aobscan vergessen bzw. du musst schauen welche Frameworkversion bei dir installiert ist und das den Leuten sagen (wenn du den Trainer public machen willst).

Wow Leute, erst mal danke für die Antworten!

Bei dem Spiel handelt es sich um "Go Home Dinosaurs!" [Steam]
Is ja echt scheisse, dachte da gäbe es ne einfachere Methode, aber so wies aussieht nicht :/

Sieht so aus als müsste ich mich dann mal wieder mit aobscan befassen und mal schauen ob was draus wird.

Vielen dank für die Antworten, echt Super wie einem hier schnell geholfen wird

In CE 6.3 gibt es im AA oben in der Menüleiste nen Template für Aobscan scripts. Wenn du nicht wie das geschrieben wird schau mal im Tables-Bereich nach, neuerdings sind viele davon mit AOBscans geschrieben.

Wenn das für dich selbst ist, kannst du dir auch als Kommentar im Script die Bytes speichern und dann eben bei jedem Start neusuchen (wobei das mit einem richtigen Aobscript natürlich wesentlich einfacher ist).

Der Nachteil an dieser ganzen Aob Geschichte ist, dass es sehr sehr schwer wird viele Features einzubauen. Stichwort: Updates. Bei einem normalen Spiel schiebst du einfach alle AOB durch ein Programm und bekommst die neuen Offsets (mit einem Klick, vorausgesetzt man coded sich so etwas), bei einem Spiel mit dynamischen Bereichen musst du eben alles neusuchen. Dummerweise haben diese Games dann auch nur selten eine feste Playerbase, d.h. pro Funktion ein Script (was mich wieder zum o.g. bringt).

In anderen Worten: Konzentriere dich bei diesen Spielen auf das Wesentliche und mach ein einfaches Script. Und immer schön darauf achten, dass es zum Aob nur EIN Treffer gibt (dein Code).

Neben dieser Aob-Geschichte gibt es noch andere Möglichkeiten, gerade bei Mono/Unity Spielen, welche in der Regel bereits ein Developer/Cheat Menü implementiert haben. Aber das würde den Rahmen sprengen.

Ja, dass ist alloctated Memory .... und ich hasse diesen scheiß, da meine Vb Trainer
zu lange brauchen für den bytepatternscan
Da bleibt dir die entweder nen aobscan, wie DerBaum schon schrieb, oder du findest
nen anständigen Pointer, mit dem du zugriff auf deinen opcode hast (eher selten (fast nie))

Pointer kannst du in diesem Fall vergessen, da die alle auch keine base haben.
@DNA: Schreib den Scan um als async, bei meinem Offset Tool brauch er bei >21 Funktionen weniger als 3 Sekunden, da er die AOBs einfach parallel sucht. Außerdem kannst du auch memory regions skippen (z.B. die, welche eine base haben.) aber eigentlich ist deine Funktion schon ziemlich schnell und mit Async unschlagbar.

(09.02.2014, 02:34)DerBaum schrieb: [ -> ]Pointer kannst du in diesem Fall vergessen, da die alle auch keine base haben.

Das stimmt allerdings nur zur Hälfte bzw. muss nicht gänzlich so sein...

Demantium II HD setzt auch auf den reservierten Speicher, allerdings kommt man da leicht per Pointer innerhalb der Mono.dll ran.
Wenn de Glück hast, dann könnte das auch bei diesem Spiel der Fall sein. Es kann zumindest nicht schaden mal per Pointer sein Glück zu versuchen...

Auf diese Weise siehts zwar bei Demantium zuerst bescheiden aus, aber per Pointer hat man das Dingens im Handumdrehen gelöst...


EDIT//
Also ich hab mir das mal schnell angesehen...
Das Spiel ist ähnlich aufgebaut wie ich das schon bei Demantium gesehen habe...
Per Pointer lässt sich z.B. prima bei den Karten bzw. Kokosnüssen bescheißen...
Aber - Dieser Speicherbereich wird erst reserviert wenn man sich in einem Level Level befindet.
Aber man könnte z.B. den Trainer so aufbauen das durch den Trainer selbst zum Levelanfang eine gewisse Anzahl an Kokosnüssen gesetzt wird.

Ein bissl hat mich jetzt aber auch der Ehrgeiz gepackt.
Hab mir das Spiel nochmal angesehen und es gibt sogar per AOB Scan eine einfache Möglichkeit um nur den bestimmten, reservierten Speicherbereich zu durchsuchen in dem sich die entsprechenden Offsets befinden...
Somit brauch man nicht den kompletten Speicher von 0x00000000h bis 0x7FFFFFFFh nach den entsprechenden Byte Sequenzen zu durchsuchen...

Na dann spann uns doch nicht so auf die folter
Würde mich nämlich auch interessieren