IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

x86 32-bits / 64-bits Assembleur Discussion :

Les différentes sections d'un exécutable Win32


Sujet :

x86 32-bits / 64-bits Assembleur

  1. #1
    Membre régulier

    Profil pro
    none
    Inscrit en
    Août 2002
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : none

    Informations forums :
    Inscription : Août 2002
    Messages : 80
    Points : 96
    Points
    96
    Par défaut Les différentes sections d'un exécutable Win32
    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.

  2. #2
    Rédacteur
    Avatar de Neitsa
    Homme Profil pro
    Chercheur sécurité informatique
    Inscrit en
    Octobre 2003
    Messages
    1 041
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur sécurité informatique

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 041
    Points : 1 956
    Points
    1 956
    Par défaut
    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.

    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 !


    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

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    7C801627    68 D00A817C     PUSH kernel32.7C810AD0
    Si on regarde les opcodes de l'instruction on voit :

    - 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 : :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    7C801627    68 D00A817C     PUSH kernel32.7C810AD0
    Si Kernel32.dll était relogée en 0x70000000, nous aurions

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    70001627    68 D00A0170     PUSH kernel32.70010AD0
    Le chargeur de Windows, grâce à la section .reloc, aura corrigé :

    - 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.

  3. #3
    Membre actif

    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    193
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 193
    Points : 277
    Points
    277
    Par défaut
    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 ?

  4. #4
    Membre régulier

    Profil pro
    none
    Inscrit en
    Août 2002
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : none

    Informations forums :
    Inscription : Août 2002
    Messages : 80
    Points : 96
    Points
    96
    Par défaut
    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.

  5. #5
    Rédacteur
    Avatar de Neitsa
    Homme Profil pro
    Chercheur sécurité informatique
    Inscrit en
    Octobre 2003
    Messages
    1 041
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur sécurité informatique

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 041
    Points : 1 956
    Points
    1 956
    Par défaut
    Bonjour,

    Citation Envoyé par Angelico Voir le message
    Merci beaucoup Neitsa, c'est très claire maintenant.

    Bonnes fêtes

    angI.
    De rien Merci toi aussi, bonnes fêtes (bonnes fêtes à tous en fait !)


    Citation Envoyé par ToutEnMasm
    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).
    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 )

    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 aurait -il une différence de format entre certaines LIB ?
    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.

    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).

  6. #6
    Membre actif

    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    193
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 193
    Points : 277
    Points
    277
    Par défaut
    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:
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 30/03/2012, 12h01
  2. Réponses: 12
    Dernier message: 14/04/2009, 09h56
  3. [Débutant] Les opcodes sur les différents processeurs
    Par loverdose dans le forum Assembleur
    Réponses: 11
    Dernier message: 03/02/2005, 14h32
  4. faire un group by sur les différents niveau de code
    Par speed034 dans le forum Langage SQL
    Réponses: 4
    Dernier message: 07/10/2004, 17h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo