Verständnis der Imprt Section der PE

[seux]

Ja, hallo zusammen,
Bei meiner Tour durch das PE Dateiformat bin ich jetzt bei der Import Section angekommen und wie ich es mir vorher schon gedacht hab, wird das der härteste Part. Die Export Section hab ich vorerst übersprungen, da so wie ich es verstanden hab sie sich nur auf DLL Dateien bezieht. Da ich meine Tour erstmal durch eine Exe Datei mache, muss diese Section also warten.

Wie in den beiden anderen Threads schon genannt, beziehe ich meine Informationen hauptsächlich vom PE File Format Compendium des ARTeam.

Zur Sache:
Was ist ein Chunk, Thunk?
Bisher hab ich Thunk als einen Api Aufruf verstanden. Also wenn mein Programm ExitProcess aufruft, dann wird der Code aus dem anderem Modul ausgeführt. -> Thunk

Ich mache die Tour ja anhand eines simplen Programmes, welches lediglich eine MessageBox aufruft und dann über ExitProcess beendet wird. Demnach hätte ich

• MessageBoxA -> user32.dll
• ExitProcess -> kernel32.dll

Für jede Dll wird eine IMAGE_IMPORT_DISCRIPTOR Struktur angelegt.
Meine Fragen dazu:

1. Sind originalFirstThunk und FirstThunk Addressen zur IMAGE_THUNK_DATA Struktur? Weil im Compendium steht RVA, und das würde sich ja erst auf den Loader beziehen.
2. für jede API. die in meinem Programm aufgerufen wird, muss doch eine IMAGE_THUNK_DATA Struktur angelegt werden, oder?

Ih weiß, dass sind eine Menge Fragen, aber ich hab damit ziemliche schwirigkeiten im moment. Zur Zeit ergibt es alles noch wenig Sinn


gruß seux

 

[CDW]

Meine Fragen dazu:

1. Sind originalFirstThunk und FirstThunk Addressen zur IMAGE_THUNK_DATA Struktur? Weil im Compendium steht RVA, und das würde sich ja erst auf den Loader beziehen.

Jein. Beide sollten prinzipiell zu unterschiedlichen Arrays zeigen, da FirstThunk Adressen nach der Loader initialisierung mit API-Adressen überschrieben werden, die "originalFirstThunk" Einträge dagegen nicht:
Iczelion's PE Tutorial 6: Import Table

Wobei es nicht unüblich ist, dass (insbesondere bei Borland Compiler/Linker oder Packern) auf OFTs verzichten.

1. für jede API. die in meinem Programm aufgerufen wird, muss doch eine IMAGE_THUNK_DATA Struktur angelegt werden, oder?

Hm, man kann die APIs auch direkt aufrufen (hartkodierte Adressen), auch wenn es keine gute Idee ist. Üblicher ist es, die API Adressen dynamisch zu ermitteln (LoadLibrary/GetProcAddr) oder alles dem Compiler/Linker zu überlassen (der eben die IAT bzw die Imports aufbaut und die API-Calls im Programm darauf umbiegt). Das ist Größtenteils dem Interna des Compilers/Linkers überlassen - bestes Beispiel dafür sollte VB5/6 sein:

Declare Function [URL="http://www.vbarchiv.net/api/details.php?id=getdrivetype"]GetDriveType[/URL] Lib "kernel32" _
  Alias "GetDriveTypeA" ( _
  ByVal nDrive As String) As Long

wird üblicherweise zur Laufzeit von MSVBVMXX-Laufzeitbibliothek
aufgelöst:

0040201F   > 68 FC1F4000    PUSH dumpde_.00401FFC
00402024   . B8 00124000    MOV EAX,<JMP.&msvbvm60.DllFunctionCall>
00402029   . FFD0           CALL EAX

während man bei C/MASM

#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

.386
.model flat, stdcall
option casemap :none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
.data
hello db "Hello World!", 0
.code
start:
invoke MessageBoxA, NULL, addr hello, addr hello, MB_OK

üblicherweise fertige Imports erhält.