Mappage de fichier PE

Signaler
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007
-
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
-
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.

10 réponses

Messages postés
202
Date d'inscription
mardi 17 mai 2005
Statut
Membre
Dernière intervention
29 septembre 2008
2
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+
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
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é.

@++
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007

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 ?
Messages postés
202
Date d'inscription
mardi 17 mai 2005
Statut
Membre
Dernière intervention
29 septembre 2008
2
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+
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
salut,

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

@++
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007

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... :-)
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
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 !!!

@++
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007

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...
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
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...

@++
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
re,

la taille file alignement serait plutot egale a 512 soit un secteur, que cela ne m'etonnerait pas.

@++