4

Il y a "First Thunk" (FT), lequel chargeur écrase après exécution avec les adresses correctes.Pourquoi le PE a-t-il besoin de l'Original First Thunk (OFT)?

Mais lorsque PE utilise OFT?

PE en a-t-il besoin?

+1

Ceci est bien décrit par [l'ancien article de Matt Pietrek] (https://msdn.microsoft.com/en-us/library/ms809762.aspx). Ne le répétons pas tous ici, l'article de Matt est canonique. –

Répondre

6

Le premier thunk d'origine est nécessaire si les importations sont liées mais que le fichier .DLL importé ne correspond pas.

Sur une nouvelle version non corrigée de Windows, toutes les adresses de toutes les fonctions dans les fichiers .DLL de base (ntdll, kernel32, user32, etc.) sont connues. Prenez Shell32 par exemple, il lie à kernel32!CreateProcess et l'adresse vraie de CreateProcess peut être stockée directement dans shell32. Ceci est appelé import binding et permet au chargeur d'ignorer l'étape où il recherche toutes les adresses des fonctions importées.

Cela ne fonctionne pas si le fichier .DLL importé n'a pas été chargé à son adresse préférée et si le fichier .DLL a été modifié (mise à jour de sécurité, etc.). Si cela se produit, le chargeur doit rechercher les fonctions "normalement" et le premier tableau de thunk original doit être utilisé car c'est le seul endroit où les RVA s des noms de fonctions sont stockés.

Si la liaison d'importation n'est pas utilisée, la première matrice de thunk d'origine est facultative et peut ne pas être présente. ASLR a probablement rendu cette optimisation non pertinente.