[HaBo]

cipher

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

CDW

Das gibt es ja in der offiziellen Doku:
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.

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

cipher

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

CDW

ok
wer lesen kann ist klar im Vorteil

__________________
Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf!
Selig, wer nichts zu sagen hat und trotzdem schweigt.

enkore

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...

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++

cipher

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