CE zeigt keinen "Module-Offset"

[iNvIcTUs oRCuS]

Hab jetz zwar keinen Zugriff zum Rechner aber ich versuchs mal so zu erklären...
Ist eigentlich ganz simpel. Ich hab mir als Beispiel die Health Bar der bzw. eines Gegners vorgenommen. Den Wert also schnell gesucht und dann danach gesucht durch welchen Befehl dieser beeinflusst wird. Dabei kommt eben raus das dieser in einem reservierten Speicherbereich liegt. Jetz hab ich also den Anfang, die Basis, dieser Region genommen und das Offset hinzuaddiert um zu meinem Befehl zu kommen. Jetz einmal das Spiel neugestartet und die ganze Prozedur nochmal wiederholt, aber was jetzt, das Offset zum Befehl stimmt nicht bzw. ist diesmal ein anderes. Also noch mal zurück auf Anfang...
Nehmen wir jetzt einfach mal die Basis dieser Memory Region... Diese Adresse suchen wir jetzt mit Cheat Engine. Und rauskommt dabei ein Offset innerhalb der "mono-20.dll". Dieses Offset innerhalb dieser DLL ist statisch. Das heißt also man brauch nur diesen Pointer auslesen und man hat die Basis dieser Memory Region. Und da die Größe dieser Region immer gleich ist, ist auch der maximal zu durchsuchende Speicherbereich gegeben. Die Größe der Region war, das muss ich dazusagen, bei mir zumindest immer 0x1010000h.

Ansonsten kann man bei den Karten die direkten Pointer suchen, bei einen One Hit Cheat würde das allerdings ins uferlose ausarten...

Ihr könnts ja jetz mal selbst versuchen, ansonsten erkläre ich das morgen mal anhand von Screenshots wenn ich wieder zugang zum Rechner hab.

Gesendet von meinem Samsung Galaxy S4 mit TapaTalk

[DerBaum]

Habs mir nicht angeschaut aber er meint bestimmt den Speicher zwischen zwei Modulen (wobei ich da vorsichtig wäre, ich habe auch schon erlebt das sich dies nach Patches ändern kann). Oder auch was ganz neues :-)

//edit: Hm, die Base durch Pointer. Keine schlechte Idee. Wobei ich bei solchen Spielen lieber Abstand von Pointer nehmen würde, speziell wenn diese in der mono.dll liegen. Auch wenn das nach dutzenden Tests immer noch stabil läuft, so kann das auf nem anderen System schon wieder falsch liegen.

Das mit der Größe aber stimmt, habs sogar vergessen gehabt. Das ist auch eine Möglichkeit die Regions zu selektieren (einfach alle Regionen die nicht der Größe entsprechen umgehen).

Aber da wir diesen Aufwand nur führen, weil DNA meinte es dauere ihm zu lange mit seinem AOB würde ich lieber auf mein Vorschlag mit Asynchronität zurückgreifen. Besonders wenn man wie ich, jeden Tag mit mono games zu tun hat spart das mehr Zeit, als jedes Mal die Größe zu überprüfen oder Pointer neuzusuchen. Durch die Threads ist die Anzahl der scans nämlich wurscht, da dauern 30 Scans solange wie 1 Scan normal bei dir dauern würde.

[iNvIcTUs oRCuS]

Da biste vollkommen auf dem Holzweg...
Meine Beweisführung ist hieb und stichfest...
Wie gesagt, basiert auf Pointer. Und das diese sich nach einem Update ändern is auch klar. Dennoch ist diese Methode imner noch allemal besser als den gesamten Speicher zu durchsuchen... Oder eben man nimmt die direkten Pointerpfade zum besagten Wert. Macht aber wie gesagt nur Sinn bei einzelnen Werten und ist definitiv nicht geeignet um einen One Hit Cheat zu realisieren...

Gesendet von meinem Samsung Galaxy S4 mit TapaTalk

[DerBaum]

Ich dürfte inzwischen weit über 50 auf Mono basierende Spiele bearbeitet haben und kann dir versichern: Pointer sind nicht immer zuverlässig, auf diesem Gebiet, wohl bemerkt. Wie gesagt, ich habe mir das Spiel vom OP nicht angesehen und in diesem Fall magst du Recht haben, das will ich dir auch nicht nehmen.

Aber so wie ich das verstanden habe, sprachen wir zuletzt über Mono Spiele im Allgemeinen und da würde ich ein ganz normalen Aobscan machen, wem das zulange dauert macht es eben mit Threads und DNAs scan dauert eh nur maximal 7 Sekunden um den ganzen Speicher einer 32 Bit executable zu durchsuchen.

Und nehmen wir an, deine Pointermethode verkürzt den Aobscan auf 1-2 Sekunden. Macht bei 5 Aobscans schon 10 Sekunden, hingegen meine Methode bleibt bei 7 Sekunden durch Threads immer noch bei 7 Sekunden. Der Aufwand den Pointer neuzusuchen nicht mitinbegriffen.

Beweisführung abgeschlossen.

[DNA]

(10.02.2014, 21:58)iNvIcTUs oRCuS schrieb: 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...

Zum Glück hast du das geschrieben, denn sonst hätte mich der Ehrgeiz auch nicht gepackt

Hab dann gestern Abend auch nochmal nen bissl rumprobiert und lese nun die speicherbereiche aus, die die Kriterien (also Größe, State und Protection) für den speicherbereiche erfüllen, den ich für meinen Trainer benötige.
Dann überprüfe ich einige Offsets, um wirklich sicher zu gehen, dass es der richtige Bereich ist und anschließend nen AOBScan auf diesen Bereich.
Der ganze Spaß dauert nunmehr 1 sek
Also danke für diesen Denk-/Ehrgeizanstoß


Gesendet von meinem iPhone mit Tapatalk

[iNvIcTUs oRCuS]

So, also wie gesagt hier mal noch ne Ausführung dazu wie man zu dem Basispointer kommt...
Ausgehend davon ist, wie ich schon schrieb, die Realisierung eines One Hit Cheat. Hat man die Adresse eines Health Wertes eines Gegners gefunden kommt man z.B. zu dieser Codestruktur...
   

Sucht man jetzt nach der Basisadresse dieses Speicherbereichs, in meinem Falle die 0x82F0000h, dann findet man diese innerhalb des Speichers der "mono-2.0.dll". Zur Veranschaulichung hab ich auch mal nen kompletten Screenshot angefertigt dieser ist eigentlich soweit selbsterklärend...
Das Offset innerhalb der "mono-2.0.dll" ist relativ zur Basis immer gleich. OllyDBG zeigt hier nur absolute Adressen, aber zum genauen Verständnis - Das Offset innerhalb der "mono-2.0.dll" ist immer: mono-2.0.dll+266730.


Aber auch in diesem Fall wird dieser Speicherbereich erst reserviert wenn man ein Level betritt. Folglich wird auch nach Beendigung eines Levels dieser Speicherbereich wieder freigegeben...
Für die verfügbaren bzw. eingesammelten Kokosnüsse könnte man aber z.B. noch folgenden Pointerpfad nutzen:
[[[[mono-2.0.dll+002665A0]+180h]+334h]+0h]+1Ch

grEEtZ iNvIcTUs oRCuS

[DerBaum]

Und das beweist nun genau was? Das du einen gültigen Pointer für ein Spiel gefunden hast? Es beweist aber noch lange nicht, dass Pointer bei Mono Spielen eine akzeptable Wahl sind geschweige denn, dass diese Methode immer Gültigkeit beweist.

Blackguards
Might & Might Legacy

beide benutzen Mono und bei beiden Spielen klappt deine Idee nicht. Selbstverständlich steht es dir frei dir beide Spiele anzusehen und zu zeigen, dass ich mich irre.

Oder um es dir noch einfacher zu machen, nimm irgendein anderes Spiel was auf Mono aufbaut und versuch das ganze zu reproduzieren.

[iNvIcTUs oRCuS]

Ich habe auch nicht behauptet das des bei allen Spielen so ist.
Natürlich kann das sein das dass bei anderen Spielen nicht so ist, es geht hier ja lediglich um einen Lösungsansatz. Und der ist, das musst de zugeben, excellent angesetzt...
Und um deine Frage zu beantworten was das beweist?! Das es sehr wohl Spiele gibt die mit Pointern um einiges auch einfacher zu lösen sind.
Aber im Enddefkt ist alles nur Ansichtssache, der User der einen Trainer nutzen will kümmert sich nicht drum wie dieser funktioniert. Hauptsache ist, das er funktioniert.

Das ist im Endeffekt genau dasselbe wie mit den Tutorials...
Ein Neuling liest diese und denkt nun das jene Tutorials 1:1 auf alle Spiele umzusetzen sind...

EDIT//
Das Spiel, Might & Magic: Legacy, hab ich mir schon etwas länger bei STEAM gekauft.
Hab mir das dort auch mal schnell angesehen. Ich weiß nicht wo dein Problem is...
Bei diesem Spiel funktioniert das genauso gut...
Das heißt mit anderen Worten - Ja, meine Idee klappt dort genauso tadellos...

[DerBaum]

Du sprichst von einfach. Was ist an deiner Methode einfacher gegenüber einem Aobscan? Nichts. Bei einem Aobscan muss ich nur die FUnktion finden, habe dnan automatisch die neuen Bytes. Bei einem Pointerscan (der bekanntlich länger dauert) muss ich erst noch aussieben, filtern, mir eventuell die neue Adresse in der Mono.dll suchen und auch da muss der Code erst erstellt worden sein, bevor es funktioniert.

Wenn du dich nun nicht im allgemeinen auf die Spiele beziehst sondern ihm nur ein Lösungsansatz geben möchtest, dann würde ich doch lieber einen nehmen mit dem derjenige auch in anderen Spielen weiter kommt (gerade auch im Bezug auf dein Hinweis mit den Neulingen). Dein Lösungsansatz ist wirklich nicht schlecht (wenn er denn funktioniert), aber klingt für mich eher nach Fortgeschritten / Plan B.

So genug gemeckert, nichts desto trotz ist es immer gut mehrere Lösungsansätze parat zu haben insofern hat deine Idee natürlich ihre Daseinsberechtigung, muss man schon so sagen.

[iNvIcTUs oRCuS]

Das seh ich ein bissl anders...
Ich habe auch nicht behauptet das die AOB Scan Methode in diesem Fall sinnlos is. Ganz im Gegenteil.
Ich würde auch nicht behaupten das dass ein möglicher Plan B is. Denn warum soll ich denn erst nach einem Pointer scannen und filtern?
Is doch quatsch. Ich weiß doch wo sich der Pointer befindet. Die Adresse, die die Basis des reservierten Speicherbereiches enthält is doch statisch. Wozu soll ich da erst nach dem richtigen Pointer scannen und filtern? Der Pointer auf diesen Speicherbereich ist eindeutig.
Das der Code erst erstellt sein muss ist schon klar. Dieses Problem haste aber auch beim AOB Scan. Wenn der Code noch nicht erstellt wurde, dann nützt dir auch der AOB Scan nichts weil dieser auch ins Leere schießt.
Ich behaupte ja nicht das meine Methode einfacher is. In dieser Hinsicht ist ein simpler AOB Scan am einfachsten, keine Frage. Aber mit meiner Methode suche ich die Bytesequenz gezielt in dem Speicherbereich in dem diese auch zu finden ist. Ich seh sozusagen nicht ein warum ich erst den gesamten adressierten Speicherbereich nach der entsprechenden Sequenz durchsuchen soll?!

Oh man, ich höre mich schon an wie maluc.
Hey maluc, wenn du das hier liest...

Nachtrag...
Natürlich ist die Pointergeschichte nur für die jeweilige Version aktuell. Bei einem Update muss ich aber dennoch nur die Adresse des Pointers raussuchen. Aber das dauert bei weitem nich solange wie du's vielleicht annimmst.
Einen AOB Scan nehm ich in der Regel nur wenn ein Spiel sehr häufig upgedated wird und dementsprechend auch die Bytes gleichbleiben. Deswegen liegt momentan auch mein Van Helsing Projekt auf Eis. Dieser Trainer nutzt ebenfalls die AOB Methode, nützt allerdings nichts wenn die Codes sich nahezu mit jeder Version imer wieder verändern...