Welche Daten im EXE-Header (vorm PE)?

C

cipher

0
Hi Crackerfreunde!

Ich hab mal ne Frage an Leute, die sich gut mit dem EXE-Header - und zwar mit den Daten vor dem PE-Header - auskennen.
In keiner Dokumentation scheint es Infos über den Bereich zwischen DOS-Stub und dem PE-Header zu geben. Der DOS-Header endet mit 03Ch "PTR to PE-Header". Dann kommt das Mini-Dos-Programm und der dazugehörige String (This Program cannot...). Dann kann man erst wieder was über den PE-Header finden.

Hab mir diverse ExeFiles angesehen und festgestellt, dass verschiedene Linker unterschiedliche und unterschiedlich lange "Bereiche" produzieren. Fast alle haben aber gegen Ende den String "Rich" und beinhalten wiederholende Muster.

Kann mir einer auf die Sprünge helfen, was es damit auf sich hat?

thnx,
cipher

[EDIT]: Ok, ich bin beim Tippen des Beitrags darauf gekommen Rich auch mal in der google-Suche zu benutzen und bin darauf gestoßen.
Der Link scheint es bestmöglich zu beschreiben: Rich-Header
 
Das gibt es ja in der offiziellen Doku:
The MS‑DOS stub is a valid application that runs under MS‑DOS. It is placed at the front of the EXE image. The linker places a default stub here, which prints out the message ?This program cannot be run in DOS mode? when the image is run in MS‑DOS. The user can specify a different stub by using the /STUB linker option.
At location 0x3c, the stub has the file offset to the PE signature. This information enables Windows to properly execute the image file, even though it has an MS‑DOS stub. This file offset is placed at location 0x3c during linking.
Zum Vergrößern anklicken....
Wird schon seit NE Zeiten (New Exe) mitgeschleppt. Funktionsweise: soweit ich weiß über die "first relocation table" Angabe am Offset 0x18 - da steht nämlich 0x40 Wert, was dem DOS "Executor" erlaubt, nichts von NE/PE wissend den DOS-Code auszufüren. Für NE/PE Loader wiederum ist es wohl "hardcodiert", den Wert am 0x3c auszuwerten. Jedenfalls ist Deine Frage etwas "komisch" - ein Compiler/Linkermacher (und das sind durchaus nicht immer große Teams wie von Intel&Co) wird sich an die offizielle Doku halten müssen - und die besagt einfach, dass alles zwischen 0x3C und "PE" zum DOSenCode gehört.
 
Hi CDW!

Danke für Deine Ausführung. Ich glaube aber, Du hast meine Frage nicht ganz richtig "erwischt" ;)

MZ Header, Dos-Stub, kenn ich alles und ist ja auch offiziell dokumentiert.
Aber die komische Datenstruktur zwischen Dos-Stub und PE-Header, um die ging es mir.
Ich habe ja mittlerweile was gefunden (siehe Edit meines ersten Beitrags).
Da wird schnell klar, welchen "Bereich" ich meine.

So weit, ich gelesen hab: Rich-Header bzw. Rich-Signature

Mysteriöse (xor-verschlüsselte) verkettete Liste. Beginnt mit String "DanS" und wird vom Linker eingebaut. NET-Files haben es nicht. MASM-Compilate und andere Microsoft-Teile (VisualStudio 2003, VC++) haben es.
Keiner weiss wirklich wozu das ist, aber es scheinen auch keine wichtigen Daten zu sein.

Gruß,
cipher
 
Hauptsächlich geht es da wohl um das Symbol "@comp.id", dass die Compilerversion enthält... wohl um vor Inkompatiblitäten mit anderen Kompilern (Nur bei objectfiles, libraries) zu verhindern...
 
Sö, ich hab den Link von oben jetzt auch einmal zu Ende gelesen.
Fazit:
Eher uninteressant.
Enthält die Versionsnummern der beim linken verwendeten Libraries und Objectfiles. Und noch ein paar Bits mehr.

Komisch fand ich allerdings, dass außerhalb von Microsoft keiner genau weiss, wozu das da ist.
Als ich dann gelesen hab, dass die Datenstruktur von neueren Microsoft-Compilern hinterlassen wird, es keine offizielle Doku gibt und das ganze xor-verschleiert wird, war mein erster Gedanke:
Ne "unique ID" vom Computer oder die Lizenz des VisualStudio. Dann könnte man ja "ein böses Programm" zu einer verkauften Compiler-Lizenz zurückverfolgen. Naja.

Jetzt würde mich eigentlich noch interessieren, wer diese Datenstruktur jemals wieder einliest. Der Windows-Loader wohl nicht. Nullt man das ganze, ändert das beim Ausführen ganix. Also vielleicht der VisualStudio-Debugger...

blue skies,
cipher
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben