Bonjour,
Je suis à la recherche d'un site d'informations implicite sur les différentes sections d'un exécutable Win32 et tout particulièrement sur la section .Reloc et son rôle.
merci à tous et bonne fêtes de fin d'année
angI.
Version imprimable
Bonjour,
Je suis à la recherche d'un site d'informations implicite sur les différentes sections d'un exécutable Win32 et tout particulièrement sur la section .Reloc et son rôle.
merci à tous et bonne fêtes de fin d'année
angI.
Le format PE dispose d'une spécification, visible à cette adresse :
http://www.microsoft.com/whdc/system...re/PECOFF.mspx
Les articles les plus connus sur le PE sont les articles de Matt Pietrek :
Article Original :
http://msdn2.microsoft.com/en-us/library/ms809762.aspx
PE partie I :
http://msdn.microsoft.com/msdnmag/is...E/default.aspx
PE Partie II :
http://msdn.microsoft.com/msdnmag/is...2/default.aspx
Concernant la section .reloc :
Le but de la section .reloc est de mettre à disposition du chargeur de windows (Windows' Loader - le mécanisme qui passe du fichier sur disque à l'image en mémoire d'un fichier PE) un mécanisme nécessaire pour "reloger" du code.
:arrow: Principe de base :
Un fichier PE se charge en mémoire normalement à une adresse appelée "adresse de chargement préférée" (Preferred load address).
Comme les exécutables sont les premiers à se charger dans l'espace d'adressage d'un processus, il peuvent se charger à leur adresse préférée sans aucun problème. (c'est pourquoi un exécutable n'a pas à avoir de relocations, même si c'est techniquement possible d'en avoir pour un .exe).
Maintenant, lorsque le chargeur de Windows charge les DLLs, on peut imaginer que deux DLLs vont avoir la même adresse de chargement préférée.
Lorsqu'une DLL ne se charge pas à l'endroit où elle devrait se charger normalement, il va falloir modifier le code et les données qui se référaient au cas où la DLL se chargeait à son adresse préférée et non à la nouvelle adresse !
:arrow: Un exemple
Supposons qu'une DLL contienne ce code (l'exemple est tiré directement de la DLL Kernel32.dll de Win XP SP2, mais dans l'absolu ça n'est pas important) :
format : adresse instruction - opcodes - mnémonique instruction
Si on regarde les opcodes de l'instruction on voit :Code:
2
- l'opcode de l'instruction PUSH (0x68)
- Une valeur immédiate : 0xD00A817C
Comme nous sommes en little endian, il faut bien sûr lire : 0x7C810AD0, adresse qui correspond à une adresse dans kernel32.
L'image base (l'adresse préférée) de Kernel32 étant 0x7C800000.
Maintenant que se passerait-il si Kernel32 devait être reloger (parce qu'une DLL est déjà présente en 0x7C800000) par exemple en 0x70000000 ?
L'adresse notée dans l'instruction que l'on a vue (0x7C810AD0) ne serait plus valide puisqu'elle n'appartiendrait plus à kernel32 :!:
C'est là qu'intervient la section reloc. Au chargement de la DLL, le chargeur de Windows va corriger l'instruction à l'adresse fautive (0x7C801627 + 1) pour que l'instruction soit correctement "relogée" (relocated) :
Au lieu de ce qui suit, pour Kernel32.dll dont l'adresse préférée est 0x7C800000 : :
Si Kernel32.dll était relogée en 0x70000000, nous aurionsCode:
2
Le chargeur de Windows, grâce à la section .reloc, aura corrigé :Code:
2
- D00A817C
en
- D00A0170
La section reloc est assez compliqué compliquée à comprendre si on à pas déjà une bonne vue d'ensemble du format PE. Je n'ai présenté que son fonctionnement mais pas ses constituants.
N'hésites pas à poser des questions si quelque chose te semble flou ou si tu veux plus de détails.
P.S : Kernel32.dll contient bien une section reloc mais n'est jamais relogée, parce que c'est une des premières DLLs (en fait NTDLL puis Kernel32) à être chargée dans l'espace d'adressage du processus., mais l'exemple reste valide dans l'absolu.
Bien informé !
J'en profite pour poser une "petite" question.J'ai écrit en assembleur un programme extrayant les COMDAT ou GUID,il marche,mais n'arrive pas a lire une librairie en particulier,wbemuuid.lib (uuid.lib est lisible).
Il y aurait -il une différence de format entre certaines LIB ?
Merci beaucoup Neitsa, c'est très claire maintenant.
ToutEnMasm, désolé je n'ai pas de réponse à te donner. Essayes de créer un poste sur le sujet dans le forum ASM.
Bonnes fêtes
angI.
Bonjour,
De rien :D Merci toi aussi, bonnes fêtes :!: (bonnes fêtes à tous en fait !)Citation:
Envoyé par Angelico
Je ne suis pas sûr de comprendre ce que tu entends par COMDAT et GUID, je ne connais que les sections COMDAT... (c-a-d quand une section a le flag : IMAGE_SCN_LNK_COMDAT qui fait référence à des données COMDAT )Citation:
Envoyé par ToutEnMasm
Si je voyais sur quoi tu travailles exactement, je pourrais te répondre (tu travailles bien sur un format de fichier commençant par !<arch>\n ?).
Qu'entends-tu par COMDAT et GUID ?
Il y a un format "long" et un format "court" pour les LIBs actuelles, mais j'imagine que les anciennes libs on pu avoir un format différent de celui d'aujourd'hui.Citation:
Il y aurait -il une différence de format entre certaines LIB ?
Si jamais il y a eu un autre format pour les fichiers LIB, il date d'avant 1999 et n'est plus usité aujourd'hui, puisque la révision 6.0 PE/COFF de 1999 ne mentionne plus que ces deux formats (long et court).
Salut,
On parle bien de la même chose.
Le principe est simple.On ouvre une librairie en mémoire,en recopiant son image sans la changer.le but est de retrouver tous les pointeurs sur des sections COMDAT qui pour masm sont des structures GUID (c'est la même chose).la librairie possède bien la signature !<arch>.
Une fois que l'on a le pointeur sur la section COMDAT on peut sortir la structure GUID et son nom.Après traduction:
Citation:
sAudioSinkServiceClass_UUID TEXTEQU <{0110BH,0H,01000H,{080H,0H,0H,080H,05FH,09BH,034H,0FBH}}>
Pour obtenir ça j'ai suivi scrupuleusement le document microsoft sur le PE et réussit a extraire les comdat d'une dizaine de librairie du microsoft SDK.
Tout se passe bien,puis ....wbemuuid.lib refuse de se laisser lire.
Elle a la signature,je l'ai vérifié,et ne semble pas répondre au format microsoft.