Signature/Pattern Scanning mit VB.NET

[iNvIcTUs oRCuS]

Naja...
Ich behaupte ja nicht das es immer so schwierig ist. Im Gegenteil... Es ist relativ häufig das solch ein Trainer für mehrere Versionen funktioniert.
"Van Helsing" ist eher auch ein krasses Beispiel dafür das solch ein Trainer höchstens für 3 oder 4 Updates funktioniert.
Liegt aber wohl auch daran das bei dem Spiel eine hohe Updatefrequenz herrscht.
Aber ich sage mal so, solange wie Du deinen Trainercode variabel aufbaust hast Du's auch mit Updates leichter.
Ich z.B. habe von sämtlichen Trainer Sourcecodes ein Backup auf der Platte. Wenn jetzt z.B. nach nem halben Jahr wieder mal ein Update zu einem Spiel rauskommt dann nehme ich den Sourcode des Trainer zur vorherigen Version des Spiels und passe innerhalb des Sourcodes nur die Offsets an und das wars dann auch schon. Das is im Endeffekt ne Sache von nicht mal 5 Minuten + Testen des fertigen Trainers zur neuen Version. Sagen wir mal alles in allem ca. 15 Minuten. Probleme oder Bugs durch den Trainer die nach stundenlangem spielen auftreten/können werden eh hauptsächlich nur durch die Community identifiziert.

Meinen ersten Trainer hab ich so geschrieben das ich jedes Offset explizit benannt/verwendet hab (im Sourcecode). Aber mittlerweile hab ich im Trainercode ne Sektion für die Initialisierung von Variablen angelegt. Somit brauch ich eben die Offsets nur einmal eintragen und alles weitere findet seine Bestimmung - Wie, wo und welche Variable Verwendung findet eben.

EDIT//
Ja und was Acubra meint...
Häufig sind ja die Befehle so aufgebaut das zu einem Wert eines Registers ein anderer Wert hinzuaddiert wird. Und dieser entgültige Wert stellt dann den Pointer auf einen Speicherberich dar der dann letztenendes ausgelesen/beschrieben wird.
Z.B. die Bytefolge "D9 9E 2C 03 00 00"
[code=ASM]fstp dword ptr [esi+32C][/code]

Wenn nun also nach einem Update aus dieser Bytefolge beispielsweise "D9 9E FF 00 00 00" wird...
[code=ASM]fstp dword ptr [esi+ff][/code]
dann ist der Witz schon wieder weg wenn man eben explizit nach der Bytefolge "D9 9E 2C 03 00 00" suchen würde.

[Anunymux]

Ja wie gesagt, das habe ich nicht so "locker" hinbekommen^^

Ich habe in meinem ersten Post ja mal die Funktion gepostet, die ich von c# zu VB.NET umgewandelt habe. Die kann auch mit Wildcards umgehen...aber es funktioniert einfach nicht.

@ iNvIcTUs oRCuS

Genau so habe ich das bei mir auch gemacht. Ich habe eine Region erstellt, in die alle Offsets reinkommen und mit den Variablen wird dann im Programm weitergearbeitet.
Du hast also bei dir trotzdem so eine Pattern Suchfunktion? Wie schnell ist die bei dir? Die im Trainermodul liest ja jedes Byte einzeln aus, was dazu führt, dass das mal gut und gerne 10 Sekunden dauert.

[Acubra]

(28.11.2013, 20:02)Anunymux schrieb: Du hast also bei dir trotzdem so eine Pattern Suchfunktion? Wie schnell ist die bei dir? Die im Trainermodul liest ja jedes Byte einzeln aus, was dazu führt, dass das mal gut und gerne 10 Sekunden dauert.

Hey,
wenn deine nicht funktioniert dann barbeite doch die aus dem Trainermodul. So das eben nicht jedes Byte einzeln eingelesen wird.

[iNvIcTUs oRCuS]

Bedingt dadurch das ich nur die Code Section nach Bytefolgen durchsuche geht das suchen auch sowas von fix... Da wird mir selbst ganz schwindelig
Wie schnell, wüsste ich jetzt garnicht. Bin noch nicht auf die Idee gekommen das mal zu messen. Aber 10 Sekunden brauch ich bei weitem nicht.

[Anunymux]

Kannst du deine Funktion bitte einmal zeigen?

Das wäre super. Du würdest damit nicht nur mir einen Gefallen tun

[iNvIcTUs oRCuS]

In Delphi wird dir das genauso wenig helfen...

[Anunymux]

Das ist wohl wahr ^^

[DNA]

Das mit der Trainerupdaterei handhabe ich genauso
wie invictus (hätte beinahe silent geschrieben ^^)

Ich habe meine Funktion gerade mal getestet,
Startadresse = Baseadresse vom Prozess, also 400000
Bytesequenz = 62 00 6C 00 69 00 63 00 00 00 00 00 54 00 61 00 67 00 49 00 6D 00 70 00 00 00 00 00 54
Gefunden bei = F00000
Zeit = weniger als 1 Sek.

Wie invictus schon schrieb, reicht es in den meisten Fällen nur eine
Codesection zu durchsuchen, bei VB hatte ich allerdings folgendes Problem...
wenn die Section zu groß ist, hat er nur noch nullen ausgelesen, darum
musste ich auf die Methode mit größeren Bereichen zurück greifen.

Du musst erstmal dafür sorgen, dass nicht jedes Byte einzeln ausgelesen wird.
Anschließend musst du die SigScan Funktion anpassen.

EDIT:
Wie ich gerade gesehen habe, wird bei der SigScan Funktion auch nur die CodeSection vom Prozess ausgelesen ... solltest du das ganze an einem Spiel
testen, bei dem sich die Bytesequenz außerhalb dieser Sektion befindet, wird
eine 0 ausgespuckt.