Tabulka importů - druhá část - Builder.cz - Informacni server o programovani

Navigace:  » Úvodní stránka  » Rubriky  » Assembler  

4. září 2001, 00.00 | Seriál popisující strukturu PE formátu souborů. Dnes poněkud složitější pokračování minulého dílu o tabulce importů..

Pokračujeme tam, kde jsme minule skončili, tedy u popisu struktury IMAGE_IMPORT_DESCRIPTOR:

Prvním prvkem struktury IMAGE_IMPORT_DESCRIPTOR je sice union, ale ve skutečnosti je to jen jedna proměnná typu DWORD s názvem OriginalFirstThunk. Ta obsahuje RVA pole struktur IMAGE_THUNK_DATA, které je zakončeno jednou strukturou vyplněnou nulami.
Name je RVA názvu DLL knihovny - prostě ukazatel na název knihovny ve formátu ASCIIZ.
FirstThunk obsahuje stejně jako OriginalFirstThunk RVA pole struktur IMAGE_THUNK_DATA. Toto pole je však uloženo na odlišném místě - obsahuje však stejná data, jako pole na které ukazuje OriginalFirstThunk.

Asi se teď ptáte, proč pole na které ukazují FirstThunk a OriginalFirstThunk obsahují stejná data. Dřív než vám na to ale odpovím, podíváme se ještě trochu hlouběji na IMAGE_THUNK_DATA. 
Tato struktura by se ani neměla označovat jako struktura, protože jediné co obsahuje, je ukazatel na další strukturu - a to IMAGE_IMPORT_BY_NAME. Nechápejte ji proto jako strukturu, ale pouze jako ukazatel - je to mnohem jednodušší.
No a konečně struktura IMAGE_IMPORT_BY_NAME obsahuje informace o samotné importované funkci. Její stavba je následující:

typedef struct _IMAGE_IMPORT_BY_NAME { WORD Hint; BYTE Name[1]; } IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

Hint ukazuje do export tabulky DLL knihovny, odkud je funkce importována. Je uváděna pro urychlení práce PE loaderu při hledání importované funkce v export tabulce DLL knihovny - není proto nikterak podstatná.
Name obsahuje název funkce v ASCIIZ formátu. I když je deklarován jako BYTE, má ve skutečnosti proměnlivou velikost.

Počet prvků pole struktur IMAGE_THUNK_DATA je stejný jako počet prvků pole struktur IMAGE_IMPORT_BY_NAME, což je ovšem logické, protože každá struktura IMAGE_THUNK_DATA je vlastně ukazatelem na jeden prvek pole struktur IMAGE_IMPORT_BY_NAME. A počet struktur IMAGE_IMPORT_BY_NAME se rovná počtu funkcí importovaných z jedné DLL knihovny.

A teď zpátky ke zmiňované otázce - proč pole, na které ukazují FirstThunk a OriginalFirstThunk obsahují stejná data? Jakmile PE loader převezme správu importovaných funkcí, zjistí ze struktury IMAGE_THUNK_DATA a poté IMAGE_IMPORT_BY_NAME název importované funkce. Následně vypočítá její skutečnou adresu a touto hodnotou přepíše pole struktur IMAGE_THUNK_DATA, na které ukazuje FirstThunk.
Pole struktur, na které ukazuje OriginalFirstThunk zůstává nezměněno a tak, pokud potřebuje PE loader z nějakého důvodu zjistit název importované funkce, může tak učinit bez sebemenších problémů.
Tohle všechno by ovšem bylo až příliš "jednoduché" a proto některým importovaným funkcím schází struktura IMAGE_IMPORT_BY_NAME. Takovýmto funkcím se říká ordinální a nejsou importovány podle svého jména, ale podle svého umístění. Struktura IMAGE_THUNK_DATA, pak místo ukazatele na IMAGE_IMPORT_BY_NAME obsahuje ve spodním wordu umístění funkce a MSB(most significant bit) je nastaven na 1. Pokud je tedy umístění ordinální funkce např. 1234h, IMAGE_THUNK_DATA pak obsahuje hodnotu 80001234h. Micro$oft pro nás definoval užitečnou konstantu pro testování MSB dwordu - jmenuje se IMAGE_ORDINAL_FLAG32 a její hodnota je 80000000h.

Tak a vyčerpávající díly o tabulce importů už jsou úspěšně za námi.