imports beim PE Format

Hallo zusammen,

ich habe ein kleines Beispielprogramm, welches lediglich eine Messagebox ausgibt. Geschrieben hab ich das in MASM. Anhand dieses Programmes versuche ich mich nun in die Funktionsweise des PE formats einzuabeiten. Zur Zeit befinde ich mich bei den imports und tue mich da auch sehr schwer.

Bisher hab ich das so verstanden, dass für jede DLL, aus der ich Funktionen importiere, eine IMAGE_IMPORT_DESCRIPTOR Struktur habe. Aber wie finde ich nun, wo diese Strukturen in meiner Datei abgelegt sind. Da ich nur drei Sections habe (.text, .rdata, .data), werden sie wohl in der .rdata Section liegen. Wie aber findet der Loader sie. Ich vermute, es hängt mit dem Import Directory zusammen. Dort hab ich allerdings nur die RVA und die Größe gegeben. Mit diesen Werten weiß ich nichts richtig anzufangen.
 
Wenn es lang sein darf: http://www.hackerboard.de/hacks-crackmes/27912-unpacking-pe-format.html ("Teil2", ja, das darf man mittlerweile als "Uralt" bezeichnen, allerdings hat sich das Format auch nicht wirklich geändert ;) )
Die Standarddoku:
Microsoft PE and COFF Specification

Ein Beispiel, wie man die Imports per Hand/im Hexeditor findet:
http://www.hackerboard.de/code-kitchen/46643-pe-import-table-frage.html (Post Nr5)
Da werden auch ein paar Begriffe in diesem Zusammenhang erklärt (VA, RVA, FileOffset)

PS: Sections und insbesondere Section-Namen sind "Schall und Rauch" - bei VB5/6 z.B liegt ein Teil der Imports (zumindest die Import Address Table) in der .text-Section ;)
 
Vielen Dank ihr zwei. Eure Hinweise haben mir sehr gut weitergeholfen. Ich habe es nun geschafft über das Import Directory die offsets zu den IMAGE_IMPORT_DESCRIPTOREN zu finden. Ich verstehe nun noch nicht ganz den Unterschied von OriginalFirstThunk und FirstThunk. Beide verweisen (wenn ich das richtig verstanden hab) auf eine Liste von IMAGE_THUNK_DATA Strukturen, die wiederum durch eine Nullstruktur beendet wird. Jede IMAGE_THUNK_DATA Struktur verweist auf eine IMAGE_IMPORT_BY_NAME Struktur, wo dann auch der Name der API Funktion drin steht.

Nun, sowohl OriginalFirstThunk als auch FirstThunk verweisen in meiner Beispiel PE Datei zwar auf unterschiedliche Bereiche, jedoch ist der Inhalt in diesen der gleiche. Ich frage mich nun natürlich wieso dieser doppelte Weg.
 
FirstThunk = IAT (Import Address Table)
Wird vom PE Loader ausgefüllt, hier stehen dann zur Laufzeit Funktionsadressen, statt Ordinalnummern/Pointern zu Funktionsnamen

OriginalFirstThunk = ILT (Import Lookup Table)
Wird vom PE Loader NICHT ausgefüllt, hier stehen dann auch zur Laufzeit immer noch die gleichen Informationen. Ist optional (es kann also auch 0 Wert annehmen) und wird von so einigen Linkern ausgelassen.

Wozu ILT gut sein soll:
Der Entwickler kann auch zur Compilierungszeit eine konkrete DLL-Version festlegen. Dann kann die IAT schon beim Programmbuild ausgefüllt werden (zumindest wird immer noch im Visual Studio Packet das Programm "BIND" mitgeliefert) - der Endanwender hat dadurch beim Starten einen ultimativen Performancevorteil, da dies nun nicht mehr vom PE Loader gemacht werden muss :rolleyes:
Das wird dann "bound imports" genannt.
Benchmark - es werden 10 DLLs mit je 100 Funktionen auf einem P3 550MhZ importiert, dank "bound imports" nimmt das dann 0.014 statt 0.018 Sekunden in Anspruch.
Wie gesagt, schon früher verzichteten viele Compiler darauf, OriginalFirstThunk auszufüllen - und mittlerweile dürfte dieses Feature noch seltener genutzt werden.

Die ILT aka "OriginalFirstThunk" ist dann "Plan B" - falls DLL-Versionen oder Timestamps nicht übereinstimmen ODER die DLL an einer anderen Basisadresse geladen wurde (ASLR lässt grüßen), stimmen die vorausgefüllten Adressen in der IAT natürlich nicht mehr - der PE Loader muss also doch 'ran und kann die nötigen Infos aus der ILT ablesen. ForwarderChain sollte aus der gleichen Oper sein - falls die importierte Funktionen aus der DLL ihrerseits nur eine Weiterleitung ist ("Export Forwarding"), gibt FC den Index (Nummer) der Funktion im jeweiligen Array an (zugegeben, eine genaue Dokumentation dazu lässt sich dazu auf Anhieb nicht finden).
 
Zurück
Oben