Bonjour, j'aimerai simplment savoir ce qui est mappé d'un fichier PE par un loader dans la mémoire. Pas très clair... bref quand le loader mappe un .exe ou un .dll en mémoire, est-ce-que les headers sont mappés ??? Ou est-ce-que ttes les sections sont mappés ??? Bref, le fichier est-il mappé en entier ou juste une partie ??? J'ai répété 3 fois la même chose, j'espère avoir correctement exposé mon problème... ;-) Merci de votre réponse.

Bonjour Morganitos,

Pour répondre à ta question (si j'ai bien compris), je m'étais interessé à ce qui étais chargé dans la mémoire au lancement d'un programme. C'étais en fait l'objet de ma première source sur CodeSources. Le programme permettait de visualiser ce qui se trouvait dans la mémoire à partir de 00400000h, emplacement traditionnel des programmes.
On retrouve effectivement integralement en mémoire le header PE (et MZ) à partir de l'adresse 00400000, puis les différentes sections aux emplacements définis par le header PE. Les informations relatives aux différentes sections du header PE contiennent entre autre:
- l'adresse de chargement (où les données vont se retrouver une fois chargées)
- l'adresse à partir de laquelle s'effectuera la copie (position des données dans le fichier non chargé - voir avec éditeur hexa).

Pour la section code et data, elles restent identiques, par compte il pourra y avoir quelques différences pour les imports/export/relocs...
A+

salut, effectivement, l'ensemble de l'executable est mappé en memoire virtuelle. Windows recuperera la memoire physique en "discardant" les parties les moins utilisées comme les ressources,... Autrement dit, tout est mappé en memoire virtuelle mais pas forcement en mémoire physique. Un acces memoire aux parties "discardées" génèrera juste une exception PAGE_NOT_PRESENT afin que le gestionnaire memoire remappe le bloc désiré en memoire physique. Ceci est bien sur transparent pour le coté application qui ne voit rien de ce qui c'est passé. @++

Merci pour ces réponses bien claires. Par contre Nasman, je comprends que la section import soit modifiée, puisque les adresses des API sont loadées lors du mapping. Mais je ne comprends pas quelles peuvent être les modif apportées par le loader sur les sections d'exportation et de relocation... Je pensais qu'elles étaient simplement lues, non ?

Bonjour Morganitos,

Pour commencer, je te présente toutes mes confuses .
Effectivement la section relocs est chargée telle quelle dans la mémoire virtuelle (à l'emplacement indiqué par le header) ; en ce qui concerne la section export il faudrait que je verifie. Enfin pour la section import, des modifications sont apportées entre le contenu du fichier source et celui chargé en mémoire.

Pour un décriptage plus complet, je suppose que tu connais la structure des fichiers PE.

A+

salut, Les exports sont indiqués en offset par rapport a la section. Pas de raison de les reloger. @++

Pour continuer dans la série : Je viens d'étudier une dll et , ho surprise, je vois qque chose qui me semble bizarre : La section .data ( remplie de 0 comme à son habitude je pense...) a sa VirtualSize plus grande que sa SizeOfRawData. Est-ce-normal ??? Si oui, est-ce une caractéristique propre à cette section ou est-il possible que d'autres types de section adoptent la même "originalité" ??? Merci d'avance pour votre réponse... :-)

salut, la taille virtuelle de la section sera tj alignée par bloc de 4Ko et peut etre plus ? il en est de meme pour la section .code qui font d'excellents endroits pour coller un code virus !!! @++

Je n'ai pas très bien compris, cependant, la SizeOfRawData d'une section devrait être alignée par rapport à la VirtualSize de cette même section selon la valeur de FileHeader.FileAlignement ( souvent égale à 1000 octets d'ailleurs) non ? Donc nécessairement : SizeOfRawData > VirtualSize n'est-ce-pas ? Ce qui n'est pas le cas dans mon exemple de la .data...

qu'est ce que tu me raconte là ? la SizeOfRawData est la taille des données fichier et la virtual size est la taille en memoire. si SizeOfRawData devient superieur a VirtualSize on obtient des données fantomes ( qui existe niveau fichier mais innaccessibles en memoire ??? ). pour dire simple, quand tu veux rentrer tes affaires dans une valise, assure toi que la valise soit assez grande... @++