Mappage de fichier PE
morganitos
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007
-
3 janv. 2006 à 19:15
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 10 janv. 2006 à 21:36
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 10 janv. 2006 à 21:36
10 réponses
cs_Nasman
Messages postés
202
Date d'inscription
mardi 17 mai 2005
Statut
Membre
Dernière intervention
29 septembre 2008
3
4 janv. 2006 à 09:20
4 janv. 2006 à 09:20
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+
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+
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
2
4 janv. 2006 à 09:49
4 janv. 2006 à 09:49
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é.
@++
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é.
@++
morganitos
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007
4 janv. 2006 à 15:34
4 janv. 2006 à 15:34
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 ?
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 ?
cs_Nasman
Messages postés
202
Date d'inscription
mardi 17 mai 2005
Statut
Membre
Dernière intervention
29 septembre 2008
3
5 janv. 2006 à 10:55
5 janv. 2006 à 10:55
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+
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+
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
2
5 janv. 2006 à 12:39
5 janv. 2006 à 12:39
salut,
Les exports sont indiqués en offset par rapport a la section.
Pas de raison de les reloger.
@++
Les exports sont indiqués en offset par rapport a la section.
Pas de raison de les reloger.
@++
morganitos
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007
10 janv. 2006 à 17:37
10 janv. 2006 à 17:37
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... :-)
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... :-)
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
2
10 janv. 2006 à 19:11
10 janv. 2006 à 19:11
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 !!!
@++
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 !!!
@++
morganitos
Messages postés
28
Date d'inscription
samedi 1 février 2003
Statut
Membre
Dernière intervention
27 septembre 2007
10 janv. 2006 à 20:56
10 janv. 2006 à 20:56
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...
Donc nécessairement : SizeOfRawData > VirtualSize n'est-ce-pas ?
Ce qui n'est pas le cas dans mon exemple de la .data...
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
2
10 janv. 2006 à 21:29
10 janv. 2006 à 21:29
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...
@++
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...
@++
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
2
10 janv. 2006 à 21:36
10 janv. 2006 à 21:36
re,
la taille file alignement serait plutot egale a 512 soit un secteur, que cela ne m'etonnerait pas.
@++
la taille file alignement serait plutot egale a 512 soit un secteur, que cela ne m'etonnerait pas.
@++