Reverse Engineering: Typisierte Dateien

[Zerolith]

Hallo,

Also, angenommen ich habe eine Typisierte Datei vor mir liegen. Mit einer Struktur die ich nicht kenne. Wie würde man vorgehen um ein Programm zu schreiben dass die Datei einlesen kann.

Irgendwie muss das doch möglich sein? Sieht man z.B. bei Savegame Editoren für Spiele.

Vorallem frage ich mich wie man das bei Strings macht die LÄNGER als 255 Zeichen sind. Kann man davon ausgehen dass einer der vorherigen Wert die Länge angibt?

Ich weiß ja nicht, in einem Hexeditor sieht man das m.e. nicht soooo toll.

Wie würdet ihr das machen?

gruß,
Daniel

[dizzy]

Zitat:

Zitat von Zerolith

Hallo,

Also, angenommen ich habe eine Typisierte Datei vor mir liegen. Mit einer Struktur die ich nicht kenne. Wie würde man vorgehen um ein Programm zu schreiben dass die Datei einlesen kann.

Irgendwie muss das doch möglich sein? Sieht man z.B. bei Savegame Editoren für Spiele.

Entwickler von Savegame-Editoren gehen imho so vor, dass sie unzählige Spielstände speichern, je mit nur einer kleinen protokollierten Änderung. Die Änderungen die das am Savegame nach sich zieht wird analysiert, und so kommt man nach und nach der Wahrheit näher.
Je nach Komplexität eines Spiels und nach können das Savegame möglichst geschickt aufzubauen, kann das schon erheblicher Aufwand werden!

Zitat:

Zitat von Zerolith

Vorallem frage ich mich wie man das bei Strings macht die LÄNGER als 255 Zeichen sind. Kann man davon ausgehen dass einer der vorherigen Wert die Länge angibt?

Nö. Üblich ist, dass ein "binär" gespeicherte String mit chr(0) abgeschlossen wird. Wo er beginnt bestimmen allein die vorhergehenden Strukturen. Aber das muss nicht immer so sein. Es kann ja jeder seine Strings speichern wie er will.

Zitat:

Zitat von Zerolith

Ich weiß ja nicht, in einem Hexeditor sieht man das m.e. nicht soooo toll.

Trotzdem ist es fast dein einziger Freund bei deinem Vorhaben ;)

Zitat:

Zitat von Zerolith

Wie würdet ihr das machen?

Erstmal 2 Monate Urlaub nehmen... :mrgreen:


Gruss,
Fabian

[Zerolith]

Danke für die Hinweiße, machst mir ja mut *G*

[MrSpock]

Hallo Zerolith,

wenn du das Format grundsätzlich kennst, kannst du mit TFileStream oder einfach mit BlockRead die Daten lesen und dann gemäß deiner Analyse zerlegen.

[Zerolith]

Also ich bin es "gewohnt" eigene Dateien in einem Objekt bzw. Record zu definieren und dann via FileStream das ganze
zu Speichern (Stream.Write....).

Bei Strings mache ich das meistens so:

Delphi-Quellcode:

TMeineDatei = record
  ...
  _String : String;
  ...
end;

...

var fs : TFileStream
begin
  fs := TFileStream.Create('datei.txt');
  fs.Write(Length(Record._String), SizeOf(Integer));
  fs.Write(Pointer(Record._String)^, Length(Record._String));
  ...
end;

wegen der Zeile

Delphi-Quellcode:

  fs.Write(Pointer(Record._String)^, Length(Record._String));

wurde ich schonmal gefragt warum ich das so mache es sei doch das selbe wie

Delphi-Quellcode:

  fs.Write(Record._String), Length(Record._String));

kann ich nicht sagen... so wie ich es mache funktioniert es in 100% der fälle - anders bekomm ich gelegentlich ne zugriffsverletzung.

BTT:

Ist es mit dieser Variante immer möglich eine Typisierte Datei auszulesen (vorrausgesetzt die Struktur ist bekannt)? Oder gibt es verschiedene Varianten die Datei zu spiechern / laden?

Danke, Daniel


[Edit: mein deutsch verbesser ^^]

[dizzy]

Typisierte Dateien in dieser Form sind eigentlich nicht so sehr üblich. In der Regel unterteilt man Daten in sog. "Chunks", also großere Abschnitte die durch irgendwelche Header-Strukturen eingeleitet werden. Eine andere Variante ist es die Offsets direkt mit einer Bedeutung zu belegen, was allerdings sehr statisch und unschön ist. Eine andere Möglichkeit ist es eine Art TOC (Tabel of Contents) im Header anzulegen, wo dann verzeichnet wird an welchem Offset welche Informationen zu finden sind.

Die Variante mit Chunks ist aber meiner Beobachtung nach recht beliebt, da sie sehr variabel ist, und sehr performant gestaltet werden kann. Innerhalb eines Chunks hat man es dann wiederum meist mit mehr oder minder statischen Strukturen zu tun. Oftmals ist es auch so, dass ein Datum allein auf Grund seiner Position relativ zu einem anderen Datum seine Bedeutung erst erhält. Sprich: Jemand (der Programmierer) definiert: 4 Bytes nach dem Wert für X, steht der Wert für Y. Sein Typ sei Integer.

Womit wir zum nächsten Kapitel kommen: Welcher Typ von Daten liegt überhaupt vor? In der Datei stehen einfach nur Werte. Wie sie zu interpretieren sind ist völlig unklar, solange man nicht die Spezifikationen hat. So kann ein Byte auch ein Char sein, oder nieder- oder höherwertiges Byte eines Words usw.. Apropos Byte-Wertigkeit: Little-Endian oder Big-Endian? Das ist die Frage! Da hilft dann oft nur eine Plausibilitätsprüfung - also wie interpretiert sieht der Wert wahrscheinlich richtig aus?

Ein gut dokumentiertes Format dass in Chunks organisiert ist, ist das WAVE-Format (www.wotsit.org). Daran erkennt man schnell, dass man ohne Doku nur sehr sehr schwer erkennen kann was was bedeutet.


Was du vor hast erfordert eine Menge an Erfahrung zu diversen Techniken in Sachen Datenverwaltung, eine Menge an Zeit, Frust-Resistenz ;) und akribische Kleinarbeit. Und dass man wirklich alles raus bekommt ist eher selten der Fall.

Ich will dir ja nicht den Wind aus den Segeln nehmen, aber schon darauf hinweisen dass das u.U. nichts wird. Auch die meisten Savegame-Editoren beschräken sich auf die Abschnitte die von Bedeutung sind, bzw. ergibt sich deren Funktionalität daraus, was man geschafft hat zu identifiziren. Der Rest wird schlicht missachtet.
Und wenn du jetzt einen GANZ gemeinen Programmierer hattest, dann werden Informationen in das gesamte File verteilt ;). So könnte man ja einen Integer in seine 4 Bytes zerlegen, und diese irgendwo einsteuen, und vorher sogar umrechnen, so dass man den Wert als solchen garnicht mehr erkennt. In Spielen in denen Geld wichtig ist, könnte man z.B. einfach den Geldwert mit einer Formel verrechnen, so dass du, auch wenn du die richtigen Stellen im Savegame findest, den Wert darin nicht als deinen Geldbetrag wiedererkennst, da der ja eigentlich ganz anders war. Nur das originale Programm weiss was zu tun ist, um den Wert richtig zu interpretieren. Und schon hat man dich genatzt :D.
Zum Glück aber machen sich wohl nicht viele die Arbeit dass so zu "verschlüsseln". Bei Games kann das aber durchaus schon mal sein, um Cheatern den Garaus zu machen (richtig so!).


Letztlich musst du es einfach mal probieren um abschätzen zu können wie umfangreich und kompliziert das ganze wird. Am besten ganz klein anfangen - z.B. bei einem Spiel den Ausgangszustand speichern, und dann einen Schritt nach vorne. Wieder speichern, und die Bits um die sich die beiden Savegames unterscheiden haben schon mal sehr wahrscheinlich etwas mit der Spielerposition zu tun.


Gruss,
Fabian

[Hansa]

Es ist davon auszugehen, daß die Daten alle hintereinander liegen und die Datensatzlänge gleich ist. Hast du das Programm, welches die Daten verwaltet wenigstens ? Falls nicht, dann vergesse das am besten. Oder wie schon gesagt, 2 Monate Urlaub dafür verwenden.

Ist das Programm vorhanden, so versuche herauszufinden, wieviele Datensätze vorhanden sind. Also Filesize / Anzahl DS. Hierbei ist zu bedenken, daß intern eventuell zumindest ein Datensatz 0 vorhanden ist, den das Programm nicht anzeigt. Tja und dann geht das Stückwerk eben weiter. :mrgreen:

[mirage228]

Hi,

mal angenommen es wäre ein Spiel.

Könnte man die Struktur des Savegames (also der "typisierten Datei") nicht herausfinden, wenn man mit einem Disassembler die Speicher-Methoden des Spieles untersucht? :?:

mfG
mirage228

[dizzy]

Mit den Datensätzen muss man aber aufpassen. Die gibt es nämlich in dieser Form nicht immer, bzw. sogar mittlerweile eher selten. Je nach Alter des Formats hat man es häufiger mit variablen Strukturen zu tun, als mit statischen Satzlängen. Das wäre dann z.B. eine der aller ersten "Amtshandlungen": rauszufinden welche Grundstruktur denn überhaupt zu Grunde liegt.

[dizzy]

Zitat:

Zitat von mirage228

Hi,

mal angenommen es wäre ein Spiel.

Könnte man die Struktur des Savegames (also der "typisierten Datei") nicht herausfinden, wenn man mit einem Disassembler die Speicher-Methoden des Spieles untersucht? :?:

mfG
mirage228

Mit viel viel Ahnung und Vollplan in ASM vielleicht. Man muss aber erst mal die Stellen identifizieren. Gerade Spielemachern liegt oft am Herzen dass man da nicht so einfach selbst dran rumfummeln kann.

\\edit: oops, Zitat, statt Edit gedrückt... Wie wäre es mit einer Zitat+Edit-Funktion? :mrgreen:

[Hansa]

Zitat:

Zitat von dizzy

...Je nach Alter des Formats hat man es häufiger mit variablen Strukturen zu tun, als mit statischen Satzlängen...

Wie sollen denn in einer (siehe Titel) "typisierten Datei" variable Satzlängen realisiert werden ? :shock: Selbst in einem VARIANT Record sind sie immer gleich. Der variante Teil ist dann immer so groß wie die größte mögliche Variante. Alles zusammen hat dann trotz "variabel" die gleiche Satzlänge. 8) Und das ist der Ansatzpunkt.

[Kedariodakon]

Zitat:

Zitat von Hansa

Zitat:

Zitat von dizzy

...Je nach Alter des Formats hat man es häufiger mit variablen Strukturen zu tun, als mit statischen Satzlängen...

Wie sollen denn in einer (siehe Titel) "typisierten Datei" variable Satzlängen realisiert werden ? :shock: Selbst in einem VARIANT Record sind sie immer gleich. Der variante Teil ist dann immer so groß wie die größte mögliche Variante. Alles zusammen hat dann trotz "variabel" die gleiche Satzlänge. 8) Und das ist der Ansatzpunkt.

Aber meist werden unterschiedliche Typen reingeschrieben...
So ist die Blockgröße unterschiedlich...


Bye

[Hansa]

Wie kommt ihr nur auf so was ? Wo ist diese Info her ? :shock: Woher soll man denn wissen, welcher Datensatz auf der Platte 100 Byte hat und welcher 200 ???

[dizzy]

@Hansa: Ich bin jetzt zunächst mal davon ausgegangen, dass der Fragesteller mit "typisiert" nicht die Delphi-Interpretation "file of ..." gemeint hat. Ich bin erst mal von einer irgendwie strukturierten Datei ausgegangen. Daher wohl das kleine Missverständnis.


Wenn man mit Sicherheit davon ausgehen kann, dass die Datei in Sätzen statischer Länge organisiert ist, dann siehe Hansa :D.

[Hansa]

Ja, Dizzy, so ist das. :P In solchen Fällen kann man "vermuten, daß es vielleicht eine Frage ist, für die es eventuell, je nachdem, verschiedene Lösungen gibt" :lol: Wenn denn die eigene Vermutung irgendwie nahe genug an die Wahrheit dran kommt. Oder man orientiert sich am Titel, der dieses mal einiges aussagt, aber nur sofern der Fragesteller keinen Fehler in der Formulierung gemacht hat. Deshalb : handelt es sich um eine "typisierte Datei", dann ist sie eben vom Typ FILE OF...

Ansonsten eben : Thema verfehlt, antworten überflüssig. :mrgreen: