LES IAT HORS NORMES

LE CAS : NOTEPAD

L'IAT... mais c'est facile!!! Oups en y regardant de plus près j'ai vraiment fini par changer d'avis!

Voici ci-dessous la section .idata de mon cobaye préféré... Notepad.exe.(Version Fenêtres95, la version 98 est différente, et je suppose que celles qui suivent le sont aussi) Tous les testes seront fait sur lui. Je l'ai décortiqué dans tous les sens. Enfin presque...

Avant toute chose, en utilisant ProcDump : Je trouve le RVA de la table d'importation en 00007000 et parmi le détail des sections je trouve :

00007000 appartient donc bien à cette section .idata
Le point de référence de cette section est 00007000 si on regarde ça du point de vu "adresses mémoire" (Virtual Offset).
Mais si on regarde du point de vue "adresse fichier" (Raw Offset) la référence de la section est en 00004400.
Rappelez vous qu'on doit voir les choses comme HexWorkShop les regarde et lui il se réfère au Raw Offset

00007000 présente un déplacement de 0h par rapport à 00007000h donc si on prend l'autre base de référence en prenant le même déplacement, on se retrouve en 00004400h+00h = 0004400h

Donc l'entrée de la table d'importation vue dans HexWorkShop commence en 00004400h
Attention : ICI le point d'entrée dans l'Import Table se trouve au début de la section (au début de l'IAT), mais ce n'est pas forcément obligatoire comme on l'a vu précédamment . Par exemple si vous compilez un programme avec MASM et bien le point d'entrée dans l'Import Table se trouvera vers le milieu de la section. On aurait pu trouver le RVA de la Table d'Importation en 0000708C au lieu de 00007000 par exemple et du coup le déplacement aurai été de 708C-7000 = 8Ch et vu avec HexWorkShop on aurait vu que le point d'entrée dans l'Import Table aurait été 4400+8C = 448Ch. au lieu de 4400h

Vous pouvez donc être sûr d'un truc, c'est que Notepad.exe n'a pas été codé sous Masm.
Quoi qu'il en soit quand on entre dans l'Import Table la première structure sur laquelle on pointe est le premier IMAGE_IMPORT_DESCRIPTOR.

Donc voilà la première structure lue dans l'Import Table étant toujours le premier IMAGE_IMPORT_DESCRIPTOR (Je dis 1er parce qu'il y en a autant qu'il y a de DLLs) et sa définition étant (un petit rappel ne fait pas de mal):

IMAGE_IMPORT_DESCRIPTOR :

Dans une structure IMAGE_IMPORT_DESCRIPTOR: (taille 5 DWORD)
- Le 1er DWORD pointe sur une stucture appelée "ORIGINAL_FIRST_THUNK".
- Le 2nd DWORD date de création de la DLL mais vous pouvez l'ignorer et le mettre à 00000000.
- Le 3e DWORD est lui aussi réservé et mis à FFFFFFFF, (mais je l'ai déjà trouvé à 00000000)
- Le 4e DWORD pointe sur une adresse. Cette adresse c'est l'endroit où se trouve écrit le nom de la DLL à laquelle cette fonction appartient.
- Le 5e DWORD pointe sur une structure appelée "FIRST_THUNK". Cette structure est normalement une copie conforme de l"ORIGINAL_FIRST_THUNK".

On retrouve les données qui nous intéressaient. Par exemple avec : 60710000. Chaque DWORD se lisant en sens inverse donne 00007160. Cette valeur est un RVA pris par rapport au Virtual Offset(00007000) comme tout à l'heure. Le déplacement est donc en réalité de +160h (bytes) mais si on reprend le Raw Offset(00004400) comme référence (puisque c'est lui qu'utilise HexWorkShop pour son adressage) on trouve alors 00004400h + 160h = 00004560h
Donc l'"ORIGINAL_FIRST_THUNK" qui est le tableau qui contient des RVA qui pointent eux-mêmes sur les nom+ordinaux des fonctions de la DLL en question commence en 00004560h (commence en 00004560 pour cette première DLL uniquement)

En fait dans l'IAT on trouve autant de fois la structure IMAGE_IMPORT_DESCRIPTOR: (taille 5 DWORD) qu'il y a de DLL utilisées par le programme, plus un IMAGE_IMPORT_DESCRIPTOR vide (mis à Zéro) pour clore ce groupe.

Et voyez plutôt ce que nous donne W32Dasm8.93

+++++++++++++++++++ IMPORTED FUNCTIONS ++++++++++++++++++
Number of Imported Modules = 5 (decimal)

Import Module 001: SHELL32.dll
Import Module 002: KERNEL32.dll
Import Module 003: USER32.dll
Import Module 004: GDI32.dll
Import Module 005: comdlg32.dll

J'ai dit que "ORIGINAL_FIRST_THUNK" et "FIRST_THUNK" étaient deux structures identiques l'une à l'autre, donc en 00004560 et en 00004770 on devrait normalement retrouver la même valeur (D874 0000), et pourtant ici exceptionnellement ce n'est pas le cas. Je vais vous dire pourquoi dans ce qui suit....

IAT... (Suite 2)