Dans mon expérience et celle des autres (http://webster.cs.ucr.edu/page_techdocs/pe.txt), le document de spécification PE / COFF affirme de manière incorrecte aux indices de tableau d'adresses d'exportation contenus dans l'ordinal. Les table sont relatives à la base ordinale et donnent même un exemple incorrect (section 5.3). En réalité, les indices de la table ordinale sont des indices à base de 0 dans le tableau d'adresses pour le cas normal dans lequel base ordinale = 1. J'ai vu cela dans VS Studio généré des bibliothèques PE et dans les bibliothèques système telles que Kernel32.dll.
Ma question est, avez-vous déjà observé un binaire avec une base ordinale qui n'était pas égale à 1? Je veux savoir si cette erreur obsolète, ou si la base ordinale n'est jamais appliquée aux entrées de la table ordinale.
3 Réponses :
Voici une vidage pour mfc42.dll, version 6.06.8064.0.
;
; Export directory for MFC42.dll
;
dd 0 ; Characteristics
dd 4D79A4A3h ; TimeDateStamp: Fri Mar 11 05:27:15 2011
dw 0 ; MajorVersion
dw 0 ; MinorVersion
dd rva aMfc42_dll ; Name
dd 5 ; Base
dd 1B1Bh ; NumberOfFunctions
dd 6 ; NumberOfNames
dd rva functbl ; AddressOfFunctions
dd rva nametbl ; AddressOfNames
dd rva nameordtbl ; AddressOfNameOrdinals
;
; Export Address Table for MFC42.dll
;
functbl dd rva ?classCCachedDataPathProperty@CCachedDataPathProperty@@2UCRuntimeClass@@B; 0
dd rva ?classCDataPathProperty@CDataPathProperty@@2UCRuntimeClass@@B; 1
dd rva DllCanUnloadNow ; 2
dd rva DllGetClassObject; 3
dd rva DllRegisterServer; 4
dd rva DllUnregisterServer; 5
dd 0F5h dup(rva __ImageBase); 6
dd rva ??0_AFX_CHECKLIST_STATE@@QAE@XZ; 251
[...]
;
; Export Names Table for MFC42.dll
;
nametbl dd rva a?classccachedd, rva a?classcdatapat, rva aDllcanunloadno
dd rva aDllgetclassobj, rva aDllregisterser, rva aDllunregisters
;
; Export Ordinals Table for MFC42.dll
;
nameordtbl dw 0, 1, 2, 3, 4, 5
Doux! Merci de confirmer ça. Comment avez-vous reçu la liste des tableaux d'exportation, est-ce que la sortie IDAPRO?
Oui, c'est d'Ida. Je n'ai renommé que les tables des noms par défaut.
Non, le champ Ordinalbase de Table d'exportation PE n'est pas ignoré!
L'échantillon fourni ci-dessus (mfc42.dll) est un bon (car sa base ordinale n'est pas 1).
ici deux remarques sur ce numéro:
. La sortie de l'outil de décharge est correcte en ce qui concerne le domaine ordinal. Il montre que le champ de base est 5. Cela signifie que, lors de l'importation d'une fonction exportée de MFC42.DLL par son nom, le décalage calculé dans le tableau d'adresses d'exportation sera X-5. La section Spécification Microsoft 5.3 est correcte.
. La sortie de l'outil de décharge n'est pas correcte en ce qui concerne l'indice. Les tables d'exportation n'ont pas de champ d'indice, seules les tables d'importation ont un champ d'astuce.
En fait, la base ordinale est appliquée non dans la table ordinale, mais lors de la récupération de l'index du tableau d'adresses!
Ce n'est pas une erreur obsolète et la base ordinale n'est pas appliquée aux entrées de la table ordinale, mais à la calcul de l'ordinal lui-même. Et oui, la spécification Microsoft PE ( http://msdn.microsoft .Com / fr-US / Bibliothèque / Windows / Matériel / GG463119.aspx , section 5.3.4) est faux. C'est la manière dont les calculs doivent être effectués: ou, exprimé d'une manière différente: si je vider mon mfc42.dll ... ... c'est ce que j'obtiens: la 7ème fonction (par exemple) ci-dessus est DllregisterServer, qui correspond au 7e mot (0x0004) dans la table d'ordinal exportation dans le vidage hexagonal ci-dessous de MFC42.DLL. Le démarrage est Les calculs: a7 05 .