Format PE

  • Article

Cette spécification décrit la structure des fichiers (image) exécutables et des fichiers objet sous la famille des systèmes d’exploitation Windows. Ces fichiers sont appelés respectivement Portable Executable (PE) et Common Object File Format (COFF).

Remarque

Ce document est destiné à faciliter le développement d’outils et d’applications pour Windows, mais on ne peut garantir qu’il s’agit d’une spécification complète à tous égards. Microsoft se réserve le droit de modifier ce document sans préavis.

Cette révision de la spécification du format de fichier Microsoft Portable Executable et Common Object remplace toutes les révisions précédentes de cette spécification.

Concepts généraux

Ce document décrit en détail la structure des fichiers (image) exécutables et des fichiers objets sous la famille de systèmes d’exploitation Microsoft Windows. Ces fichiers sont appelés respectivement Portable Executable (PE) et Common Object File Format (COFF). Le nom « Portable Executable » fait référence au fait que le format n’est pas spécifique à l’architecture.

Certains concepts qui figurent dans cette spécification sont décrits dans le tableau suivant :

Nom Description
Certificat d’attribut
Certificat utilisé pour associer des instructions vérifiables à une image. Un certain nombre d’instructions vérifiables différentes peuvent être associées à un fichier. L’une des plus utiles est l’instruction d’un fabricant de logiciels qui indique ce que devrait être le condensat du message de l’image. Un condensat de message est similaire à une somme de contrôle, sauf qu’il est extrêmement difficile de falsifier. Par conséquent, il est très difficile de modifier un fichier pour avoir le même condensat de message que le fichier d’origine. On peut vérifier que l’instruction a été réalisée par le fabricant au moyen de modèles de chiffrement à clé publique ou privée. Ce document fournit les détails des certificats d’attributs autres que ceux permettant leur insertion dans les fichiers d’images.
date/horodatage
Tampon utilisé à différentes fins à plusieurs endroits dans un fichier PE ou COFF. Dans la plupart des cas, le format de chaque tampon est identique à celui utilisé par les fonctions d’heure de la bibliothèque d’exécution C. Pour les exceptions, consultez la descripton de IMAGE_DEBUG_TYPE_REPRO dans Type de débogage. Si la valeur du tampon est 0 ou 0xFFFFFFFF, il ne s’agit pas d’un tampon date/heure réel ou significatif.
pointeur de fichier
Emplacement d’un élément dans le fichier lui-même, avant son traitement par l’éditeur de liens (dans le cas des fichiers objet) ou du chargeur (dans le cas de fichiers image). En d’autres termes, il s’agit d’une position dans le fichier telle qu’il est stocké sur le disque.
éditeur de liens
Référence à l’éditeur de liens fourni avec Microsoft Visual Studio.
fichier objet
Fichier donné comme entrée à l’éditeur de liens. L’éditeur de liens produit un fichier image, lequel à son tour est utilisé comme entrée par le chargeur. Le terme « fichier objet » n’implique pas nécessairement un lien avec la programmation orientée objet.
réservée, doit être 0
Description d’un champ qui indique que la valeur de ce dernier doit être égale à zéro pour les générateurs et que les consommateurs doivent l’ignorer.
Adresse virtuelle relative (RVA)
Dans un fichier image, il s’agit de l’adresse d’un élément après son chargement en mémoire, à laquelle est soustraite l’adresse de base du fichier image. L’adresse virtuelle relative (RVA) d’un élément est presque toujours différente de sa position dans le fichier sur le disque (pointeur de fichier).
Dans un fichier objet, une RVA est moins significative, car les emplacements de mémoire ne sont pas attribués. Dans ce cas, une RVA serait une adresse à l’intérieur d’une section (décrite plus loin dans ce tableau), à laquelle une relocalisation est appliquée ultérieurement lors de la liaison. Pour des raisons de simplicité, le compilateur devrait simplement définir sur zéro la première RVA de chaque section.
section
Unité de base du code ou des données dans un fichier PE ou COFF. Par exemple, la totalité du code d’un fichier objet peut être regroupée dans une seule section ou (en fonction du comportement du compilateur) chaque fonction peut occuper sa propre section. Plus le nombre de sections est élevé, plus le fichier est surchargé, mais l’éditeur de liens est en mesure de lier le code de manière plus sélective. Une section est similaire à un segment dans l’architecture Intel 8086. Toutes les données brutes d’une section doivent être chargées de manière contiguë. En outre, un fichier image peut contenir un certain nombre de sections, telles que .tls ou .reloc, qui ont des fonctions particulières.
Adresse virtuelle (VA)
Identique à la RVA, sauf que l’adresse de base du fichier image n’est pas soustraite. L’adresse est appelée VA car Windows crée un espace VA distinct pour chaque processus, indépendamment de la mémoire physique. Dans la plupart des cas, une VA doit être considérée comme une simple adresse. Une va n’est pas aussi prévisible qu’une RVA, car le chargeur est susceptible de ne pas charger l’image à son emplacement préféré.

Vue d’ensemble

La liste suivante décrit le format exécutable Microsoft PE, avec la base de l’en-tête de l’image en haut. La section allant de l’en-tête de l’EXE compatible avec MS-DOS 2.0 jusqu’à la section inutilisée située juste avant l’en-tête du PE est la section MS-DOS 2.0 et est uniquement utilisée pour la compatibilité avec MS-DOS.

  • En-tête EXE compatible MS-DOS 2.0

  • unused

  • Identificateur OEM

    Informations OEM

    Décalage avec l’en-tête PE

  • Programme stub MS-DOS 2.0 and tableau de réadressage

  • unused

  • En-tête PE (aligné sur la limite de 8 octets)

  • En-têtes des sections

  • Pages d’images :

    infos importation

    infos exportation

    réadressage de base

    informations sur les ressources

La liste suivante décrit le format du module objet Microsoft COFF :

  • En-tête Microsoft COFF

  • En-têtes des sections

  • Données brutes :

    code

    données

    infos débogage

    réadressages

En-têtes des fichiers

L’en-tête de fichier PE se compose d’un stub Microsoft MS-DOS, de la signature PE, de l’en-tête de fichier COFF et d’un en-tête facultatif. L’en-tête d’un fichier objet COFF se compose d’un en-tête de fichier COFF et d’un en-tête facultatif. Dans les deux cas, les en-têtes de fichier sont suivis immédiatement d’en-têtes de section.

Stub MS-DOS (image uniquement)

Le stub MS-DOS est une application valide qui s’exécute sous MS-DOS. Il est placé à l’avant de l’image EXE. L’éditeur de liens place ici un stub par défaut, qui affiche le message « Ce programme ne peut pas être exécuté en mode DOS » lorsque l’image est exécutée dans MS-DOS. L’utilisateur peut spécifier un stub différent à l’aide de l’option /STUB linker.

À l’emplacement 0x3c, le stub contient le décalage de fichier de la signature PE. Ces informations permettent à Windows d’exécuter correctement le fichier image, même s’il a un stub MS-DOS. Ce décalage de fichier est situé à l’emplacement 0x3c lors de la liaison.

Signature (image uniquement)

Une signature de 4 octets qui identifie le fichier comme étant un fichier image au format PE se trouve après le stub MS-DOS, au niveau du décalage de fichier spécifié au décalage 0x3c. Cette signature est « PE\0\0 » (les lettres « P » et « E » suivies de deux octets Null).

En-tête de fichier COFF (objet et image)

Un en-tête de fichier COFF standard, au format suivant, figure au début d’un fichier objet ou immédiatement après la signature d’un fichier image. Il convient de noter que le chargeur Windows limite le nombre de sections à 96.

Contrepartie Taille Champ Description
0
2
Machine
Numéro qui identifie le type d’erreur de l’ordinateur cible. Pour plus d’informations, consultez Types d’ordinateurs.
2
2
NumberOfSections
Nombre de sections. Cela indique la taille de la table de la section, qui suit immédiatement les en-têtes.
4
4
TimeDateStamp
Les 32 bits de poids faible du nombre de secondes écoulées depuis 0 h 00 le 1er janvier 1970 (une valeur time_t d’exécution C), qui indique quand le fichier a été créé.
8
4
PointerToSymbolTable
Décalage de fichier de la table de symboles COFF ou zéro si aucune table de symboles COFF n’est présente. Cette valeur doit être égale à zéro pour une image, car les informations de débogage COFF sont obsolètes.
12
4
NumberOfSymbols
Le nombre d’entrées dans la table de symboles. Ces données peuvent être utilisées pour localiser la table de chaînes, qui suit immédiatement la table de symboles. Cette valeur doit être égale à zéro pour une image, car les informations de débogage COFF sont obsolètes.
16
2
SizeOfOptionalHeader
La taille de l’en-tête facultatif, qui est requis pour les fichiers exécutables, mais pas pour les fichiers objets. Cette valeur doit être égale à zéro pour un fichier objet. Pour une description du format d’en-tête, consultez En-tête facultatif (image uniquement).
18
2
Caractéristiques
Les indicateurs qui indiquent les attributs du fichier. Pour des valeurs d’indicateur spécifiques, consultez Caractéristiques.

Types d’ordinateurs

Le champ Ordinateur présente l’une des valeurs suivantes, qui spécifient le type de processeur. Un fichier image peut uniquement être exécuté sur l’ordinateur spécifié ou sur un système qui émule l’ordinateur spécifié.

Constant Valeur Description
IMAGE_FILE_MACHINE_UNKNOWN
0x0
Le contenu de ce champ est supposé pouvoir s’appliquer à n’importe quel type d’ordinateur
IMAGE_FILE_MACHINE_ALPHA
0x184
Alpha AXP, espace d’adressage 32 bits
IMAGE_FILE_MACHINE_ALPHA64
 0x284
Alpha 64, espace d’adressage 64 bits
IMAGE_FILE_MACHINE_AM33
 0x1d3
Matsushita AM33
IMAGE_FILE_MACHINE_AMD64
 0x8664
X64
IMAGE_FILE_MACHINE_ARM
 0x1c0
ARM little endian
IMAGE_FILE_MACHINE_ARM64
 0xaa64
ARM64 little endian
IMAGE_FILE_MACHINE_ARMNT
0x1c4
ARM Thumb-2 little endian
IMAGE_FILE_MACHINE_AXP64
 0x284
AXP 64 (identique à Alpha 64)
IMAGE_FILE_MACHINE_EBC
 0xebc
EFI byte code
IMAGE_FILE_MACHINE_I386
 0x14c
Processeurs Intel 386 ou ultérieurs et processeurs compatibles
IMAGE_FILE_MACHINE_IA64
 0x200
Famille de processeurs Intel Itanium
IMAGE_FILE_MACHINE_LOONGARCH32
 0x6232
Famille de processeurs LoongArch 32 bits
IMAGE_FILE_MACHINE_LOONGARCH64
 0x6264
Famille de processeurs LoongArch 64 bits
IMAGE_FILE_MACHINE_M32R
 0x9041
Mitsubishi M32R little endian
IMAGE_FILE_MACHINE_MIPS16
 0x266
MIPS16
IMAGE_FILE_MACHINE_MIPSFPU
0x366
MIPS avec FPU
IMAGE_FILE_MACHINE_MIPSFPU16
 0x466
MIPS16 avec FPU
IMAGE_FILE_MACHINE_POWERPC
0x1f0
Power PC little endian
IMAGE_FILE_MACHINE_POWERPCFP
0x1f1
Power PC avec prise en charge de la virgule flottante
IMAGE_FILE_MACHINE_R4000
 0x166
MIPS little endian
IMAGE_FILE_MACHINE_RISCV32
 0x5032
Espace d’adressage RISC-V 32 bits
IMAGE_FILE_MACHINE_RISCV64
 0x5064
Espace d’adressage RISC-V 64 bits
IMAGE_FILE_MACHINE_RISCV128
 0x5128
Espace d’adressage RISC-V 128 bits
IMAGE_FILE_MACHINE_SH3
 0x1a2
Hitachi SH3
IMAGE_FILE_MACHINE_SH3DSP
 0x1a3
Hitachi SH3 DSP
IMAGE_FILE_MACHINE_SH4
 0x1a6
Hitachi SH4
IMAGE_FILE_MACHINE_SH5
 0x1a8
Hitachi SH5
IMAGE_FILE_MACHINE_THUMB
0x1c2
Thumb
IMAGE_FILE_MACHINE_WCEMIPSV2
 0x169
MIPS little-endian WCE v2

Caractéristiques

Le champ Caractéristiques contient des indicateurs qui indiquent les attributs du fichier objet ou image. Les indicateurs suivants sont actuellement définis :

Indicateur Valeur Description
IMAGE_FILE_RELOCS_STRIPPED
0x0001
Image uniquement, Windows CE et Microsoft Windows NT et versions ultérieures. Cela indique que le fichier ne contient aucun réadressage de base et doit donc être chargé à son adresse de base préférée. Si l’adresse de base n’est pas disponible, le chargeur signale une erreur. Le comportement par défaut de l’éditeur de liens consiste à supprimer les réadressages de base à partir de fichiers exécutables (EXE).
IMAGE_FILE_EXECUTABLE_IMAGE
0x0002
Image uniquement. Cela indique que le fichier image est valide et peut être exécuté. Si cet indicateur n’est pas défini, il indique une erreur de l’éditeur de liens.
IMAGE_FILE_LINE_NUMS_STRIPPED
0x0004
Les numéros de ligne COFF ont été supprimés. Cet indicateur est obsolète et doit être égal à zéro.
IMAGE_FILE_LOCAL_SYMS_STRIPPED
0x0008
Les entrées de la table de symboles COFF pour les symboles locaux ont été supprimées. Cet indicateur est obsolète et doit être égal à zéro.
IMAGE_FILE_AGGRESSIVE_WS_TRIM
0x0010
Obsolète. Réduire de manière agressive la plage de travail. Cet indicateur est obsolète pour Windows 2000 et versions ultérieures et doit être égal à zéro.
IMAGE_FILE_LARGE_ADDRESS_ AWARE
0x0020
L’application peut gérer des adresses > de 2 Go.
0x0040
Cet indicateur est réservé pour une utilisation future.
IMAGE_FILE_BYTES_REVERSED_LO
0x0080
Little endian : le bit le moins significatif (LSB) précède le bit le plus significatif (MSB) en mémoire. Cet indicateur est obsolète et doit être égal à zéro.
IMAGE_FILE_32BIT_MACHINE
0x0100
L’ordinateur est basé sur une architecture de mot 32 bits.
IMAGE_FILE_DEBUG_STRIPPED
0x0200
Les informations de débogage sont supprimées du fichier image.
IMAGE_FILE_REMOVABLE_RUN_ FROM_SWAP
0x0400
Si l’image se trouve sur un support amovible, chargez-la complètement et copiez-la dans le fichier d’échange.
IMAGE_FILE_NET_RUN_FROM_SWAP
0x0800
Si l’image se trouve sur un support réseau, chargez-la complètement et copiez-la dans le fichier d’échange.
IMAGE_FILE_SYSTEM
0x1000
Le fichier image est un fichier système, et non un programme utilisateur.
IMAGE_FILE_DLL
0x2000
Le fichier image est une bibliothèque de liens dynamiques (DLL). Ces fichiers sont considérés comme des fichiers exécutables dans la plupart des cas, bien qu’ils ne puissent pas être exécutés directement.
IMAGE_FILE_UP_SYSTEM_ONLY
0x4000
Le fichier doit être exécuté uniquement sur un ordinateur monoprocesseur.
IMAGE_FILE_BYTES_REVERSED_HI
0x8000
Big endian : le MSB précède le LSB en mémoire. Cet indicateur est obsolète et doit être égal à zéro.

En-tête facultatif (image uniquement)

Chaque fichier image possède un en-tête facultatif qui fournit des informations au chargeur. Cet en-tête est facultatif dans le sens où certains fichiers (en particulier les fichiers objet) n’en possèdent pas. Pour les fichiers image, cet en-tête est requis. Un fichier objet peut avoir un en-tête facultatif, mais en général ce dernier n’a aucune fonction dans un fichier objet, si ce n’est d’en augmenter la taille.

Il convient de noter que la taille de l’en-tête facultatif n’est pas fixe. Le champ SizeOfOptionalHeader de l’en-tête COFF doit être utilisé pour confirmer qu’une recherche dans le fichier pour un répertoire de données particulier ne va pas au-delà de SizeOfOptionalHeader. Pour plus d’informations, consultez En-tête de fichier COFF (objet et image).

Le champ NumberOfRvaAndSizes de l’en-tête facultatif doit également être utilisé pour s’assurer qu’aucune recherche pour une entrée de répertoire de données particulière ne va au-delà de l’en-tête facultatif. En outre, il est important de valider le nombre magique de l’en-tête facultatif pour assurer la compatibilité des formats.

Le nombre magique de l’en-tête facultatif détermine si une image est un exécutable PE32 ou PE32+.

Nombre magique Format PE
0x10b
PE32
0x20b
PE32+

Les images PE32+ permettent un espace d’adressage 64 bits tout en limitant la taille de l’image à 2 gigaoctets. D’autres modifications PE32+ sont traitées dans leurs sections respectives.

L’en-tête facultatif lui-même se compose de trois parties principales.

Décalage (PE32/PE32+) Taille (PE32/PE32+) Composant de l’en-tête Description
0
28/24
Champs standard
Champs définis pour toutes les implémentations de COFF, y compris UNIX.
28/24
68/88
Champs spécifiques à Windows
Champs supplémentaires pour prendre en charge des fonctionnalités spécifiques de Windows (par exemple, sous-systèmes).
96/112
variable ;
 Répertoires de données
Paires adresse/taille pour les tables spéciales trouvées dans le fichier image et utilisées par le système d’exploitation (par exemple, la table d’importation et la table d’exportation).

Champs standard des en-têtes facultatifs (image uniquement)

Les huit premiers champs de l’en-tête facultatif sont des champs standard définis pour chaque implémentation de COFF. Ils contiennent des informations générales utiles pour le chargement et l’exécution d’un fichier exécutable. Ils sont identiques pour le format PE32+.

Contrepartie Taille Champ Description
0
2
Magique
Entier non signé qui identifie l’état du fichier image. Le nombre le plus courant est 0x10B, qui l’identifie comme un fichier exécutable normal. 0x107 l’identifie comme une image ROM et 0x20B comme un exécutable PE32+.
2
1
MajorLinkerVersion
Numéro de version principale de l’éditeur de liens.
3
1
MinorLinkerVersion
Numéro de version mineure de l’éditeur de liens.
4
4
SizeOfCode
La taille de la section de code (texte), ou la somme de toutes les sections de code s’il y a plusieurs sections.
8
4
SizeOfInitializedData
La taille de la section de données initialisées, ou la somme de toutes ces sections s’il y a plusieurs sections de données.
12
4
SizeOfUninitializedData
La taille de la section de données non initialisées (BSS), ou la somme de toutes ces sections s’il y a plusieurs sections BSS.
16
4
AddressOfEntryPoint
L’adresse du point d’entrée par rapport à la base de l’image quand le fichier exécutable est chargé en mémoire. Pour les images de programme, il s’agit de l’adresse de départ. Pour les pilotes de périphérique, il s’agit de l’adresse de la fonction d’initialisation. Un point d’entrée est facultatif pour les DLL. Lorsqu’aucun point d’entrée n’est présent, ce champ doit être égal à zéro.
20
4
BaseOfCode
L’adresse de la section de début de code par rapport à la base de l’image quand elle est chargée en mémoire.

PE32 présente ce champ supplémentaire, absent dans PE32+, suivant BaseOfCode.

Contrepartie Taille Champ Description
24
4
BaseOfData
L’adresse de la section de début de données par rapport à la base de l’image quand elle est chargée en mémoire.

En-têtes facultatifs des champs spécifiques à Windows (image uniquement)

Les 21 champs suivants sont une extension du format d’en-tête facultatif COFF. Ils contiennent Les informations supplémentaires requises par l’éditeur de liens et le chargeur dans Windows.

Décalage (PE32/PE32+) Taille (PE32/PE32+) Champ Description
28/24
4/8
ImageBase
L’adresse préférée du premier octet de l’image lorsqu’il est chargé en mémoire. Ce doit être un multiple de 64 K. La valeur par défaut pour les DLL est 0x10000000. La valeur par défaut pour les EXE Windows CE est 0x00010000. La valeur par défaut pour Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98 et Windows Me est 0x00400000.
32/32
4
SectionAlignment
Alignement (en octets) des sections quand elles sont chargées en mémoire. Il doit être supérieur ou égal à FileAlignment La valeur par défaut correspond à la taille de page de l’architecture.
36/36
4
FileAlignment
Facteur d’alignement (en octets) utilisé pour aligner les données brutes des sections du fichier image. La valeur doit être une puissance de 2 comprise entre 512 et 64 Ko inclus. La valeur par défaut est 512. Si la valeur SectionAligment est inférieure à la taille de page de l’architecture, la valeur FileAlignment doit correspondre à celle de SectionAlignment.
40/40
2
MajorOperatingSystemVersion
Numéro de version principale du système d’exploitation nécessaire.
42/42
2
MinorOperatingSystemVersion
Numéro de version mineure du système d’exploitation nécessaire.
44/44
2
MajorImageVersion
Numéro de version principale de l’image.
46/46
2
MinorImageVersion
Numéro de version mineure de l’image.
48/48
2
MajorSubsystemVersion
Numéro de version principale du sous-système.
50/50
2
MinorSubsystemVersion
Numéro de version mineure du sous-système.
52/52
4
Win32VersionValue
Réservée, doit être zéro.
56/56
4
SizeOfImage
La taille (en octets) de l’image, y compris tous les en-têtes, quand l’image est chargée en mémoire. Il doit s’agir d’un multiple de SectionAlignment.
60/60
4
SizeOfHeaders
La taille combinée d’un stub MS DOS, d’un en-tête PE et des en-têtes de section, arrondie vers le haut à un multiple de FileAlignment.
64/64
4
CheckSum
La somme de contrôle du fichier image. L’algorithme de calcul de la somme de contrôle est incorporé dans IMAGHELP.DLL. La validation des éléments suivants est vérifiée au moment du chargement : tous les pilotes, toutes les DLL chargées au démarrage et toutes les DLL chargées dans un processus Windows critique.
68/68
2
Subsystem
Sous-système nécessaire pour exécuter cette image. Pour en savoir plus, voir Sous-système Windows.
70/70
2
DllCharacteristics
Pour en savoir plus, consultez Caractéristiques DLL plus loin dans cette spécification.
72/72
4/8
SizeOfStackReserve
Taille de la pile à réserver. Seule SizeOfStackCommit est validée ; le reste est mis à disposition une page à la fois jusqu’à ce que la taille de réserve soit atteinte.
76/80
4/8
SizeOfStackCommit
Taille de la pile à commiter.
80/88
4/8
SizeOfHeapReserve
Taille de l’espace du tas local à réserver. Seule SizeOfHeapCommit est validée ; le reste est mis à disposition une page à la fois jusqu’à ce que la taille de réserve soit atteinte.
84/96
4/8
SizeOfHeapCommit
Taille de l’espace du tas local à commiter.
88/104
4
LoaderFlags
Réservée, doit être zéro.
92/108
4
NumberOfRvaAndSizes
Le nombre d’entrées de répertoire de données dans le reste de l’en-tête facultatif. Chacune décrit un emplacement et une taille.
Sous-système Windows

Les valeurs suivantes définies pour le champ Sous-système de l’en-tête facultatif déterminent le sous-système Windows (s’il existe) requis pour exécuter l’image.

Constant Valeur Description
IMAGE_SUBSYSTEM_UNKNOWN
0
Un sous-système inconnu
IMAGE_SUBSYSTEM_NATIVE
1
Pilotes de périphérique et processus Windows natifs
IMAGE_SUBSYSTEM_WINDOWS_GUI
2
Sous-système d’interface graphique utilisateur (GUI) Windows
IMAGE_SUBSYSTEM_WINDOWS_CUI
3
Sous-système de caractères Windows
IMAGE_SUBSYSTEM_OS2_CUI
5
Sous-système de caractères OS/2
IMAGE_SUBSYSTEM_POSIX_CUI
7
Sous-système de caractères Posix
IMAGE_SUBSYSTEM_NATIVE_WINDOWS
8
Pilote Win9x natif
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI
9
Windows CE
IMAGE_SUBSYSTEM_EFI_APPLICATION
10
Une application EFI (Extensible Firmware Interface)
IMAGE_SUBSYSTEM_EFI_BOOT_ SERVICE_DRIVER
11
Un pilote EFI avec services de démarrage
IMAGE_SUBSYSTEM_EFI_RUNTIME_ DRIVER
12
Un pilote EFI avec des services d’exécution
IMAGE_SUBSYSTEM_EFI_ROM
13
Une image ROM EFI
IMAGE_SUBSYSTEM_XBOX
14
XBOX
IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION
16
Application de démarrage Windows.
Caractéristiques DLL

Les valeurs suivantes sont définies pour le champ DllCharacteristics de l’en-tête facultatif.

Constant Valeur Description
0x0001
Réservée, doit être zéro.
0x0002
Réservée, doit être zéro.
0x0004
Réservée, doit être zéro.
0x0008
Réservée, doit être zéro.
IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA
0x0020
L’image peut gérer un espace d’adressage virtuel 64 bits à entropie élevée.
IMAGE_DLLCHARACTERISTICS_
DYNAMIC_BASE
0x0040
La DLL peut être déplacée au moment du chargement.
IMAGE_DLLCHARACTERISTICS_
FORCE_INTEGRITY
0x0080
Les contrôles d’intégrité du code sont appliquées.
IMAGE_DLLCHARACTERISTICS_
NX_COMPAT
0x0100
L’image est compatible avec NX.
IMAGE_DLLCHARACTERISTICS_ NO_ISOLATION
0x0200
L’isolement est pris en compte, mais l’image n’est pas isolée.
IMAGE_DLLCHARACTERISTICS_ NO_SEH
0x0400
N’utilise pas la gestion d’exceptions structurées (SE). Aucun gestionnaire de SE ne peut être appelé dans cette image.
IMAGE_DLLCHARACTERISTICS_ NO_BIND
0x0800
Ne lie pas l’image.
IMAGE_DLLCHARACTERISTICS_APPCONTAINER
0x1000
L’image doit s’exécuter dans un AppContainer.
IMAGE_DLLCHARACTERISTICS_ WDM_DRIVER
0x2000
Pilote WDM.
IMAGE_DLLCHARACTERISTICS_GUARD_CF
0x4000
L’image prend en charge la protection du flux de contrôle.
IMAGE_DLLCHARACTERISTICS_ TERMINAL_SERVER_AWARE
0x8000
Prend en charge Terminal Server.

En-têtes facultatifs des répertoires de données (image uniquement)

Chaque répertoire de données fournit l’adresse et la taille d’une table ou d’une chaîne que Windows utilise. Ces entrées de répertoire de données sont toutes chargées en mémoire afin que le système puisse les utiliser au moment de l’exécution. Un répertoire de données est un champ de 8 octets qui contient la déclaration suivante :

typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

Le premier champ, VirtualAddress, est en fait l’adresse virtuelle relative de la table. Cette dernière est l’adresse relative de la table par rapport à l’adresse de base de l’image lorsque la table est chargée. Le deuxième champ fournit la taille en octets. Les répertoires de données, qui constituent la dernière partie de l’en-tête facultatif, sont répertoriés dans le tableau suivant.

Il convient de noter que le nombre de répertoires n’est pas fixe. Avant de rechercher un répertoire spécifique, vérifiez le champ NumberOfRvaAndSizes dans l’en-tête facultatif.

De plus, ne supposez pas que les adresses virtuelles relatives de cette table indiquent le début d’une section ou que les sections qui contiennent des tables spécifiques ont des noms spécifiques.

Décalage (PE/PE32+) Taille Champ Description
96/112
8
Table d’exportation
Adresse et taille de la table d’exportation. Pour plus d’informations, consultez la section .edata (image uniquement).
104/120
8
Table d’importation
Adresse et taille de la table d’importation. Pour en savoir plus, consultez la section .idata.
112/128
8
Table de ressources
Adresse et taille de la table de ressources. Pour en savoir plus, consultez la section .rsrc.
120/136
8
Table des exceptions
Adresse et taille de la table des exceptions. Pour en savoir plus, consultez la section .pdata.
128/144
8
Table de certificats
Adresse et taille de la table de certificats d’attributs. Pour plus d’informations, consultez la Table de certificats d’attributs (image uniquement).
136/152
8
Table de réadressage de base
Adresse et taille de la table de réadressage de base. Pour plus d’informations, consultez la section .reloc (image uniquement).
144/160
8
Déboguer
Adresse et taille de départ des données de débogage. Pour en savoir plus, consultez la section .debug.
152/168
8
Architecture
Réservée, doit être 0
160/176
8
Registre de pointeur global
Adresse virtuelle relative de la valeur à stocker dans le registre de pointeur global. Le membre « taille » de cette structure doit être défini sur zéro.
168/184
8
TLS Table
 Adresse et taille de la table de stockage local de thread (TLS). Pour en savoir plus, consultez la section .tls.
176/192
8
Table de configuration de charge
Adresse et taille de la table de configuration de charge. Pour plus d’informations, consultez la Structure de configuration de charge (image uniquement).
184/200
8
Importation liée
Adresse et taille de la table d’importation liée.
192/208
8
IAT
Adresse et taille de la table d’adresse d’importation. Pour plus d’informations, consultez Table d’adresse d’importation.
200/216
8
Descripteur d’importation différée
Adresse et taille du descripteur d’importation différée. Pour plus d’informations, consultez les Tables d’importation de chargement différé (image uniquement).
208/224
8
En-tête du runtime CLR
Adresse et taille de l’en-tête du runtime CLR. Pour plus d’informations, consultez la section .cormeta (objet uniquement).
216/232
8
Réservée, doit être zéro

L’entrée de la table de certificats pointe vers une table de certificats d’attributs. Ces certificats ne sont pas chargés en mémoire en tant que partie de l’image. Par conséquent, le premier champ de cette entrée, qui est normalement une adresse virtuelle relative, est en fait un pointeur de fichier.

Table de sections (en-têtes de sections)

Chaque ligne du tableau de section est à proprement parler un en-tête de section. Cette table vient immédiatement après l’en-tête optionnel, le cas échéant. Ce positionnement est requis parce que l’en-tête du fichier ne contient pas de pointeur direct vers la table de sections. Au lieu de cela, l’emplacement de la table de sections est déterminé en calculant l’emplacement du premier octet après les en-têtes. Veillez à utiliser la taille de l’en-tête facultatif telle qu’elle est spécifiée dans l’en-tête du fichier.

Le nombre d’entrées dans la table de sections est indiqué dans le champ NumberOfSections de l’en-tête du fichier. Les entrées de la table de sections sont numérotées à partir de un (1). Les entrées des sections de mémoire de code et de données sont dans l’ordre choisi par l’éditeur de liens.

Dans un fichier image, les machines virtuelles des sections doivent être attribuées par l’éditeur de liens de manière à ce qu’elles soient dans l’ordre croissant et adjacentes, et elles doivent être un multiple de la valeur SectionAlignment dans l’en-tête facultatif.

Chaque en-tête de section (entrée de la table de sections) a le format suivant, pour un total de 40 octets par entrée.

Contrepartie Taille Champ Description
0
8
Nom
Une chaîne de 8 octets codée en UTF-8 avec remplissage nul. Si la chaîne contient exactement 8 caractères, le caractère Null de fin n’apparaît pas. Pour les noms plus longs, ce champ contient une barre oblique (/) suivie d’une représentation ASCII d’un nombre décimal qui est un décalage dans la table de chaînes. Les images exécutables n’utilisent pas de table de chaînes et ne prennent pas en charge les noms de sections de plus de 8 caractères. Les noms longs dans les fichiers d’objets qui sont transmis à un fichier exécutable sont tronqués.
8
4
VirtualSize
La taille totale de la section quand elle est chargée en mémoire. Si cette valeur est supérieure à SizeOfRawData, la section est remplie de zéros. Ce champ est valide uniquement pour les images exécutables et doit être défini sur zéro pour les fichiers objet.
12
4
VirtualAddress
Pour les images exécutables, l’adresse du premier octet de la section par rapport à la base d’image lorsque la section est chargée en mémoire. Pour les fichiers objet, ce champ correspond à l’adresse du premier octet avant l’application du réadressage ; pour plus de simplicité, les compilateurs doivent définir cette valeur sur zéro. Dans le cas contraire, il s’agit d’une valeur arbitraire qui est soustraite des décalages lors du réadressage.
16
4
SizeOfRawData
La taille de la section (pour les fichiers objets) ou la taille des données initialisées sur le disque (pour les fichiers image). Pour les images exécutables, il doit s’agir d’un multiple de FileAlignment de l’en-tête facultatif. Si cette valeur est inférieure à VirtualSize, le reste de la section est rempli de zéros. Étant donné que le champ SizeOfRawData est arrondi mais que le champ VirtualSize ne l’est pas, il est possible que SizeOfRawData soit également supérieur à VirtualSize. Lorsqu’une section contient uniquement des données non initialisées, ce champ doit être égal à zéro.
20
4
PointerToRawData
Le pointeur de fichier vers la première page de la section dans le fichier COFF. Pour les images exécutables, il doit s’agir d’un multiple de FileAlignment de l’en-tête facultatif. Pour les fichiers objets, la valeur doit être alignée sur une limite de 4 octets pour des performances optimales. Lorsqu’une section contient uniquement des données non initialisées, ce champ doit être égal à zéro.
24
4
PointerToRelocations
Le pointeur de fichier vers le début des entrées de réadressage pour la section. Cette valeur est définie sur zéro pour les images exécutables ou lorsqu’il n’y a pas de réadressage.
28
4
PointerToLinenumbers
Le pointeur de fichier vers le début des entrées de numéro de ligne pour la section. Cette valeur est définie sur zéro s’il n’y a pas de numéros de ligne COFF. Cette valeur doit être égale à zéro pour une image, car les informations de débogage COFF sont obsolètes.
32
2
NumberOfRelocations
Le nombre d’entrées de réadressage pour la section. Cette valeur est définie sur zéro pour les images exécutables.
34
2
NumberOfLinenumbers
Le nombre d’entrées de numéro de ligne pour la section. Cette valeur doit être égale à zéro pour une image, car les informations de débogage COFF sont obsolètes.
36
4
Caractéristiques
Les indicateurs qui décrivent les caractéristiques de la section. Pour plus d’informations, consultez Indicateurs de sections.

 

Indicateurs de sections

Les indicateurs de section dans le champ Caractéristiques de l’en-tête de section indiquent les caractéristiques de cette dernière.

Indicateur Valeur Description
0x00000000
Réservé pour un usage futur.
0x00000001
Réservé pour un usage futur.
0x00000002
Réservé pour un usage futur.
0x00000004
Réservé pour un usage futur.
IMAGE_SCN_TYPE_NO_PAD
0x00000008
La section ne doit pas être remplie jusqu’à la limite suivante. Cet indicateur est obsolète et est remplacé par IMAGE_SCN_ALIGN_1BYTES. Uniquement valide pour des fichiers objet.
0x00000010
Réservé pour un usage futur.
IMAGE_SCN_CNT_CODE
0x00000020
La section contient du code exécutable.
IMAGE_SCN_CNT_INITIALIZED_DATA
0x00000040
La section contient des données initialisées.
IMAGE_SCN_CNT_UNINITIALIZED_ DATA
0x00000080
La section contient des données non initialisées.
IMAGE_SCN_LNK_OTHER
0x00000100
Réservé pour un usage futur.
IMAGE_SCN_LNK_INFO
0x00000200
La section contient des commentaires ou d’autres informations. La section .drectve est de ce type. Uniquement valide pour des fichiers objet.
0x00000400
Réservé pour un usage futur.
IMAGE_SCN_LNK_REMOVE
0x00000800
La section ne fera pas partie de l’image. Uniquement valide pour des fichiers objet.
IMAGE_SCN_LNK_COMDAT
0x00001000
La section contient des données COMDAT. Pour plus d’informations, consultez les sections COMDAT (uniquement objet). Uniquement valide pour des fichiers objet.
IMAGE_SCN_GPREL
0x00008000
La section contient des données référencées via le pointeur global (GP).
IMAGE_SCN_MEM_PURGEABLE
0x00020000
Réservé pour un usage futur.
IMAGE_SCN_MEM_16BIT
0x00020000
Réservé pour un usage futur.
IMAGE_SCN_MEM_LOCKED
0x00040000
Réservé pour un usage futur.
IMAGE_SCN_MEM_PRELOAD
0x00080000
Réservé pour un usage futur.
IMAGE_SCN_ALIGN_1BYTES
0x00100000
Aligner les données sur une limite de 1 octet. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_2BYTES
0x00200000
Aligner les données sur une limite de 2 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_4BYTES
0x00300000
Aligner les données sur une limite de 4 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_8BYTES
0x00400000
Aligner les données sur une limite de 8 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_16BYTES
0x00500000
Aligner les données sur une limite de 16 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_32BYTES
0x00600000
Aligner les données sur une limite de 32 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_64BYTES
0x00700000
Aligner les données sur une limite de 64 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_128BYTES
0x00800000
Aligner les données sur une limite de 128 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_256BYTES
0x00900000
Aligner les données sur une limite de 256 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_512BYTES
0x00A00000
Aligner les données sur une limite de 512 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_1024BYTES
0x00B00000
Aligner les données sur une limite de 1024 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_2048BYTES
0x00C00000
Aligner les données sur une limite de 2048 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_4096BYTES
0x00D00000
Aligner les données sur une limite de 4096 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_ALIGN_8192BYTES
0x00E00000
Aligner les données sur une limite de 8192 octets. Valide uniquement pour des fichiers objet.
IMAGE_SCN_LNK_NRELOC_OVFL
0x01000000
La section contient des réadressages étendus.
IMAGE_SCN_MEM_DISCARDABLE
0x02000000
La section peut être ignorée en fonction des besoins.
IMAGE_SCN_MEM_NOT_CACHED
0x04000000
La section ne peut pas être mise en cache.
IMAGE_SCN_MEM_NOT_PAGED
0x08000000
La section n’est pas paginable.
IMAGE_SCN_MEM_SHARED
0x10000000
La section peut être partagée en mémoire.
IMAGE_SCN_MEM_EXECUTE
0x20000000
La section peut être exécutée en tant que code.
IMAGE_SCN_MEM_READ
0x40000000
La section peut être lue.
IMAGE_SCN_MEM_WRITE
0x80000000
La section peut être écrite.

 

IMAGE_SCN_LNK_NRELOC_OVFL indique que le nombre de réadressages pour la section dépasse les 16 bits réservés dans ce but dans l’en-tête de section. Si le bit est défini et que le champ NumberOfRelocations dans l’en-tête de section est 0xffff, le nombre réel de réadressages est stocké dans le champ VirtualAddress 32 bits du premier réadressage. Il s’agit d’une erreur si IMAGE_SCN_LNK_NRELOC_OVFL est définie et qu’il y a moins de 0xffff réadressages dans la section.

Sections groupées (objet uniquement)

Le caractère « $ » (symbole de dollar) a une interprétation spéciale dans les noms de sections des fichiers objet.

Lorsqu’il détermine la section d’image qui accueillera le contenu d’une section d’objet, l’éditeur de liens ignore les caractères «$ » et tous les caractères qui le suivent. Ainsi, une section d’objet nommée .text$X contribue dans les faits à la section .text dans l’image.

Toutefois, les caractères qui suivent le symbole « $ » déterminent l’ordre des contributions à la section d’image. Toutes les contributions portant le même nom de section d’objet sont attribuées de manière contiguë dans l’image, et les blocs de contributions sont triés dans l’ordre lexical par nom de section d’objet. Par conséquent, tout ce qui se trouve dans les fichiers objet portant le nom de section .text$X se retrouve ensemble, après les contributions .text$W et avant les contributions .text$Y.

Le nom de section d’un fichier image ne contient jamais de caractère « $ ».

Autres contenus du fichier

Les structures de données décrites jusqu’à présent, y compris l’en-tête facultatif, se trouvent toutes à un distance fixe du début du fichier (ou de l’en-tête PE si le fichier est une image contenant un stub MS-DOS).

Le reste d’un fichier objet ou image COFF contient des blocs de données qui ne sont pas nécessairement situés à une distance spécifique du fichier. Au lieu de cela, les emplacements sont définis par des pointeurs dans l’en-tête facultatif ou un en-tête de section.

Les images dont la valeur de SectionAlignment est inférieure à la taille de page de l’architecture (4 K pour Intel x86 et MIPS, et 8 K pour Itanium) constituent une exception. Pour obtenir une description de SectionAlignment, consultez En-tête facultatif (image uniquement). Dans ce cas, des contraintes s’appliquent au décalage de fichier des données de la section, comme indiqué dans la section 5.1, « Données de section ». Une autre exception concerne le certificat d’attribut et les informations de débogage qui doivent être placés à la toute fin d’un fichier image, la table de certificat d’attribut précédant immédiatement la section de débogage, car le chargeur ne les mappe pas en la mémoire. Toutefois, la règle concernant le certificat d’attribut et les informations de débogage ne s’appliquent pas aux fichiers objet.

Données de section

Les données initialisées pour une section se composent de blocs simples d’octets. Toutefois, pour les sections qui contiennent tous les zéros, il n’est pas nécessaire d’inclure les données de section.

Les données de chaque section sont situées au niveau du décalage de fichier indiqué dans le champ PointerToRawData de l’en-tête de la section. La taille de ces données dans le fichier est indiquée par le champ SizeOfRawData. Si SizeOfRawData est inférieur à VirtualSize, le reste est rempli avec des zéros.

Dans un fichier image, les données de section doivent être alignées sur une limite spécifiée dans le champ FileAlignment de l’en-tête facultatif. Les données de section doivent apparaître dans l’ordre des valeurs des adresses virtuelles relative des sections correspondantes (comme les en-têtes de section individuels dans le tableau des sections).

Des restrictions supplémentaires s’appliquent aux fichiers image si la valeur SectionAlignment de l’en-tête facultatif est inférieure à la taille de la page de l’architecture. Pour ces fichiers, l’emplacement des données de section dans le fichier doit correspondre à leur emplacement en mémoire lorsque l’image est chargée, de sorte que le décalage physique des données de section soit le même que celui de l’adresse virtuelle relative.

Réadressages COFF (objet uniquement)

Les fichiers objet contiennent des réadressages COFF, qui spécifient la façon dont les données de section doivent être modifiées lorsqu’elles sont placées dans le fichier image et chargées ultérieurement en mémoire.

Les fichiers image ne contiennent pas de réadressages COFF, car tous les symboles référencés ont déjà été attribués à des adresses dans un espace d’adressage plat. Une image contient des informations de réadressage sous la forme de réadressages de base dans la section .reloc (sauf si l’image possède l’attribut IMAGE_FILE_RELOCS_STRIPPED). Pour plus d’informations, consultez la section .reloc (image uniquement).

Pour chaque section d’un fichier objet, un tableau d’enregistrements de longueur fixe contient les réadressages COFF de la section. La position et la longueur du tableau sont spécifiées dans l’en-tête de section. Chaque élément du tableau a le format suivant.

Contrepartie Taille Champ Description
0
4
VirtualAddress
Adresse de l’élément auquel le réadressage est appliqué. Il s’agit du décalage à partir du début de la section, plus la valeur du champ RVA/Offset de la section. Consultez le Tableau de sections (en-têtes de sections). Par exemple, si le premier octet de la section a une adresse de 0x10, le troisième octet a une adresse de 0x12.
4
4
SymbolTableIndex
Index de base zéro dans la table de symboles. Ce symbole indique l’adresse à utiliser pour le réadressage. Si le symbole spécifié possède une classe de stockage de section, l’adresse du symbole est celle de la première section du même nom.
8
2
Type
Valeur qui indique le type de réadressage qui doit être effectué. Les types de réadressage valides dépendent du type d’ordinateur. Consulter Indicateurs de type.

 

Si le symbole référencé par le champ SymbolTableIndex possède la classe de stockage IMAGE_SYM_CLASS_SECTION, l’adresse du symbole constitue le début de la section. La section se trouve généralement dans le même fichier, sauf lorsque le fichier objet fait partie d’une archive (bibliothèque). Dans un tel cas, on peut trouver la section dans n’importe quel autre fichier objet de l’archive qui a le même nom de membre d’archive que le fichier objet actuel. (La relation avec le nom de membre d’archive est utilisée dans la liaison de tables d’importation, autrement dit, la section .idata.)

Indicateurs de type

Le champ Type de l’enregistrement de réadressage indique le type de réadressage à effectuer. Différents types de réadressage sont définis pour chaque type d’ordinateur.

Processeur x64

Les indicateurs de type de réadressage suivants sont définis pour les processeurs x64 et compatibles.

Constant Valeur Description
IMAGE_REL_AMD64_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_AMD64_ADDR64
0x0001
Adresse virtuelle 64 bits de la cible de réadressage.
IMAGE_REL_AMD64_ADDR32
0x0002
Adresse virtuelle 32 bits de la cible de réadressage.
IMAGE_REL_AMD64_ADDR32NB
0x0003
Adresse 32 bits sans base d’image (RVA).
IMAGE_REL_AMD64_REL32
0x0004
Adresse 32 bits relative à partir de l’octet suivant le réadressage.
IMAGE_REL_AMD64_REL32_1
0x0005
Adresse 32 bits relative à la distance de l’octet 1 par rapport au réadressage.
IMAGE_REL_AMD64_REL32_2
0x0006
Adresse 32 bits relative à la distance de l’octet 2 par rapport au réadressage.
IMAGE_REL_AMD64_REL32_3
0x0007
Adresse 32 bits relative à la distance de l’octet 3 par rapport au réadressage.
IMAGE_REL_AMD64_REL32_4
0x0008
Adresse 32 bits relative à la distance de l’octet 4 par rapport au réadressage.
IMAGE_REL_AMD64_REL32_5
0x0009
Adresse 32 bits relative à la distance de l’octet 5 par rapport au réadressage.
IMAGE_REL_AMD64_SECTION
0x000A
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_AMD64_SECREL
0x000B
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_AMD64_SECREL7
0x000C
Décalage non signé 7 bits à partir de la base de la section qui contient la cible.
IMAGE_REL_AMD64_TOKEN
0x000D
Jetons CLR.
IMAGE_REL_AMD64_SREL32
0x000E
Valeur signée 31 bit dépendante de l’étendue émise dans l’objet.
IMAGE_REL_AMD64_PAIR
0x000F
Paire qui doit suivre immédiatement chaque valeur dépendante de l’étendue.
IMAGE_REL_AMD64_SSPAN32
0x0010
Valeur signée 32 bits dépendante de l’étendue qui est appliquée au moment de la liaison.

 

Processeurs ARM

Les indicateurs de type de réadressage suivants sont définis pour les processeurs ARM.

Constant Valeur Description
IMAGE_REL_ARM_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_ARM_ADDR32
0x0001
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_ARM_ADDR32NB
0x0002
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_ARM_BRANCH24
0x0003
Déplacement relatif 24 bits par rapport à la cible.
IMAGE_REL_ARM_BRANCH11
0x0004
Référence à un appel de sous-routine. La référence se compose de deux instructions 16 bits avec des décalages 11 bits.
IMAGE_REL_ARM_REL32
0x000A
Adresse 32 bits relative à partir de l’octet suivant le réadressage.
IMAGE_REL_ARM_SECTION
0x000E
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_ARM_SECREL
0x000F
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_ARM_MOV32
0x0010
Adresse virtuelle 32 bits de la cible. Ce réadressage est appliqué au moyen d’une instruction MOVW pour les 16 bits de poids faible suivis d’un MOVT pour les 16 bits de poids fort.
IMAGE_REL_THUMB_MOV32
0x0011
Adresse virtuelle 32 bits de la cible. Ce réadressage est appliqué au moyen d’une instruction MOVW pour les 16 bits de poids faible suivis d’un MOVT pour les 16 bits de poids fort.
IMAGE_REL_THUMB_BRANCH20
0x0012
L’instruction est corrigée avec le déplacement relatif de 21 bits par rapport à la cible alignée de 2 octets. Le bit le moins significatif du déplacement est toujours égal à zéro et n’est pas stocké. Ce réadressage correspond à une instruction B conditionnelle 32 bits de Thumb-2
Inutilisé
0x0013
IMAGE_REL_THUMB_BRANCH24
0x0014
L’instruction est corrigée avec le déplacement relatif de 25 bits par rapport à la cible alignée de 2 octets. Le bit le moins significatif du déplacement est égal à zéro et n’est pas stocké. Ce déplacement correspond à une instruction Thumb-2 B.
IMAGE_REL_THUMB_BLX23
0x0015
L’instruction est corrigée avec le déplacement relatif de 25 bits par rapport à la cible alignée de 4 octets. Les 2 bits de poids faibles du déplacement sont nuls et ne sont pas stockés.
Ce réadressage correspond à une instruction BLX Thumb-2.
IMAGE_REL_ARM_PAIR
0x0016
Le réadressage est uniquement valide lorsqu’il suit immédiatement un ARM_REFHI ou THUMB_REFHI. Son SymbolTableIndex contient un déplacement et non un index dans la table de symboles.

 

Processeurs ARM64

Les indicateurs de type de réadressage suivants sont définis pour les processeurs ARM64.

Constant Valeur Description
IMAGE_REL_ARM64_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_ARM64_ADDR32
0x0001
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_ARM64_ADDR32NB
0x0002
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_ARM64_BRANCH26
0x0003
Déplacement relatif 26 bits vers la cible, pour les instructions B et BL.
IMAGE_REL_ARM64_PAGEBASE_REL21
0x0004
Base de page de la cible, pour l’instruction ADRP.
IMAGE_REL_ARM64_REL21
0x0005
Déplacement relatif 12 bits vers la cible, pour l’instruction ADR
IMAGE_REL_ARM64_PAGEOFFSET_12A
0x0006
Décalage de page 12 bits de la cible, pour les instructions ADD/ADDS (immédiat) avec zéro décalage.
IMAGE_REL_ARM64_PAGEOFFSET_12L
0x0007
Décalage de page 12 bits de la cible, pour l’instruction LDR (indexée, non signée immédiatement).
IMAGE_REL_ARM64_SECREL
0x0008
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_ARM64_SECREL_LOW12A
0x0009
Bit 0:11 du décalage de section de la cible, pour les instructions ADD/ADDS (immédiate) avec zéro décalage.
IMAGE_REL_ARM64_SECREL_HIGH12A
0x000A
Bit 12:23 du décalage de section de la cible, pour les instructions ADD/ADDS (immédiate) avec zéro décalage.
IMAGE_REL_ARM64_SECREL_LOW12L
0x000B
Bit 0:11 du décalage de section de la cible, pour l’instruction LDR (indexée, non signée immédiate).
IMAGE_REL_ARM64_TOKEN
0x000C
Jeton CLR.
IMAGE_REL_ARM64_SECTION
0x000D
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_ARM64_ADDR64
0x000E
Adresse virtuelle 64 bits de la cible de réadressage.
IMAGE_REL_ARM64_BRANCH19
0x000F
Décalage 19 bits par rapport à la cible de réadressage, pour l’instruction B conditionnelle.
IMAGE_REL_ARM64_BRANCH14
0x0010
Décalage 14 bits par rapport à la cible de réadressage, pour les instructions TBZ et TBNZ.
IMAGE_REL_ARM64_REL32
0x0011
Adresse 32 bits relative à partir de l’octet suivant le réadressage.
Processeurs SuperH Hitachi

Les indicateurs de type de réadressage suivants sont définis pour les processeurs SH3 et SH4. Les réadressages spécifiques à SH5 sont notés comme SHM (SH Media).

Constant Valeur Description
IMAGE_REL_SH3_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_SH3_DIRECT16
0x0001
Référence à l’emplacement 16 bits qui contient l’évaluation de vulnérabilité du symbole cible.
IMAGE_REL_SH3_DIRECT32
0x0002
Adresse virtuelle 32 bits du symbole cible.
IMAGE_REL_SH3_DIRECT8
0x0003
Référence à l’emplacement 8 bits qui contient l’évaluation de vulnérabilité du symbole cible.
IMAGE_REL_SH3_DIRECT8_WORD
0x0004
Référence à l’instruction 8 bits qui contient l’adresse virtuelle 16 bits effective du symbole cible.
IMAGE_REL_SH3_DIRECT8_LONG
0x0005
Référence à l’instruction 8 bits qui contient l’adresse virtuelle 32 bits effective du symbole cible.
IMAGE_REL_SH3_DIRECT4
0x0006
Référence à l’emplacement 8 bits dont les 4 bits de poids faible contiennent l’adresse virtuelle du symbole cible.
IMAGE_REL_SH3_DIRECT4_WORD
0x0007
Référence à l’instruction 8 bits dont les 4 bits de poids faible contiennent l’adresse virtuelle 16 bits effective du symbole cible.
IMAGE_REL_SH3_DIRECT4_LONG
0x0008
Référence à l’instruction 8 bits dont les 4 bits de poids faible contiennent l’adresse virtuelle 32 bits effective du symbole cible.
IMAGE_REL_SH3_PCREL8_WORD
0x0009
Référence à l’instruction 8 bits qui contient le décalage relatif 16 bits effectif du symbole cible.
IMAGE_REL_SH3_PCREL8_LONG
0x000A
Référence à l’instruction 8 bits qui contient le décalage relatif 32 bits effectif du symbole cible.
IMAGE_REL_SH3_PCREL12_WORD
0x000B
Référence à l’instruction 16 bits dont les 12 bits de poids faible contiennent le décalage relatif 16 bits effectif du symbole cible.
IMAGE_REL_SH3_STARTOF_SECTION
0x000C
Référence à un emplacement 32 bits qui est l’adresse virtuelle de la section qui contient le symbole cible.
IMAGE_REL_SH3_SIZEOF_SECTION
0x000D
Référence à l’emplacement 32 bits qui est la taille de la section qui contient le symbole cible.
IMAGE_REL_SH3_SECTION
0x000E
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_SH3_SECREL
0x000F
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_SH3_DIRECT32_NB
0x0010
Adresse virtuelle relative 32 bits du symbole cible.
IMAGE_REL_SH3_GPREL4_LONG
0x0011
GP relative.
IMAGE_REL_SH3_TOKEN
0x0012
Jeton CLR.
IMAGE_REL_SHM_PCRELPT
0x0013
Décalage par rapport à l’instruction actuelle en mots longs. Si le bit NOMODE n’est pas défini, insérez l’inverse du bit de poids faible au bit 32 pour sélectionner PTA ou PTB.
IMAGE_REL_SHM_REFLO
0x0014
Les 16 bits de poids faible de l’adresse 32 bits.
IMAGE_REL_SHM_REFHALF
0x0015
Les 16 bits de poids fort de l’adresse 32 bits.
IMAGE_REL_SHM_RELLO
0x0016
Les 16 bits de poids faible de l’adresse relative.
IMAGE_REL_SHM_RELHALF
0x0017
Les 16 bits de poids fort de l’adresse relative.
IMAGE_REL_SHM_PAIR
0x0018
Le réadressage est uniquement valide lorsqu’il suit immédiatement un réadressage REFHALF, RELHALF ou RELLO. Le champ SymbolTableIndex du réadressage contient un déplacement et non un index dans la table de symboles.
IMAGE_REL_SHM_NOMODE
0x8000
Le réadressage ignore le mode section.

 

Processeurs IBM PowerPC

Les indicateurs de type de réadressage suivants sont définis pour les processeurs PowerPC.

Constant Valeur Description
IMAGE_REL_PPC_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_PPC_ADDR64
0x0001
Adresse virtuelle 64 bits de la cible.
IMAGE_REL_PPC_ADDR32
0x0002
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_PPC_ADDR24
0x0003
Les 24 bits de poids faible de l’adresse virtuelle de la cible. Cela est valide uniquement lorsque le symbole cible est absolu et peut être étendu à sa valeur d’origine.
IMAGE_REL_PPC_ADDR16
0x0004
Les 16 bits de poids faible de l’adresse virtuelle de la cible.
IMAGE_REL_PPC_ADDR14
0x0005
Les 14 bits de poids faible de l’adresse virtuelle de la cible. Cela est valide uniquement lorsque le symbole cible est absolu et peut être étendu à sa valeur d’origine.
IMAGE_REL_PPC_REL24
0x0006
Décalage relatif PC 24 bits par rapport à l’emplacement du symbole.
IMAGE_REL_PPC_REL14
0x0007
Décalage relatif PC 14 bits par rapport à l’emplacement du symbole.
IMAGE_REL_PPC_ADDR32NB
0x000A
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_PPC_SECREL
0x000B
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_PPC_SECTION
0x000C
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_PPC_SECREL16
0x000F
Décalage 16 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_PPC_REFHI
0x0010
Les 16 bits de poids fort de l’adresse virtuelle 32 bits de la cible. Cela est utilisé pour la première instruction d’une séquence présentant deux instructions qui charge une adresse complète. Ce réadressage doit être immédiatement suivi d’un réadressage PAIR dont SymbolTableIndex contient un déplacement 16 bits signé qui est ajouté aux 16 bits de poids fort qui ont été pris à partir de l’emplacement en cours de réadressage.
IMAGE_REL_PPC_REFLO
0x0011
Les 16 bits de poids faible de l’adresse virtuelle de la cible.
IMAGE_REL_PPC_PAIR
0x0012
Réadressage valide uniquement lorsqu’il suit immédiatement un réadressage REFHI ou SECRELHI. Son SymbolTableIndex contient un déplacement et non un index dans la table de symboles.
IMAGE_REL_PPC_SECRELLO
0x0013
Les 16 bits de poids faible du décalage 32 bits de la cible à partir du début de sa section.
IMAGE_REL_PPC_GPREL
0x0015
Déplacement signé 16 bits de la cible par rapport au registre GP.
IMAGE_REL_PPC_TOKEN
0x0016
Jeton CLR.

 

Processeurs Intel 386

Les indicateurs de type de réadressage suivants sont définis pour les processeurs Intel 386 et compatibles.

Constant Valeur Description
IMAGE_REL_I386_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_I386_DIR16
0x0001
Non pris en charge.
IMAGE_REL_I386_REL16
0x0002
Non pris en charge.
IMAGE_REL_I386_DIR32
0x0006
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_I386_DIR32NB
0x0007
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_I386_SEG12
0x0009
Non pris en charge.
IMAGE_REL_I386_SECTION
0x000A
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_I386_SECREL
0x000B
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_I386_TOKEN
0x000C
Jeton CLR.
IMAGE_REL_I386_SECREL7
0x000D
Décalage 7 bits à partir de la base de la section qui contient la cible.
IMAGE_REL_I386_REL32
0x0014
Déplacement relatif 32 bits par rapport à la cible. Il prend en charge les instructions de branche et d’appel relatives de l’architecture x86.

 

Famille de processeurs Intel Itanium (IPF)

Les indicateurs de type de réadressage suivants sont définis pour la famille de processeurs Intel Itanium et les processeurs compatibles. Il convient de noter que les réadressages sur les instructions utilisent le décalage et le numéro d’emplacement du bundle pour le décalage du réadressage.

Constant Valeur Description
IMAGE_REL_IA64_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_IA64_IMM14
0x0001
Le réadressage d’instructions peut être suivie d’un réadressage ADDEND dont la valeur est ajoutée à l’adresse cible avant d’être insérée dans l’emplacement spécifié dans le bundle IMM14. La cible de réadressage doit être absolue ou l’image doit être fixe.
IMAGE_REL_IA64_IMM22
0x0002
Le réadressage d’instructions peut être suivie d’un réadressage ADDEND dont la valeur est ajoutée à l’adresse cible avant d’être insérée dans l’emplacement spécifié dans le bundle IMM22. La cible de réadressage doit être absolue ou l’image doit être fixe.
IMAGE_REL_IA64_IMM64
0x0003
Le numéro d’emplacement de ce réadressage doit être un (1). Le réadressage peut être suivie d’un réadressage ADDEND dont la valeur est ajoutée à l’adresse cible avant qu’elle ne soit stockée dans les trois emplacements du bundle IMM64.
IMAGE_REL_IA64_DIR32
0x0004
Adresse virtuelle 32 bits de la cible. Uniquement pris en charge pour les images /LARGEADDRESSAWARE :NO.
IMAGE_REL_IA64_DIR64
0x0005
Adresse virtuelle 64 bits de la cible.
IMAGE_REL_IA64_PCREL21B
0x0006
L’instruction est corrigée avec le déplacement relatif de 25 bits par rapport à la cible alignée de 16 bits. Les 4 bits de poids faibles du déplacement sont nuls et ne sont pas stockés.
IMAGE_REL_IA64_PCREL21M
0x0007
L’instruction est corrigée avec le déplacement relatif de 25 bits par rapport à la cible alignée de 16 bits. Les 4 bits de poids faibles du déplacement sont nuls et ne sont pas stockés.
IMAGE_REL_IA64_PCREL21F
0x0008
Les LSB de ce décalage de réadressage doivent contenir le numéro d’emplacement, tandis que le reste est l’adresse du bundle. Le bundle est corrigé avec le déplacement relatif de 25 bits par rapport à la cible alignée de 16 bits. Les 4 bits de poids faibles du déplacement sont nuls et ne sont pas stockés.
IMAGE_REL_IA64_GPREL22
0x0009
Le réadressage de l’instruction peut être suivi d’un réadressage ADDEND dont la valeur est ajoutée à l’adresse cible, puis d’un décalage relatif à GP 22 bits calculé et appliqué au bundle GPREL22.
IMAGE_REL_IA64_LTOFF22
0x000A
L’instruction est corrigée avec le décalage relatif GP 22 bits à l’entrée de table littérale du symbole cible. L’éditeur de liens crée cette entrée de table littérale en fonction de ce réadressage et du réadressage ADDEND qui peut suivre.
IMAGE_REL_IA64_SECTION
0x000B
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_IA64_SECREL22
0x000C
L’instruction est corrigée avec le décalage 22 bits de la cible à partir du début de sa section. Ce réadressage peut être suivi immédiatement par un réadressage ADDEND, dont le champ Valeur contient le décalage non signé 32 bits de la cible à partir du début de la section.
IMAGE_REL_IA64_SECREL64I
0x000D
Le numéro d’emplacement de ce réadressage doit être un (1). L’instruction est corrigée avec le décalage 64 bits de la cible à partir du début de sa section. Ce réadressage peut être suivi immédiatement par un réadressage ADDEND, dont le champ Valeur contient le décalage non signé 32 bits de la cible à partir du début de la section.
IMAGE_REL_IA64_SECREL32
0x000E
Adresse des données à corriger avec le décalage 32 bits de la cible à partir du début de sa section.
IMAGE_REL_IA64_DIR32NB
0x0010
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_IA64_SREL14
0x0011
Ceci s’applique à un immédiat de 14 bits signé qui contient la différence entre deux cibles réadressables. Il s’agit d’un champ déclaratif pour l’éditeur de liens indiquant que le compilateur a déjà émis cette valeur.
IMAGE_REL_IA64_SREL22
0x0012
Ceci s’applique à un immédiat de 22 bits signé qui contient la différence entre deux cibles réadressables. Il s’agit d’un champ déclaratif pour l’éditeur de liens indiquant que le compilateur a déjà émis cette valeur.
IMAGE_REL_IA64_SREL32
0x0013
Ceci s’applique à un immédiat de 32 bits signé qui contient la différence entre deux valeurs réadressables. Il s’agit d’un champ déclaratif pour l’éditeur de liens indiquant que le compilateur a déjà émis cette valeur.
IMAGE_REL_IA64_UREL32
0x0014
Ceci s’applique à un immédiat de 32 bits non signé qui contient la différence entre deux valeurs réadressables. Il s’agit d’un champ déclaratif pour l’éditeur de liens indiquant que le compilateur a déjà émis cette valeur.
IMAGE_REL_IA64_PCREL60X
0x0015
Correctif relatif au PC 60 bits qui reste toujours une instruction BRL d’un bundle MLX.
IMAGE_REL_IA64_PCREL60B
0x0016
Correctif relatif au PC 60 bits. Si le déplacement cible tient dans un champ signé de 25 bits, convertissez la totalité du bundle en bundle MBB avec NOP.B dans l’emplacement 1 et une instruction BR de 25 bits (avec les 4 bits de poids le plus faible tous sur zéro et supprimés) dans l’emplacement 2.
IMAGE_REL_IA64_PCREL60F
0x0017
Correctif relatif au PC 60 bits. Si le déplacement cible tient dans un champ signé de 25 bits, convertissez la totalité du bundle en bundle MFB avec NOP.F dans l’emplacement 1 et une instruction BR de 25 bits (avec les 4 bits de poids le plus faible tous sur zéro et supprimés) dans l’emplacement 2.
IMAGE_REL_IA64_PCREL60I
0x0018
Correctif relatif au PC 60 bits. Si le déplacement cible tient dans un champ signé de 25 bits, convertissez la totalité du bundle en bundle MIB avec NOP.I dans l’emplacement 1 et une instruction BR de 25 bits (avec les 4 bits de poids le plus faible tous sur zéro et supprimés) dans l’emplacement 2.
IMAGE_REL_IA64_PCREL60M
0x0019
Correctif relatif au PC 60 bits. Si le déplacement cible tient dans un champ signé de 25 bits, convertissez la totalité du bundle en bundle MMB avec NOP.M dans l’emplacement 1 et une instruction BR de 25 bits (avec les 4 bits de poids le plus faible tous sur zéro et supprimés) dans l’emplacement 2.
IMAGE_REL_IA64_IMMGPREL64
0x001a
Correctif relatif à GP 64 bits.
IMAGE_REL_IA64_TOKEN
0x001b
Jeton CLR.
IMAGE_REL_IA64_GPREL32
0x001c
Correctif relatif à GP 32 bits.
IMAGE_REL_IA64_ADDEND
0x001F
Le réadressage est uniquement valide lorsqu’il suit immédiatement l’un des réadressages suivants : IMM14, IMM22, IMM64, GPREL22, LTOFF22, LTOFF64, SECREL22, SECREL64I ou SECREL32. Sa valeur contient le complément à appliquer aux instructions d’un bundle, et non pour les données.

 

Processeurs MIPS

Les indicateurs de type de réadressage suivants sont définis pour les processeurs MIPS.

Constant Valeur Description
IMAGE_REL_MIPS_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_MIPS_REFHALF
0x0001
Les 16 bits de poids fort de l’adresse virtuelle 32 bits de la cible.
IMAGE_REL_MIPS_REFWORD
0x0002
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_MIPS_JMPADDR
0x0003
Les 26 bits de poids faible de l’adresse virtuelle de la cible. Cela prend en charge les instructions J ET JAL MIPS.
IMAGE_REL_MIPS_REFHI
0x0004
Les 16 bits de poids fort de l’adresse virtuelle 32 bits de la cible. Cela est utilisé pour la première instruction d’une séquence présentant deux instructions qui charge une adresse complète. Ce réadressage doit être immédiatement suivi d’un réadressage PAIR dont SymbolTableIndex contient un déplacement 16 bits signé qui est ajouté aux 16 bits de poids fort qui sont pris à partir de l’emplacement en cours de réadressage.
IMAGE_REL_MIPS_REFLO
0x0005
Les 16 bits de poids faible de l’adresse virtuelle de la cible.
IMAGE_REL_MIPS_GPREL
0x0006
Déplacement signé 16 bits de la cible par rapport au registre GP.
IMAGE_REL_MIPS_LITERAL
0x0007
Identique à IMAGE_REL_MIPS_GPREL.
IMAGE_REL_MIPS_SECTION
0x000A
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_MIPS_SECREL
0x000B
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_MIPS_SECRELLO
0x000C
Les 16 bits de poids faible du décalage 32 bits de la cible à partir du début de sa section.
IMAGE_REL_MIPS_SECRELHI
0x000D
Les 16 bits de poids fort du décalage 32 bits de la cible à partir du début de sa section. Un réadressage IMAGE_REL_MIPS_PAIR doit immédiatement le suivre. Le SymbolTableIndex du réadressage PAIR contient un déplacement 16 bits signé qui est ajouté aux 16 bits de poids fort extraits de l’emplacement en cours du réadressage.
IMAGE_REL_MIPS_JMPADDR16
0x0010
Les 26 bits de poids faible de l’adresse virtuelle de la cible. Cela prend en charge l’instruction JAL MIPS16.
IMAGE_REL_MIPS_REFWORDNB
0x0022
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_MIPS_PAIR
0x0025
Réadressage valide uniquement lorsqu’il suit immédiatement un réadressage REFHI ou SECRELHI. Son SymbolTableIndex contient un déplacement et non un index dans la table de symboles.

 

Mitsubishi M32R

Les indicateurs de type de réadressage suivants sont définis pour les processeurs Mitsubishi M32R.

Constant Valeur Description
IMAGE_REL_M32R_ABSOLUTE
0x0000
Le réadressage est ignoré.
IMAGE_REL_M32R_ADDR32
0x0001
Adresse virtuelle 32 bits de la cible.
IMAGE_REL_M32R_ADDR32NB
0x0002
Adresse virtuelle relative 32 bits de la cible.
IMAGE_REL_M32R_ADDR24
0x0003
Adresse virtuelle 24 bits de la cible.
IMAGE_REL_M32R_GPREL16
0x0004
Décalage 16 bits de la cible à partir du registre GP.
IMAGE_REL_M32R_PCREL24
0x0005
Décalage 24 bits de la cible à partir du compteur de programme (PC), déplacé à gauche de 2 bits et signe étendu
IMAGE_REL_M32R_PCREL16
0x0006
Décalage 16 bits de la cible à partir du PC, déplacé à gauche de 2 bits et signe étendu
IMAGE_REL_M32R_PCREL8
0x0007
Décalage 8 bits de la cible à partir du PC, déplacé à gauche de 2 bits et signe étendu
IMAGE_REL_M32R_REFHALF
0x0008
16 MSB de l’évaluation des vulnérabilité de la cible.
IMAGE_REL_M32R_REFHI
0x0009
16 MSB de l’adresse virtuelle de la cible, ajustés pour l’extension de signature LSB. Cela est utilisé pour la première instruction d’une séquence présentant deux instructions qui charge une adresse 32 bits complète. Ce réadressage doit être immédiatement suivi d’un réadressage PAIR dont SymbolTableIndex contient un déplacement 16 bits signé qui est ajouté aux 16 bits de poids fort qui sont pris à partir de l’emplacement en cours de réadressage.
IMAGE_REL_M32R_REFLO
0x000A
16 LSB de l’évaluation des vulnérabilité de la cible.
IMAGE_REL_M32R_PAIR
0x000B
Le réadressage doit suivre le réadressage REFHI. Son SymbolTableIndex contient un déplacement et non un index dans la table de symboles.
IMAGE_REL_M32R_SECTION
0x000C
Index de section 16 bits de la section qui contient la cible. Il est utilisé pour prendre en charge les informations de débogage.
IMAGE_REL_M32R_SECREL
0x000D
Décalage 32 bits de la cible par rapport au début de sa section. Il est utilisé pour prendre en charge les informations de débogage et le stockage local des threads de type statique.
IMAGE_REL_M32R_TOKEN
0x000E
Jeton CLR.

 

Numéros de ligne COFF (obsolètes)

Les numéros de ligne COFF ne sont plus produits et, à l’avenir, ne seront pas consommés.

Les numéros de ligne COFF indiquent la relation entre le code et les numéros de ligne dans les fichiers sources. Le format Microsoft pour les numéros de ligne COFF est similaire à un COFF standard, mais il a été étendu pour permettre à une section unique de se rapporter aux numéros de ligne dans plusieurs fichiers sources.

Les numéros de ligne COFF se composent d’un tableau d’enregistrements de longueur fixe. L’emplacement (décalage de fichiers) et la taille du tableau sont spécifiés dans l’en-tête de section. Chaque enregistrement de numéro de ligne est au format suivant.

Contrepartie Taille Champ Description
0
4
Type (*)
Il s’agit d’une union de deux champs : SymbolTableIndex et VirtualAddress. L’utilisation de SymbolTableIndex ou de l’adresse virtuelle relative dépend de la valeur de Linenumber.
4
2
Linenumber
S’il est différent de zéro, ce champ indique un numéro de ligne bas sur un. Lorsqu’il est égal à zéro, le champ Type est interprété comme un index de table de symboles pour une fonction.

 

Le champ Type est une union de deux champs de 4 octets : SymbolTableIndex et VirtualAddress.

Contrepartie Taille Champ Description
0
4
SymbolTableIndex
Utilisé lorsque Linenumber est égal à zéro : index de l’entrée de la table des symboles pour une fonction. Ce format est utilisé pour indiquer la fonction à laquelle un groupe d’enregistrements de numéro de ligne fait référence.
0
4
VirtualAddress
Utilisée lorsque linenumber est différent de zéro : l’adresse virtuelle relative du code exécutable qui correspond à la ligne source indiquée. Dans un fichier objet, il contient l’adresse virtuelle relative dans la section.

 

Un enregistrement de numéro de ligne peut soit définir le champ Linenumber sur zéro et pointer vers une définition de fonction dans la table des symboles, soit fonctionner comme une entrée de numéro de ligne standard en donnant un nombre entier positif (numéro de ligne) et l’adresse correspondante dans le code objet.

Un groupe d’entrées de numéros de ligne commence toujours par le premier format : l’index d’un symbole de fonction. S’il s’agit du premier enregistrement de numéro de ligne dans la section, il s’agit également du nom du symbole COMDAT pour la fonction si l’indicateur COMDAT de la section est défini. Consulter Sections COMDAT (objet uniquement). L’enregistrement auxiliaire de la fonction dans la table de symboles possède un pointeur vers le champ Linenumber qui pointe vers ce même enregistrement de numéro de ligne.

Un enregistrement qui identifie une fonction est suivi d’un certain nombre d’entrées de numéros de ligne qui donnent des informations réelles sur les numéros de ligne (c’est-à-dire des entrées dont le Linenumber est supérieur à zéro). Ces entrées sont basées sur un, par rapport au début de la fonction, et représentent chaque ligne source de cette dernière, à l’exception de la première.

Par exemple, le premier enregistrement de numéro de ligne pour l’exemple suivant spécifie la fonction ReverseSign (SymbolTableIndex de ReverseSign et Linenumber défini sur zéro). Ensuite, les enregistrements avec les valeurs Linenumber de 1, 2 et 3 suivent, correspondant aux lignes sources comme indiqué :

// some code precedes ReverseSign function
int ReverseSign(int i)
1: {
2:  return -1 * i;
3: }

Table de symboles COFF

La table de symboles de cette section est héritée du format COFF traditionnel. Elle est différente des informations de débogage Microsoft Visual C++. Un fichier peut contenir à la fois une table de symboles COFF et des informations de débogage Visual C++, et les deux sont conservées séparément. Certains outils Microsoft utilisent la table de symboles à des fins limitées mais essentielles, notamment la communication d’informations COMDAT à l’éditeur de liens. Les noms de sections et les noms de fichiers, ainsi que les symboles de code et de données, sont répertoriés dans la table de symboles.

L’emplacement de la table de symboles est indiqué dans l’en-tête COFF.

La table de symboles est un tableau d’enregistrements de 18 octets chacun. Chaque enregistrement est un enregistrement de table de symboles standard ou auxiliaire. Un enregistrement standard définit un symbole ou un nom et a le format suivant.

Contrepartie Taille Champ Description
0
8
Nom (*)
Nom du symbole représenté par une union de trois structures. Un tableau de 8 octets est utilisé si la longueur du nom ne dépasse pas 8 octets. Pour en savoir plus, consultez Représentation du nom de symbole.
8
4
Valeur
La valeur qui est associée au symbole. L’interprétation de ce champ dépend de SectionNumber et de StorageClass. Une signification typique est l’adresse réadressable.
12
2
SectionNumber
Entier signé qui identifie la section à l’aide d’un index de base un dans la table de sections. Certaines valeurs ont une signification spéciale, définie dans la section 5.4.2, « Valeurs du numéro de section ».
14
2
Tapez .
 Nombre qui représente le type. Les outils Microsoft définissent ce champ sur 0x20 (fonction) ou 0x0 (pas une fonction). Pour en savoir plus, voir Représentation du type.
16
1
StorageClass
Valeur énumérée qui représente la classe de stockage. Pour en savoir plus, consultez Classe de stockage.
17
1
NumberOfAuxSymbols
Nombre d’entrées de la table des symboles auxiliaires qui suivent cet enregistrement.

 

Zéro ou plusieurs enregistrements de table de symboles auxiliaires suivent immédiatement chaque enregistrement de table de symboles standard. Toutefois, un enregistrement auxiliaire de la table des symboles ne suit généralement pas plus d’un enregistrement de la table des symboles standard (sauf pour les enregistrements .file avec de longs noms de fichiers). Chaque enregistrement auxiliaire a la même taille qu’un enregistrement standard de la table des symboles (18 octets), mais au lieu de définir un nouveau symbole, l’enregistrement auxiliaire donne des informations supplémentaires sur le dernier symbole défini. Le choix entre les différents formats à utiliser dépend du champ StorageClass. Les formats actuellement définis pour les enregistrements de table de symboles auxiliaires sont présentés dans la section 5.5, « Enregistrements des symboles auxiliaires ».

Les outils qui lisent les tables de symboles COFF doivent ignorer les enregistrements de symboles auxiliaires dont l’interprétation est inconnue. Il est ainsi possible d’étendre le format de la table de symboles afin d’ajouter de nouveaux enregistrements auxiliaires, sans perturber les outils existants.

Représentation du nom de symbole

Le champ ShortName d’une table de symboles se compose de 8 octets qui contiennent le nom lui-même, si sa longueur n’est pas supérieure à 8 octets, ou le champ ShortName donne un décalage dans la table de chaînes. Pour déterminer s’il s’agit du nom lui-même ou d’un décalage, il faut vérifier que les 4 premiers octets sont égaux à zéro.

Par convention, les noms sont traités comme des chaînes encodées UTF-8 terminées par zéro.

Contrepartie Taille Champ Description
0
8
ShortName
Un tableau de 8 octets. Ce tableau est rempli avec des valeurs Null à droite si la longueur du nom est inférieure à 8 octets.
0
4
Zéros
Un champ qui prend la valeur zéro si le nom est plus long que 8 octets.
4
4
Décalage
Décalage dans la table de chaînes.

 

Valeurs du numéro de section

En principe, le champ Valeur de la section dans une entrée de la table des symboles est un index de base un dans la table des sections. Mais ce champ est un nombre entier signé et peut prendre des valeurs négatives. Les valeurs suivantes, inférieures à un, ont des significations spéciales.

Constant Valeur Description
IMAGE_SYM_UNDEFINED
0
L’enregistrement de symboles n’est pas encore affecté à une section. La valeur zéro indique qu’une référence à un symbole externe est définie ailleurs. Une valeur différente de zéro est un symbole commun dont la taille est spécifiée par la valeur.
IMAGE_SYM_ABSOLUTE
1-
Le symbole a une valeur absolue (non réadressable) et n’est pas une adresse.
IMAGE_SYM_DEBUG
2-
Le symbole fournit des informations générales de type ou de débogage, mais ne correspond pas à une section. Les outils Microsoft utilisent ce paramètre avec les enregistrements .file (classe de stockage FILE).

 

Représentation du type

Le champ Type d’une entrée de table de symboles comprend 2 octets, chaque octet représentant une information sur le type. Le LSB représente le type de données simple (de base) et le MSB représente le type complexe, le cas échéant :

MSB LSB
Type complexe : aucun, pointeur, fonction, tableau.
Type de base : entier, virgule flottante et ainsi de suite.

 

Les valeurs suivantes sont définies pour le type de base, bien que les outils Microsoft n’utilisent généralement pas ce champ et définissent le LSB sur 0. Au lieu de cela, les informations de débogage Visual C++ sont utilisées pour indiquer les types. Toutefois, les valeurs COFF possibles sont répertoriées ici par souci d’exhaustivité.

Constant Valeur Description
IMAGE_SYM_TYPE_NULL
0
Aucune information de type ou type de base inconnu. Les outils Microsoft utilisent ce paramètre
IMAGE_SYM_TYPE_VOID
1
Aucun type valide ; utilisé avec des pointeurs et des fonctions void
IMAGE_SYM_TYPE_CHAR
2
Caractère (octet signé)
IMAGE_SYM_TYPE_SHORT
3
Entier signé sur 2 octets
IMAGE_SYM_TYPE_INT
4
Type entier naturel (normalement 4 octets dans Windows)
IMAGE_SYM_TYPE_LONG
5
Entier signé sur 4 octets
IMAGE_SYM_TYPE_FLOAT
6
Nombre à virgule flottante sur 4 octets
IMAGE_SYM_TYPE_DOUBLE
7
Nombre à virgule flottante sur 8 octets
IMAGE_SYM_TYPE_STRUCT
8
Une structure
IMAGE_SYM_TYPE_UNION
9
Un union
IMAGE_SYM_TYPE_ENUM
10
Un type énuméré
IMAGE_SYM_TYPE_MOE
11
Un membre de l’énumération (une valeur spécifique)
IMAGE_SYM_TYPE_BYTE
12
Un octet ; entier non signé sur 1 octet
IMAGE_SYM_TYPE_WORD
13
Un mot ; entier non signé sur 2 octets
IMAGE_SYM_TYPE_UINT
14
Entier non signé de taille naturelle (normalement, 4 octets)
IMAGE_SYM_TYPE_DWORD
15
Entier non signé sur 4 octets

 

L’octet le plus significatif précise si le symbole est un pointeur, une fonction qui retourne ou un tableau du type de base spécifié dans le LSB. Les outils Microsoft utilisent uniquement ce champ pour indiquer si le symbole est une fonction, afin que les deux seules valeurs résultantes soient 0x0 et 0x20 pour le champ Type. Toutefois, d’autres outils peuvent utiliser ce champ pour communiquer davantage d’informations.

Il est très important de spécifier correctement l’attribut de fonction. Ces informations sont nécessaires pour que la liaison incrémentielle fonctionne correctement. Pour certaines architectures, les informations peuvent être requises à d’autres fins.

Constant Valeur Description
IMAGE_SYM_DTYPE_NULL
0
Aucun type dérivé ; le symbole est une variable scalaire simple.
IMAGE_SYM_DTYPE_POINTER
1
Le symbole est un pointeur vers le type de base.
IMAGE_SYM_DTYPE_FUNCTION
2
Le symbole est une fonction qui retourne un type de base.
IMAGE_SYM_DTYPE_ARRAY
3
Le symbole est un tableau de type de base.

 

Classe de stockage

Le champ StorageClass de la table de symboles indique le type de définition qu’un symbole représente. Le tableau suivant présente les valeurs possibles. Notez que le champ StorageClass est un entier de 1 octet non signé. La valeur spéciale -1 doit donc être prise pour son équivalent non signé, 0xFF.

Bien que le format COFF traditionnel utilise de nombreuses valeurs de classe de stockage, les outils Microsoft s’appuient sur le format de débogage Visual C++ pour la plupart des informations symboliques et n’utilisent généralement que quatre valeurs de classe de stockage : EXTERNAL (2), STATIC (3), FUNCTION (101) et FILE (103). À l’exception de l’en-tête de la deuxième colonne ci-dessous, il faut entendre par « Valeur » le champ Valeur de l’enregistrement du symbole (dont l’interprétation dépend du numéro trouvé en tant que classe de stockage).

Constant Valeur Description/interprétation du champ Valeur
IMAGE_SYM_CLASS_END_OF_FUNCTION
-1 (0xFF)
Symbole spécial qui représente la fin de la fonction, à des fins de débogage.
IMAGE_SYM_CLASS_NULL
0
Aucune classe de stockage attribuée.
IMAGE_SYM_CLASS_AUTOMATIC
1
Variable automatique (pile). Le champ Valeur spécifie le décalage de la trame de pile.
IMAGE_SYM_CLASS_EXTERNAL
2
Valeur utilisée par les outils Microsoft pour les symboles externes. Le champ Valeur indique la taille si le numéro de section est IMAGE_SYM_UNDEFINED (0). Si le numéro de section n’est pas égal à zéro, le champ Valeur spécifie le décalage dans la section.
IMAGE_SYM_CLASS_STATIC
3
Décalage du symbole dans la section. Si le champ Valeur est égal à zéro, le symbole représente un nom de section.
IMAGE_SYM_CLASS_REGISTER
4
Variable de registre. Le champ Valeur spécifie le numéro de registre.
IMAGE_SYM_CLASS_EXTERNAL_DEF
5
Symbole défini en externe.
IMAGE_SYM_CLASS_LABEL
6
Étiquette de code définie dans le module. Le champ Valeur spécifie le décalage du symbole dans la section.
IMAGE_SYM_CLASS_UNDEFINED_LABEL
7
Référence à une étiquette de code qui n’est pas définie.
IMAGE_SYM_CLASS_MEMBER_OF_STRUCT
8
Membre de la structure. Le champ Valeur spécifie le nième membre.
IMAGE_SYM_CLASS_ARGUMENT
9
Argument formel (paramètre) d’une fonction. Le champ Valeur spécifie le nième argument.
IMAGE_SYM_CLASS_STRUCT_TAG
10
Entrée de nom d’étiquette de la structure.
IMAGE_SYM_CLASS_MEMBER_OF_UNION
11
Membre de l’union. Le champ Valeur spécifie le nième membre.
IMAGE_SYM_CLASS_UNION_TAG
12
Entrée de nom de l’étiquette de l’union.
IMAGE_SYM_CLASS_TYPE_DEFINITION
13
Entrée Typedef.
IMAGE_SYM_CLASS_UNDEFINED_STATIC
14
Déclaration de données statiques.
IMAGE_SYM_CLASS_ENUM_TAG
15
Entrée tagname de type énuméré.
IMAGE_SYM_CLASS_MEMBER_OF_ENUM
16
Membre d’une énumération. Le champ Valeur spécifie le nième membre.
IMAGE_SYM_CLASS_REGISTER_PARAM
17
Paramètre du registre.
IMAGE_SYM_CLASS_BIT_FIELD
18
Référence de champ de bits. Le champ Valeur spécifie le nième bit dans le champ de bit.
IMAGE_SYM_CLASS_BLOCK
100
Enregistrement .bb (début du bloc) ou .eb (fin de bloc). Le champ Valeur est l’adresse réadressable de l’emplacement du code.
IMAGE_SYM_CLASS_FUNCTION
101
Valeur utilisée par les outils Microsoft pour les enregistrements de symboles qui définissent l’étendue d’une fonction : fonction de début (.bf), fonction de fin (.ef) et lignes dans une fonction (.lf). Pour les enregistrements .lf, le champ Valeur fournit le nombre de lignes sources dans la fonction. Pour les enregistrements .ef, le champ Valeur fournit la taille du code de fonction.
IMAGE_SYM_CLASS_END_OF_STRUCT
102
Entrée de fin de structure.
IMAGE_SYM_CLASS_FILE
103
Valeur que les outils Microsoft, ainsi que le format COFF traditionnel, utilisent pour l’enregistrement du symbole du fichier source. Le symbole est suivi d’enregistrements auxiliaires qui nomment le fichier.
IMAGE_SYM_CLASS_SECTION
104
Définition d’une section (les outils Microsoft utilisent plutôt la classe de stockage STATIC).
IMAGE_SYM_CLASS_WEAK_EXTERNAL
105
Un externe faible. Pour en savoir plus, consultez Format auxiliaire 3 : externes faibles.
IMAGE_SYM_CLASS_CLR_TOKEN
107
Symbole de jeton CLR. Le nom est une chaîne ASCII qui se compose de la valeur hexadécimale du jeton. Pour en savoir plus, consultez Définition du jeton CLR (objet uniquement).

 

Enregistrements de symboles auxiliaires

Les enregistrements de table de symboles auxiliaires suivent toujours et s’appliquent à certains enregistrements de table de symboles standard. Un enregistrement auxiliaire peut avoir n’importe quel format que les outils peuvent reconnaître, mais 18 octets doivent leur être alloués afin que la table de symboles soit conservée sous la forme d’un tableau de taille normale. Actuellement, les outils Microsoft reconnaissent les formats auxiliaires pour les types d’enregistrements suivants : définitions de fonction, symboles de début et de fin de fonction (.bf et .ef), externes faibles, noms de fichiers et définitions de section.

La conception COFF traditionnelle inclut également des formats d’enregistrement auxiliaire pour les tableaux et les structures. Les outils Microsoft ne les utilisent pas, mais placent ces informations symboliques au format de débogage Visual C++ dans les sections de débogage.

Format auxiliaire 1 : définitions de fonction

Un enregistrement de table de symboles marque le début d’une définition de fonction s’il présente tous les éléments suivants : une classe de stockage EXTERNAL (2), une valeur de type indiquant qu’il s’agit d’une fonction (0x20) et un numéro de section supérieur à zéro. Il convient de noter qu’un enregistrement de table de symboles qui a un numéro de section UNDEFINED (0) ne définit pas la fonction et n’a pas d’enregistrement auxiliaire. Les enregistrements de symboles de définition de fonction sont suivis d’un enregistrement auxiliaire au format décrit ci-dessous :

Contrepartie Taille Champ Description
0
4
TagIndex
Index de table de symboles de l’enregistrement de symbole .bf (fonction de début) correspondant.
4
4
TotalSize
Taille du code exécutable pour la fonction elle-même. Si la fonction se trouve dans sa propre section, la valeur SizeOfRawData dans l’en-tête de section est supérieure ou égale à ce champ, en fonction des considérations d’alignement.
8
4
PointerToLinenumber
Décalage du fichier de la première entrée de numéro de ligne COFF pour la fonction, ou zéro s’il n’y en a pas. Pour en savoir plus, consultez Numéros de ligne COFF (obsolète).
12
4
PointerToNextFunction
Index de table de symboles de l’enregistrement pour la fonction suivante. Si la fonction est la dernière dans la table de symboles, ce champ est défini sur zéro.
16
2
Inutilisé

 

Format auxiliaire 2 : symboles .bf et .ef

Pour chaque définition de fonction dans la table de symboles, trois éléments décrivent le début, la fin et le nombre de lignes. Chacun de ces symboles possède la classe de stockage FUNCTION (101) :

Enregistrement de symbole nommé .bf (début de la fonction). Le champ Valeur n’est pas utilisé.

Enregistrement de symbole nommé .lf (lignes dans la fonction). Le champ Valeur fournit le nombre de lignes dans la fonction.

Enregistrement de symbole nommé .ef (fin de la fonction). Le champ Valeur a le même numéro que le champ Total Size dans l’enregistrement du symbole de définition de la fonction.

Les enregistrements de symboles .bf et .ef (mais pas les enregistrements .lf) sont suivis d’un enregistrement auxiliaire au format suivant :

Contrepartie Taille Champ Description
0
4
Inutilisé
4
2
Linenumber
Numéro de ligne ordinal réel (1, 2, 3, etc.) dans le fichier source, correspondant à l’enregistrement .bf ou .ef.
6
6
Inutilisé
12
4
PointerToNextFunction (.bf uniquement)
Index de table de symboles de l’enregistrement de symbole .bf suivant. Si la fonction est la dernière dans la table de symboles, ce champ est défini sur zéro. Il n’est pas utilisé pour les enregistrements .ef.
16
2
Inutilisé

 

Format auxiliaire 3 : externes faibles

Les « externes faibles » sont un mécanisme pour les fichiers objet qui permet une flexibilité au moment de la liaison. Un module peut contenir un symbole externe non résolu (sym1), mais aussi un enregistrement auxiliaire qui indique que si sym1 n’est pas présent au moment de la liaison, un autre symbole externe (sym2) est utilisé à la place pour résoudre les références.

Si une définition de sym1 est liée, une référence externe au symbole est résolue normalement. Si une définition de sym1 n’est pas liée, toutes les références à l’externe faible pour sym1 renvoient à sym2. Le symbole externe, sym2, doit toujours être lié. En général, il est défini dans le module qui contient la référence faible à sym1.

Les externes faibles sont représentés par un enregistrement de table de symboles avec la classe de stockage EXTERNAL, le numéro de section UNDEF et la valeur zéro. L’enregistrement de symboles faibles externes est suivi d’un enregistrement auxiliaire au format suivant :

Contrepartie Taille Champ Description
0
4
TagIndex
Index de la table de symboles de sym2, symbole à lier si sym1 est introuvable.
4
4
Caractéristiques
Une valeur IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY indique qu’aucune recherche de bibliothèque ne doit être effectuée pour le sym1.
Une valeur IMAGE_WEAK_EXTERN_SEARCH_LIBRARY indique qu’aucune recherche de bibliothèque ne doit être effectuée pour le sym1.
Une valeur IMAGE_WEAK_EXTERN_SEARCH_ALIAS indique que sym1 est un alias pour sym2.
8
10
Inutilisé

 

Il convient de noter que le champ Caractéristiques n’est pas défini dans WINNT.H. C’est le champ Total Size qui est utilisé.

Format auxiliaire 4 : fichiers

Ce format suit un enregistrement de table de symboles avec la classe de stockage FILE (103). Le nom de symbole lui-même doit être .file, et l’enregistrement auxiliaire qui le suit fournit le nom d’un fichier de code source.

Contrepartie Taille Champ Description
0
18
Nom de fichier
Chaîne ANSI qui indique le nom du fichier source. Celle-ci est complétée par des zéros si elle est inférieure à la longueur maximale.

 

Format auxiliaire 5 : définitions de section

Ce format suit un enregistrement de table de symboles qui définit une section. Le nom de symbole d’un tel enregistrement est celui d’une section (.text ou .drectve) et sa classe de stockage est STATIC (3). L’enregistrement auxiliaire fournit des informations sur la section à laquelle il fait référence. Par conséquent, il duplique certaines informations dans l’en-tête de section.

Contrepartie Taille Champ Description
0
4
Longueur
Taille des données de section. Identique à SizeOfRawData dans l’en-tête de section.
4
2
NumberOfRelocations
Le nombre d’entrées de réadressage pour la section.
6
2
NumberOfLinenumbers
Le nombre d’entrées de numéro de ligne pour la section.
8
4
CheckSum
Somme de contrôle des données communautaires. Elle s’applique si l’indicateur IMAGE_SCN_LNK_COMDAT est défini dans l’en-tête de section. Pour plus d’informations, consultez les sections COMDAT (uniquement objet).
12
2
Nombre
Index de base un dans le tableau de section pour la section associée. Il est utilisé lorsque le paramètre de sélection COMDAT est 5.
14
1
Sélection
Numéro de sélection COMDAT. Il s’applique si la section est une section COMDAT.
15
3
Inutilisé

 

Sections COMDAT (objet uniquement)

Le champ Sélection du format auxiliaire de définition de section s’applique s’il s’agit d’une section COMDAT. Une section COMDAT peut être définie par plusieurs fichiers objet. (L’indicateur IMAGE_SCN_LNK_COMDAT est défini dans le champ Indicateurs de section de l’en-tête de section). Le champ Sélection détermine la façon dont l’éditeur de liens résout les multiples définitions des sections COMDAT.

Le premier symbole qui affiche la valeur de section de la section COMDAT doit être le symbole de section. Ce symbole comporte le nom de la section, le champ Valeur égal à zéro, le numéro de la section COMDAT en question, le champ Type égal à IMAGE_SYM_TYPE_NULL, le champ Classe égal à IMAGE_SYM_CLASS_STATIC, et un enregistrement auxiliaire. Le deuxième symbole est appelé « Symbole COMDAT » et est utilisé par l’éditeur de liens conjointement avec le champ Sélection.

Les valeurs du champ Sélection sont indiquées ci-dessous.

Constant Valeur Description
IMAGE_COMDAT_SELECT_NODUPLICATES
1
Si ce symbole est déjà défini, l’éditeur de liens émet une erreur « symbole défini multiplié ».
IMAGE_COMDAT_SELECT_ANY
2
Toute section définissant le même symbole COMDAT peut être liée. Les autres sont supprimées.
IMAGE_COMDAT_SELECT_SAME_SIZE
3
L’éditeur de liens choisit une section aléatoire parmi les définitions de ce symbole. Si toutes les définitions ne sont pas de la même taille, une erreur « symbole défini multiplié » est émise.
IMAGE_COMDAT_SELECT_EXACT_MATCH
4
L’éditeur de liens choisit une section aléatoire parmi les définitions de ce symbole. Si toutes les définitions ne correspondent pas exactement, une erreur « symbole défini multiplié » est émise.
IMAGE_COMDAT_SELECT_ASSOCIATIVE
5
La section est liée si une autre section COMDAT l’est aussi. Cette autre section est indiquée dans le champ Numéro de l’enregistrement du symbole auxiliaire pour la définition de la section. Ce paramètre est utile pour les définitions qui comportent des éléments dans plusieurs sections (par exemple, du code dans une section et des données dans une autre), mais qui doivent être liées ou éliminées en tant qu’ensemble. L’autre section à laquelle cette section est associée doit être une section COMDAT, qui peut être une autre section COMDAT associative. Une chaîne d’association de sections de la section COMDAT associative ne peut pas former une boucle. La chaîne d’association de sections doit finalement aboutir à une section COMDAT pour laquelle IMAGE_COMDAT_SELECT_ASSOCIATIVE n’a pas été défini.
IMAGE_COMDAT_SELECT_LARGEST
6
L’éditeur de liens choisit la définition la plus étendue parmi toutes les définitions de ce symbole. Si plusieurs définitions ont cette taille, le choix entre eux est aléatoire.

 

Définition de jeton CLR (objet uniquement)

Ce symbole auxiliaire suit généralement IMAGE_SYM_CLASS_CLR_TOKEN. Il est utilisé pour associer un jeton à l’espace de noms de la table de symboles COFF.

Contrepartie Taille Champ Description
0
1
bAuxType
Doit être IMAGE_AUX_SY Mo OL_TYPE_TOKEN_DEF (1).
1
1
bReserved
Réservée, doit être zéro.
2
4
SymbolTableIndex
Index de symbole du symbole COFF auquel cette définition de jeton CLR fait référence.
6
12
Réservée, doit être zéro.

 

Table de chaînes COFF

Immédiatement après la table de symboles COFF vient la table de chaînes COFF. Pour déterminer la position de cette table, il faut prendre l’adresse de la table des symboles dans l’en-tête COFF et ajouter le nombre de symboles multiplié par la taille d’un symbole.

Les 4 octets qui se trouvent au début de la table de chaînes COFF contiennent la taille totale (en octets) du reste de la table de chaînes. Cette taille inclut le champ de taille lui-même, de sorte que la valeur de cet emplacement serait 4 s’il n’y avait pas de chaînes.

La taille est suivie de chaînes de caractères se terminant par une valeur nulle qui sont désignées par des symboles dans la table des symboles COFF.

Table de certificats d’attributs (image uniquement)

Les certificats d’attribut peuvent être associés à une image en ajoutant une table de certificats d’attribut. La table de certificats d’attribut est composée d’un ensemble d’entrées de certificat d’attribut contiguës, alignées sur quadword. Pour réaliser cet alignement, aucun remplissage n’est inséré entre la fin originale du fichier et le début de la table de certificats d’attribut. Chaque entrée de certificat d’attribut contient les champs suivants.

Contrepartie Taille Champ Description
0
 4
 dwLength
 Spécifie la longueur de l’entrée du certificat d’attribut.
4
 2
 wRevision
 Contient le numéro de version du certificat. Pour plus de détails, consultez le texte suivant.
6
 2
 wCertificateType
 Spécifie le type de contenu dans bCertificate. Pour plus de détails, consultez le texte suivant.
8
 Consultez
 bCertificate
 Contient un certificat, comme une signature Authenticode. Pour plus de détails, consultez le texte suivant.

 

La valeur de l’adresse virtuelle de l’entrée de la table de certificats dans le répertoire de données de l’en-tête facultatif est un décalage de fichier vers la première entrée de certificat d’attribut. Les entrées suivantes sont accessibles en avançant les octets dwLength de cette entrée, arrondis à un multiple de 8 octets, à partir du début de l’entrée de certificat d’attribut actuelle. Cette opération se poursuit jusqu’à ce que la somme des valeurs dwLength arrondies soit égale à la valeur Size de l’entrée de la table de certificats dans le répertoire de données de l’en-tête facultatif. Si la somme des valeurs dwLength arrondies n’est pas égale à la valeur Size, la table de certificats d’attribut ou le champ Size est endommagé.

Par exemple, si l’entrée de table de certificats du répertoire de données de l’en-tête facultatif contient :

virtual address = 0x5000
size = 0x1000

Le premier certificat commence au niveau du décalage 0x5000 à partir du début du fichier sur le disque. Pour parcourir toutes les entrées de certificats d’attributs :

  1. Ajoutez la valeur dwLength du premier certificat d’attribut au décalage de départ.
  2. Arrondissez la valeur de l’étape 1 jusqu’au multiple de 8 octets le plus proche pour trouver le décalage de la deuxième entrée du certificat d’attribut.
  3. Ajoutez la valeur de décalage de l’étape 2 à la valeur dwLength de la deuxième entrée du certificat d’attribut et arrondissez au multiple de 8 octets le plus proche pour déterminer le décalage de la troisième entrée du certificat d’attribut.
  4. Répétez l’étape 3 pour chaque certificat successif jusqu’à ce que le décalage calculé soit égal à 0x6000 (0x5000 début + 0x1000 taille totale), ce qui indique que vous avez parcouru la table entière.

Vous pouvez également énumérer les entrées de certificats en appelant la fonction Win32 ImageEnumerateCertificates dans une boucle. Pour obtenir un lien vers la page de référence de la fonction, consultez Références.

Les entrées de la table des certificats d’attributs peuvent contenir n’importe quel type de certificat, à condition que l’entrée possède la valeur dwLength correcte, une valeur wRevision unique et une valeur wCertificateType unique. Le type d’entrée de table de certificat le plus courant est une structure WIN_CERTIFICATE, documentée dans Wintrust.h et abordée dans le reste de cette section.

Les options du membre WIN_CERTIFICATE wRevision incluent (mais sans s’y limiter) les éléments suivants.

Valeur Nom Notes
0x0100
 WIN_CERT_REVISION_1_0
 Version 1, version héritée de la structure Win_Certificate. Elle est prise en charge uniquement à des fins de vérification des signatures Authenticode héritées
0x0200
 WIN_CERT_REVISION_2_0
 La version 2 est la version actuelle de la structure Win_Certificate.

 

Les options du membre WIN_CERTIFICATE wCertificateType incluent (mais sans s’y limiter) les éléments du tableau suivant. Il convient de noter que certaines valeurs ne sont pas prises en charge pour le moment.

Valeur Nom Notes
0x0001
 WIN_CERT_TYPE_X509
bCertificate contient un certificat X.509
Non pris en charge
0x0002
 WIN_CERT_TYPE_PKCS_SIGNED_DATA
 bCertificate contient une structure PKCS#7 SignedData
0x0003
 WIN_CERT_TYPE_RESERVED_1
 Réservé
0x0004
 WIN_CERT_TYPE_TS_STACK_SIGNED
 Signature du certificat de la pile du protocole du serveur de terminal
Non pris en charge

 

Le membre bCertificate de la structure WIN_CERTIFICATE contient un tableau d’octets de longueur variable avec le type de contenu spécifié par wCertificateType. Le type pris en charge par Authenticode est WIN_CERT_TYPE_PKCS_SIGNED_DATA, une structure PKCS#7 SignedData. Pour en savoir plus sur le format de signature numérique Authenticode, consultez Format de signature de l’exécutable portable Authenticode de Windows.

Si le contenu de bCertificate ne se termine pas sur une limite quadword, l’entrée du certificat d’attribut est complétée par des zéros, de la fin de bCertificate jusqu’à la limite quadword suivante.

La valeur dwLength est la longueur de la structure de WIN_CERTIFICATE finalisée et est calculée comme suit :

dwLength = offsetof(WIN_CERTIFICATE, bCertificate) + (size of the variable-length binary array contained within bCertificate)

Cette longueur doit inclure la taille de n’importe quel remplissage utilisé pour satisfaire à l’exigence selon laquelle chaque structure WIN_CERTIFICATE est alignée sur quadword :

dwLength += (8 - (dwLength & 7)) & 7;

La taille de la table de certificats spécifiée dans l’entrée Table des certificats dans les Répertoires de données de l’en-tête facultatif (image uniquement) inclut le remplissage.

Pour en savoir plus sur l’utilisation de l’API ImageHlp pour énumérer, ajouter et supprimer des certificats de fichiers PE, consultez Fonctions ImageHlp.

Données du certificat

Comme l’explique la section précédente, les certificats de la table des certificats d’attributs peuvent contenir n’importe quel type de certificat. Les certificats qui garantissent l’intégrité d’un fichier PE peuvent inclure un hachage d’image PE.

Un hachage d’image PE (ou hachage de fichier) est similaire à une somme de contrôle d’un fichier en ce sens que l’algorithme de hachage produit un condensé de message lié à l’intégrité d’un fichier. Cependant, une somme de contrôle est produite par un algorithme simple et est utilisée principalement pour détecter si un bloc de mémoire sur le disque a été endommagé et si les valeurs qui y sont stockées ont été corrompues. Un hachage de fichier est similaire à une somme de contrôle dans la mesure où il détecte également la corruption d’un fichier. Toutefois, contrairement à la plupart des algorithmes de somme de contrôle, il est très difficile de modifier un fichier sans changer son hachage par rapport à sa valeur initiale non modifiée. Un hachage de fichier peut donc être utilisé pour détecter des modifications intentionnelles et même subtiles d’un fichier, notamment celles introduites par des virus, des pirates informatiques ou des programmes de chevaux de Troie.

Lorsqu’il est inclus dans un certificat, le condensé d’image doit exclure certains champs de l’image PE, tels que la somme de contrôle et l’entrée de la table de certificats dans les répertoires de données de l’en-tête facultatif. En effet, l’ajout d’un certificat modifie ces champs et entraîne le calcul d’une valeur de hachage différente.

La fonction Win32 ImageGetDigestStream fournit un flux de données à partir d’un fichier PE cible avec lequel les fonctions de hachage sont utilisées. Ce flux de données reste cohérent lorsque des certificats sont ajoutés ou retirés d’un fichier PE. En fonction des paramètres transmis à ImageGetDigestStream, d’autres données de l’image PE peuvent être omises à partir du calcul du hachage. Pour obtenir un lien vers la page de référence de la fonction, consultez Références.

Tables d’importation de chargement différé (image uniquement)

Ces tables ont été ajoutées à l’image pour permettre aux applications de retarder le chargement d’une DLL jusqu’au premier appel dans cette DLL. La disposition des tables correspond à celle des tables d’importation traditionnelles décrites dans la section 6.4, La section .idata. Seuls quelques détails sont abordés ici.

Table de répertoire de chargement différé

La table de répertoire de chargement différé est l’équivalent de la table de répertoire d’importation. Elle peut être récupérée via l’entrée Descripteur d’importation différée dans la liste des répertoires de données de l’en-tête facultatif (décalage 200). La table est organisée comme suit :

Contrepartie Taille Champ Description
0
4
Attributs
Doit être zéro.
4
4
Nom
L’adresse virtuelle relative du nom de la DLL à charger. Le nom se trouve dans la section de données en lecture seule de l’image.
8
4
Descripteur de module
Adresse virtuelle relative du descripteur de module (dans la section données de l’image) de la DLL à charger plus tard. Il est utilisé pour le stockage par la routine qui est fournie pour gérer le chargement différé.
12
4
Table d’adresse d’importation différée
Adresse virtuelle relative de la table d’adresses d’importation de chargement différé. Pour en savoir plus, consultez Table d’adresses d’importation différée (IAT).
16
4
Table de noms d’importation différée
Adresse virtuelle relative de la table de noms de chargement différé, qui contient les noms des importations qui pourraient devoir être chargées. Cela correspond à la disposition de la table de noms d’importation. Pour en savoir plus, consultez Table indicateur/nom.
20
4
Table d’importation différée liée
Adresse virtuelle relative de la table d’adresses de chargement différé liée, le cas échéant.
24
4
Table d’importation du délai de déchargement
Adresse virtuelle relative de la table d’adresses de chargement et de délai du déchargement, si elle existe. Il s’agit d’une copie exacte de la table d’adresses d’importation différée. Si l’appelant décharge la DLL, cette table doit être recopiée sur la table des adresses d’importation différée afin que les appels ultérieurs à la DLL continuent d’utiliser correctement le mécanisme de conversion de code.
28
4
Horodatage
Horodatage de la DLL à laquelle cette image a été liée.

 

Les tables qui sont référencées dans cette structure de données sont organisées et triées de la même manière que leurs homologues le sont pour les importations traditionnelles. Pour en savoir plus, consultez la Section .idata.

Attributs

Pour l’instant, aucun indicateur d’attribut n’est défini. L’éditeur de liens définit ce champ sur zéro dans l’image. Ce champ peut être utilisé pour étendre l’enregistrement en indiquant la présence de nouveaux champs ou pour indiquer des comportements aux fonctions d’assistance de retard ou de déchargement.

Nom

Le nom de la DLL à charger en différé se trouve dans la section des données en lecture seule de l’image. Elle est référencée par le biais du champ szName.

Descripteur de module

Le descripteur de la DLL à charger en différé se trouve dans la section données de l’image. Le champ phmod pointe vers le descripteur. L’assistance au chargement différé fournie utilise cet emplacement pour stocker le descripteur dans la DLL chargée.

Table d’adresse d’importation différée

La table d’adresse d’importation différée (IAT) est référencée par le descripteur d’importation différé par le biais du champ pIAT. L’assistance de chargement différé met à jour ces pointeurs avec les points d’entrée réels, afin que les conversions de code ne se trouvent plus dans la boucle d’appel. L’accès aux pointeurs de fonction se fait à l’aide de l’expression pINT->u1.Function.

Table de noms d’importation différée

La table de noms d’importation différée (INT) contient les noms des importations qui peuvent nécessiter un chargement. Ils sont classés de la même manière que les pointeurs de fonction dans l’IAT. Ils se composent des mêmes structures que l’INT standard et sont accessibles à l’aide de l’expression pINT->u1.AddressOfData->Name[0].

Table et horodatage des adresses d’importation liées différées

La table des adresses d’importation liées différées (BIAT) est une table facultative des éléments IMAGE_THUNK_DATA qui est utilisée avec le champ d’horodatage de la table du répertoire de chargement différé par une phase de liaison post-processus.

Table d’adresses d’importation de déchargement différé

La table d’adresses d’importation de déchargement différé (UIAT) est une table facultative d’éléments IMAGE_THUNK_DATA utilisée par le code de déchargement pour gérer une demande de déchargement explicite. Elle se compose de données initialisées dans la section en lecture seule qui est une copie exacte de l’IAT d’origine qui a renvoyé le code aux conversions de code de chargement différé. Lors de la demande de déchargement, la bibliothèque peut être libérée, le *phmod effacé et l’UIAT écrite sur l’IAT pour tout restaurer dans l’état préalable au chargement.

Sections spéciales

Les sections COFF classiques contiennent du code ou des données que les éditeurs de liens et les chargeurs Microsoft Win32 traitent sans connaissance particulière du contenu de la section. Le contenu est pertinent uniquement pour l’application qui est liée ou exécutée.

Toutefois, certaines sections COFF ont une signification particulière lorsqu’elles se trouvent dans des fichiers objet ou image. Les outils et les chargeurs reconnaissent ces sections parce qu’elles contiennent des indicateurs spéciaux dans leur en-tête, parce que des emplacements spéciaux dans l’en-tête facultatif de l’image pointent vers elles, ou parce que le nom de la section lui-même indique une fonction spéciale de cette dernière. (Même si le nom de la section n’indique pas lui-même une fonction spéciale de cette dernière, il est déterminé par convention, de sorte que les auteurs de cette spécification peuvent se référer à un nom de section dans tous les cas).

Les sections réservées et leurs attributs sont décrits dans le tableau ci-dessous, suivi de descriptions détaillées pour les types de section qui sont conservés dans les exécutables et les types de section qui contiennent des métadonnées pour les extensions.

Nom de section Contenu Caractéristiques
.bss
Données non initialisées (format libre)
IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.cormeta
Métadonnées CLR qui indiquent que le fichier objet contient du code managé
IMAGE_SCN_LNK_INFO
.data
Données initialisées (format libre)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.debug$F
Informations de débogage FPO générées (objet uniquement, architecture x86 uniquement, et désormais obsolètes)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE
.debug$P
Types de débogage précompilés (objet uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE
.debug$S
Symboles de débogage (objet uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE
.debug$T
Types de débogage (objet uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE
.drective
Options de l’éditeur de liens
IMAGE_SCN_LNK_INFO
.edata
Tables d’exportation
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
.idata
Tables d’importation
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.idlsym
Inclut SEH inscrit (image uniquement) pour prendre en charge les attributs IDL. Pour en savoir plus, consultez « Attributs IDL » dans Références à la fin de cette rubrique.
IMAGE_SCN_LNK_INFO
.pdata
Informations sur l’exception
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
.rdata
Données initialisées en lecture seule
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
.reloc
Déplacement d’images
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE
.rsrc
Répertoire de ressources
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ
.sbss
Données non initialisées relatives à GP (format libre)
IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL L’indicateur IMAGE_SCN_GPREL doit être défini uniquement pour les architectures IA64 ; cet indicateur n’est pas valide pour d’autres architectures. L’indicateur IMAGE_SCN_GPREL concerne uniquement les fichiers objet. Lorsque ce type de section apparaît dans un fichier image, l’indicateur IMAGE_SCN_GPREL ne doit pas être défini.
.sdata
Données initialisées relatives à GP (format libre)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL L’indicateur IMAGE_SCN_GPREL doit être défini uniquement pour les architectures IA64 ; cet indicateur n’est pas valide pour d’autres architectures. L’indicateur IMAGE_SCN_GPREL concerne uniquement les fichiers objet. Lorsque ce type de section apparaît dans un fichier image, l’indicateur IMAGE_SCN_GPREL ne doit pas être défini.
.srdata
Données en lecture seule relatives à GP (format libre)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_GPREL IMAGE _SCN_GPREL L’indicateur IMAGE_SCN_GPREL doit être défini uniquement pour les architectures IA64 ; cet indicateur n’est pas valide pour d’autres architectures. L’indicateur IMAGE_SCN_GPREL concerne uniquement les fichiers objet. Lorsque ce type de section apparaît dans un fichier image, l’indicateur IMAGE_SCN_GPREL ne doit pas être défini.
.sxdata
Données de descripteur d’exceptions inscrites (format libre et x86/objet uniquement)
IMAGE_SCN_LNK_INFO Contient l’index de symboles de chacun des descripteurs d’exceptions référencés par le code de ce fichier objet. Il peut s’agir d’un symbole UNDEF ou d’un symbole défini dans ce module.
.text
Code exécutable (format libre)
IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IIMAGE_SCN_MEM_READ
.tls
Stockage local des threads (objet uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.tls$
Stockage local des threads (objet uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.vsdata
Données initialisées relatives à GP (format libre et pour les architectures ARM, SH4 et Thumb uniquement)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE
.xdata
Informations sur les exceptions (format libre)
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

 

Certaines sections répertoriées ici portent la mention « objet uniquement » ou « image uniquement » pour indiquer que leur sémantique spéciale est pertinente uniquement pour les fichiers objet ou les fichiers image, respectivement. Une section portant la mention « image uniquement » peut toujours apparaître dans un fichier objet comme moyen d’accéder au fichier image, mais la section n’a pas de signification particulière pour l’éditeur de liens, seulement pour le chargeur de fichiers image.

La section .debug

La section .debug est utilisée dans les fichiers objets pour contenir les informations de débogage générées par le compilateur et dans les fichiers images pour contenir toutes les informations de débogage générées. Cette section décrit l’empaquetage des informations de débogage dans les fichiers objet et image.

La section suivante décrit le format du répertoire de débogage, qui peut se trouver n’importe où dans l’image. Les sections suivantes décrivent les « groupes » dans les fichiers objet qui contiennent des informations de débogage.

Par défaut, les informations de débogage de l’éditeur de liens ne sont pas mappées dans l’espace d’adressage de l’image. Une section .debug existe uniquement lorsque les informations de débogage sont mappées dans l’espace d’adressage.

Répertoire de débogage (image uniquement)

Les fichiers image contiennent un répertoire de débogage facultatif qui indique sous quelle forme se présente les informations de débogage et où elles se trouvent. Ce répertoire se compose d’un tableau d’entrées de répertoire de débogage dont l’emplacement et la taille sont indiqués dans l’en-tête facultatif de l’image.

Le répertoire de débogage peut se trouver dans une section .debug éliminable (s’il en existe une), être inclus dans n’importe quelle autre section du fichier image ou ne pas se trouver du tout dans une section.

Chaque entrée de répertoire de débogage identifie l’emplacement et la taille d’un bloc d’informations de débogage. L’adresse virtuelle relative spécifiée peut être nulle si les informations de débogage ne sont pas couvertes par un en-tête de section (c’est-à-dire qu’elles résident dans le fichier image et ne sont pas mappées dans l’espace d’adressage d’exécution). Si elle est mappée, l’adresse virtuelle relative est son adresse.

Une entrée de répertoire de débogage a le format suivant :

Contrepartie Taille Champ Description
0
4
Caractéristiques
Réservée, doit être zéro.
4
4
TimeDateStamp
La date et l’heure de création des données de débogage.
8
2
MajorVersion
Le numéro de version principale du format des données de débogage.
10
2
MinorVersion
Le numéro de version mineure du format des données de débogage.
12
4
Tapez .
 Le format des informations de débogage. Ce champ permet la prise en charge de plusieurs débogueurs. Pour en savoir plus, consultez Type de débogage.
16
4
SizeOfData
La taille des données de débogage (répertoire de débogage exclu).
20
4
AddressOfRawData
L’adresse des données de débogage quand elles sont chargées, par rapport à la base de l’image.
24
4
PointerToRawData
Le pointeur de fichier vers les données de débogage.

 

Type de débogage

Les valeurs suivantes sont définies pour le champ Type de l’entrée de répertoire de débogage :

Constant Valeur Description
IMAGE_DEBUG_TYPE_UNKNOWN
0
Valeur inconnue qui est ignorée par tous les outils.
IMAGE_DEBUG_TYPE_COFF
1
Informations de débogage COFF (numéros de ligne, table de symboles et table de chaînes). Ce type d’informations de débogage est également désigné par des champs dans les en-têtes de fichiers.
IMAGE_DEBUG_TYPE_CODEVIEW
2
Informations de débogage Visual C++.
IMAGE_DEBUG_TYPE_FPO
3
Informations sur l’omission du pointeur de frame (FPO). Ces informations indiquent au débogueur comment interpréter les frames de pile non standard, qui utilisent le registre EBP dans un but autre que celui d’un pointeur de frame.
IMAGE_DEBUG_TYPE_MISC
4
Emplacement du fichier DBG.
IMAGE_DEBUG_TYPE_EXCEPTION
5
Copie de la section .pdata.
IMAGE_DEBUG_TYPE_FIXUP
6
Réservé.
IMAGE_DEBUG_TYPE_OMAP_TO_SRC
7
Mappage d’une adresse virtuelle relative dans l’image à une adresse virtuelle relative dans l’image source.
IMAGE_DEBUG_TYPE_OMAP_FROM_SRC
8
Mappage d’une adresse virtuelle relative dans l’image source à une adresse virtuelle relative dans l’image.
IMAGE_DEBUG_TYPE_BORLAND
9
Réservée à Borland.
IMAGE_DEBUG_TYPE_RESERVED10
10
Réservé.
IMAGE_DEBUG_TYPE_CLSID
11
Réservé.
IMAGE_DEBUG_TYPE_REPRO
16
Déterminisme ou reproductibilité d’un fichier PE.
Undefined
 17
Les informations de débogage sont incorporées dans le fichier PE à l’emplacement spécifié par PointerToRawData.
Undefined
 19
Stocke le hachage de chiffrement pour le contenu du fichier de symboles utilisé pour générer le fichier PE/COFF.
IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS 20 Bits de caractéristiques DLL étendues.

 

Si le champ Type est défini sur IMAGE_DEBUG_TYPE_FPO, les données brutes de débogage sont un tableau dans lequel chaque membre décrit la frame de pile d’une fonction. Toutes les fonctions du fichier image ne doivent pas contenir d’informations FPO définies pour elles, même si le type de débogage est FPO. Ces fonctions qui ne contiennent pas d’informations FPO sont supposées avoir des frames de pile normales. Le format des informations FPO est le suivant :

#define FRAME_FPO   0
#define FRAME_TRAP  1
#define FRAME_TSS   2

typedef struct _FPO_DATA {
    DWORD       ulOffStart;            // offset 1st byte of function code
    DWORD       cbProcSize;            // # bytes in function
    DWORD       cdwLocals;             // # bytes in locals/4
    WORD        cdwParams;             // # bytes in params/4
    WORD        cbProlog : 8;          // # bytes in prolog
    WORD        cbRegs   : 3;          // # regs saved
    WORD        fHasSEH  : 1;          // TRUE if SEH in func
    WORD        fUseBP   : 1;          // TRUE if EBP has been allocated
    WORD        reserved : 1;          // reserved for future use
    WORD        cbFrame  : 2;          // frame type
} FPO_DATA;

La présence d’une entrée de type IMAGE_DEBUG_TYPE_REPRO indique que le fichier PE est créé de manière à obtenir le déterminisme ou la reproductibilité. Si l’entrée ne change pas, le fichier PE de sortie est garanti identique bit à bit, quel que soit le moment ou l’endroit où il est produit. Différents champs d’horodatage du fichier PE sont complétés avec une partie ou la totalité des bits d’une valeur de hachage calculée qui utilise le contenu du fichier PE comme entrée. Ils ne représentent donc plus la date et l’heure réelles de la production d’un fichier PE ou de données spécifiques connexes dans le PE. Les données brutes de cette entrée de débogage peuvent être vides ou contenir une valeur de hachage calculée précédée d’une valeur de quatre octets représentant la longueur de la valeur de hachage.

Si le champ Type est défini sur IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS, les données brutes de débogage contiennent des bits de caractéristiques DLL étendues, en plus de ceux qui peuvent être définis dans l’en-tête facultatif de l’image. Consultez Caractéristiques de la DLL dans la section En-têtes facultatifs des champs spécifiques à Windows (image uniquement) .

Caractéristiques d’une DLL étendues

Les valeurs suivantes sont définies pour les bits des caractéristiques DLL étendues.

Constant Valeur Description
IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT 0x0001 L’image est compatible avec la technologie de mise en œuvre de flux de contrôle (CET).
IMAGE_DLLCHARACTERISTICS_EX_FORWARD_CFI_COMPAT 0x0040 Toutes les cibles de branches dans toutes les sections du code image sont annotées avec des instructions de protection de l’intégrité du flux de contrôle de périphérie, notamment les instructions x86 CET-Indirect Branch Tracking (IBT) ou ARM Branch Target Identification (BTI). Ce bit n’est pas utilisé par Windows.

.debug$F (objet uniquement)

Les données de cette section ont été remplacées dans les versions 7.0 et ultérieures de Visual C++ par un ensemble plus complet de données émises dans une sous-section .debug$S.

Les fichiers objet peuvent contenir des sections .debug$F dont le contenu est un ou plusieurs enregistrements FPO_DATA (informations sur l’omission du pointeur de frame). Consultez « IMAGE_DEBUG_TYPE_FPO » dans Type de débogage.

L’éditeur de liens reconnaît ces enregistrements .debug$F. Si des informations de débogage sont générées, l’éditeur de liens trie les enregistrements FPO_DATA par une procédure d’adresse virtuelle relative et génère une entrée de répertoire de débogage pour eux.

Le compilateur ne doit pas générer d’enregistrements FPO pour les procédures qui ont un format de frame standard.

.debug$S (objet uniquement)

Cette section présente des informations de débogage de Visual C++ (informations symboliques).

.debug$P (objet uniquement)

Cette section présente des informations de débogage de Visual C++ (informations précompilées). Il s’agit de types partagés entre tous les objets compilés à l’aide de l’en-tête précompilé généré avec cet objet.

.debug$T (objet uniquement)

Cette section présente des informations de débogage de Visual C++ (informations de type).

Prise en charge par l’éditeur de liens des informations de débogage de Microsoft

Pour prendre en charge les informations de débogage, l’éditeur de liens :

  • Collecte toutes les données de débogage pertinentes à partir des sections .debug$F, debug$S, .debug$P et .debug$T.

  • Traite ces données ainsi que les informations de débogage générées par l’éditeur de liens dans le fichier PDB et crée une entrée dans le répertoire de débogage pour s’y référer.

La section .drectve (objet uniquement)

Une section est une section directive si l’indicateur IMAGE_SCN_LNK_INFO est défini dans l’en-tête de section et porte le nom de la section .drectve. L’éditeur de liens supprime une section .drectve après avoir traité les informations. Ainsi, la section n’apparaît pas dans le fichier image lié.

Une section .drectve se compose d’une chaîne de texte qui peut être encodée en ANSI ou UTF-8. Si le marqueur d’ordre d’octet UTF-8 (BOM, préfixe à trois octets constitué de 0xEF, 0xBB et 0xBF) n’est pas présent, la chaîne de directive est interprétée comme ANSI. La chaîne de directive est une série d’options d’éditeur de liens séparées par des espaces. Chaque option contient un trait d’union, le nom de l’option et tout attribut approprié. Si une option contient des espaces, elle doit être placée entre guillemets. La section .drectve ne doit pas comporter de numéros de ligne ou de réadressages.

La section .edata (image uniquement)

La section exporter des données, nommée .edata, contient des informations sur les symboles auxquels d’autres images peuvent accéder grâce à la liaison dynamique. Les symboles exportés se trouvent généralement dans les DLL, mais ces dernières peuvent également importer des symboles.

Une vue d’ensemble de la structure générale de la section d’exportation est décrite ci-dessous. Les tables décrites sont généralement contiguës dans le fichier dans l’ordre indiqué (bien que cela ne soit pas obligatoire). Seule la table des répertoires d’exportation et la table des adresses d’exportation sont requises pour exporter des symboles en tant qu’ordinaux. (Un ordinal est une exportation à laquelle on accède directement par l’index de sa table d’adresses d’exportation). La table des pointeurs de noms, la table des ordinaux et la table des noms d’exportation existent toutes pour prendre en charge l’utilisation des noms d’exportation.

Nom de table Description
Table des répertoires d’exportation
Table avec une seule ligne (contrairement au répertoire de débogage). Cette table indique les emplacements et les tailles des autres tables d’exportation.
Table des adresses d’exportation
Tableau des adresses virtuelles relatives de symboles exportés. Il s’agit des adresses réelles des fonctions et des données exportées dans le code exécutable et les sections de données. D’autres fichiers image peuvent importer un symbole à l’aide d’un index de cette table (un ordinal) ou, éventuellement, en utilisant le nom public qui correspond à l’ordinal si un nom public est défini.
Table de pointeurs de noms
Tableau de pointeurs vers les noms d’exportation publics, triés par ordre croissant.
Table des ordinaux
Tableau des ordinaux qui correspondent aux membres de la table des pointeurs de noms. La correspondance se fait par position. Par conséquent, la table des pointeurs de noms et la table des ordinaux doivent avoir le même nombre de membres. Chaque ordinal est un index dans la table d’adresses d’exportation.
Table des noms d’exportation
Série de chaînes ASCII terminées par une valeur nulle. Les membres de la table des pointeurs de noms pointent dans cette zone. Ces noms sont les noms publics par lesquels les symboles sont importés et exportés. Ils ne sont pas nécessairement les mêmes que les noms privés utilisés dans le fichier image.

 

Quand un autre fichier image importe un symbole par nom, le chargeur Win32 recherche dans la table des pointeurs de noms une chaîne correspondante. S’il la trouve, l’ordinal associé est identifié en recherchant le membre correspondant dans la table des ordinaux (autrement dit, le membre de la table des ordinaux ayant le même index que le pointeur de chaîne trouvé dans la table des pointeurs de noms). L’ordinal obtenu est un index dans la table d’adresses d’exportation, qui indique l’emplacement réel du symbole souhaité. Chaque symbole d’exportation est accessible par un ordinal.

Lorsqu’un autre fichier image importe un symbole par ordinal, il est inutile de rechercher une chaîne correspondante dans la table des pointeurs de noms. L’utilisation directe d’un ordinal est donc plus efficace. Toutefois, un nom d’exportation est plus facile à retenir et ne nécessite pas que l’utilisateur connaisse l’index de la table pour le symbole.

Table des répertoires d’exportation

Les informations sur les symboles d’exportation commencent par le tableau des répertoires d’exportation, qui décrit le reste des informations sur les symboles d’exportation. La table des répertoires d’exportation contient des informations d’adresse utilisées pour résoudre les importations vers les points d’entrée de cette image.

Contrepartie Taille Champ Description
0
4
Indicateur d’exportation
Réservée, doit être 0.
4
4
Date/horodatage
La date et l’heure de création des données d’exportation.
8
2
Version principale
Numéro de version principale. Les numéros de version principale et mineure peuvent être définis par l’utilisateur.
10
2
Version mineure
Numéro de version secondaire.
12
4
Adresse virtuelle relative du nom
Adresse de la chaîne ASCII qui contient le nom de la DLL. Cette adresse est relative à la base d’image.
16
4
Base de l’ordinal
Numéro ordinal de départ pour les exportations dans cette image. Ce champ spécifie le numéro ordinal de départ de la table d’adresses d’exportation. Il est généralement défini sur 1.
20
4
Entrées de la table d’adresses
Nombre d’entrées dans la table d’adresses d’exportation.
24
4
Nombre de pointeurs de noms
Nombre d’entrées dans la table des pointeurs de noms. Il s’agit également du nombre d’entrées dans la table des ordinaux.
28
4
Adresse virtuelle relative de la table des adresses d’exportation
Adresse de la table des adresses d’exportation, par rapport à la base d’image.
32
4
Adresse virtuelle relative du pointeur de nom
Adresse de la table des pointeurs de noms d’exportation, par rapport à la base d’image. La taille de la table est indiquée par le champ Nombre des pointeurs de noms.
36
4
Adresse virtuelle relative de la table des ordinaux
Adresse de la table des ordinaux, par rapport à la base d’image.

 

Table des adresses d’exportation

La table des adresses d’exportation contient l’adresse des points d’entrée exportés et des données et des absolus exportés. Un nombre ordinal est utilisé comme index dans la table des adresses d’exportation.

Chaque entrée de la table des adresses d’exportation est un champ qui utilise l’un des deux formats de la table suivante. Si l’adresse spécifiée ne se trouve pas dans la section d’exportation (telle que définie par l’adresse et la longueur indiquées dans l’en-tête facultatif), le champ est une adresse virtuelle relative d’exportation, c’est-à-dire une adresse réelle dans le code ou les données. Sinon, le champ est une adresse virtuelle relative de redirecteur, qui nomme un symbole dans une autre DLL.

Contrepartie Taille Champ Description
0
4
Exporter au format RVA
 Adresse du symbole exporté lorsqu’il est chargé en mémoire, par rapport à la base d’image. Par exemple, l’adresse d’une fonction exportée.
0
4
Adresse virtuelle relative du redirecteur
Pointeur vers une chaîne ASCII terminée par une valeur nulle dans la section d’exportation. Cette chaîne doit se trouver dans la plage fournie par l’entrée de répertoire de données de la table d’exportation. Consultez En-têtes facultatifs des répertoires de données (image uniquement). Cette chaîne indique le nom de la DLL et le nom de l’exportation (par exemple, « MYDLL.expfunc ») ou le nom de la DLL et le numéro ordinal de l’exportation (par exemple, « MYDLL.#27 »).

 

Une adresse virtuelle relative de redirecteur exporte une définition à partir d’une autre image, en donnant l’impression qu’elle est exportée par l’image actuelle. Ainsi, le symbole est importé et exporté simultanément.

Par exemple, dans Kernel32.dll sous Windows XP, l’exportation nommée « HeapAlloc » est transférée à la chaîne « NTDLL.RtlAllocateHeap ». Cela permet aux applications d’utiliser le module Ntdll.dll spécifique à Windows XP sans contenir de références d’importation vers ce dernier. La table d’importation de l’application fait uniquement référence à Kernel32.dll. Par conséquent, l’application n’est pas spécifique à Windows XP et peut s’exécuter sur n’importe quel système Win32.

Table des pointeurs de noms d’exportation

La table des pointeurs de noms d’exportation est un tableau d’adresses (adresses virtuelles relatives) dans la table de noms d’exportation. Les pointeurs sont composés de 32 bits chacun et sont relatifs à la base d’image. Les pointeurs sont ordonnés lexicalement pour permettre des recherches binaires.

Un nom d’exportation est défini uniquement si la table des pointeurs de noms d’exportation contient un pointeur vers celui-ci.

Table des ordinaux d’exportation

La table des ordinaux d’exportation est un tableau d’index 16 bits non biaisés dans la table des adresses d’exportation. Les ordinaux sont biaisés par le champ Base de l’ordinal de la table des répertoires d’exportation. En d’autres termes, la base de l’ordinal doit être soustraite des ordinaux pour obtenir de véritables index dans la table des adresses d’exportation.

La table des pointeurs de noms d’exportation et la table des ordinaux d’exportation constituent deux tableaux parallèles séparés pour permettre un alignement naturel des champs. Ces deux tables fonctionnent en fait comme une seule, dans laquelle la colonne Pointeur des noms d’exportation pointe vers un nom public (exporté) et la colonne Ordinaux d’exportation indique l’ordinal correspondant à ce nom public. Un membre de la table des pointeurs de noms d’exportation et un membre de la table des ordinaux d’exportation sont associés en ayant la même position (index) dans leurs tableaux respectifs.

Ainsi, lorsque la table des pointeurs de noms d’exportation est consultée et qu’une chaîne de caractères correspondante est trouvée à la position i, l’algorithme permettant de trouver l’adresse virtuelle relative et de l’ordinal biaisé du symbole est le suivant :

i = Search_ExportNamePointerTable (name);
ordinal = ExportOrdinalTable [i];

rva = ExportAddressTable [ordinal];
biased_ordinal = ordinal + OrdinalBase;

Lors de la recherche d’un symbole par ordinal (biaisé), l’algorithme de recherche de l’adresse virtuelle relative et du nom du symbole est :

ordinal = biased_ordinal - OrdinalBase;
i = Search_ExportOrdinalTable (ordinal);

rva = ExportAddressTable [ordinal];
name = ExportNameTable [i];

Table des noms d’exportation

La table des noms d’exportation contient les données de la chaîne qui ont été pointées par la table des pointeurs de noms d’exportation. Les chaînes de ce tableau sont des noms publics que d’autres images peuvent utiliser pour importer les symboles. Ces noms d’exportation publics ne sont pas nécessairement les mêmes que les noms de symboles privés que les symboles ont dans leur propre fichier image et code source, même si cela peut être le cas.

Chaque symbole exporté possède une valeur ordinale, qui n’est autre que l’index de la table des adresses d’exportation. Toutefois, l’utilisation de noms d’exportation est facultative. Certains, tous ou aucun des symboles exportés peuvent avoir de noms d’exportation. Pour ceux qui en ont, les entrées correspondantes de la table des pointeurs des noms d’exportation et de la table des ordinaux d’exportation fonctionnent ensemble pour associer chaque nom à un ordinal.

La structure de la table des noms d’exportation est une série de chaînes ASCII terminées par une valeur nulle de longueur variable.

La section .idata

Tous les fichiers images qui importent des symboles, y compris la quasi-totalité des fichiers exécutables (EXE), comportent une section .idata. Voici une disposition de fichiers type pour les informations relatives à l’importation :

  • Table des répertoires

    Entrée de répertoire Null

  • Table de recherche d’importations DLL1

    Null

  • Table de recherche d’importations DLL2

    Null

  • Table de recherche d’importations DLL3

    Null

  • Table indicateur/nom

Table des répertoires d’importation

Les informations sur l’importation commencent par la table des répertoires d’importation, qui décrit le reste des informations sur l’importation. La table des répertoires d’importation contient des informations sur les adresses qui sont utilisées pour résoudre les références de correction aux points d’entrée d’une image DLL. La table des répertoires d’importation se compose d’un tableau d’entrées de répertoires d’importation, une entrée pour chaque DLL à laquelle l’image fait référence. La dernière entrée de répertoire est vide (remplie avec des valeurs nulles), ce qui indique la fin de la table des répertoires.

Chaque entrée de répertoire d’importation a le format suivant :

Contrepartie Taille Champ Description
0
4
Adresse virtuelle relative de la table de recherche d’importation (caractéristiques)
Adresse virtuelle relative de la table de recherche d’importation (caractéristiques). Cette table contient un nom ou un ordinal pour chaque importation. (Le nom « Caractéristiques » est utilisé dans Winnt.h, mais ne décrit plus ce champ).
4
4
Date/horodatage
Horodatage défini sur zéro jusqu’à ce que l’image soit liée. Une fois l’image liée, ce champ est défini sur l’horodatage de la DLL.
8
4
Chaîne du redirecteur
Index de la première référence du redirecteur.
12
4
Adresse virtuelle relative du nom
Adresse d’une chaîne ASCII qui contient le nom de la DLL. Cette adresse est relative à la base d’image.
16
4
Adresse virtuelle relative de la table des adresses d’importation (table de thunk)
Adresse virtuelle relative de la table des adresses d’importation. Le contenu de cette table est identique à celui de la table de recherche d’importations jusqu’à ce que l’image soit liée.

 

Table de recherche d’importations

Une table de recherche d’importation est un tableau de nombres de 32 bits pour PE32 ou un tableau de nombres de 64 bits pour PE32+. Chaque entrée utilise le format de champ de bits décrit dans le tableau suivant. Dans ce format, le bit 31 est le bit le plus significatif pour PE32 et le bit 63 est le bit le plus significatif pour PE32+. L’ensemble de ces entrées décrit toutes les importations d’une DLL donnée. La dernière entrée est définie sur zéro (NULL) pour indiquer la fin de la table.

Bit(s) Taille Champ de bits Description
31/63
1
Indicateur Ordinal/Nom
Si ce bit est défini, importez par ordinal. Sinon, importez par nom. Le bit est masqué comme 0x80000000 pour PE32 et 0x8000000000000000 pour PE32+.
15-0
16
Nombre ordinal
Nombre ordinal 16 bits. Ce champ est utilisé uniquement si le champ d’indicateur nom/ordinal est 1 (importer par ordinal). Les bits 30-15 ou 62-15 doivent être 0.
30-0
31
Adresse virtuelle relative de la table indicateur/nom
Adresse virtuelle relative 31 bits d’une entrée de table indicateur/nom. Ce champ est utilisé uniquement si le champ d’indicateur nom/ordinal est 0 (importer par nom). Pour PE32+, les bits 62-31 doivent être zéro.

 

Table indicateur/nom

Une table indicateur/nom suffit pour la section d’importation entière. Chaque entrée dans la table indicateur/nom a le format suivant :

Contrepartie Taille Champ Description
0
2
Indicateur
Index dans la table des pointeurs des noms d’exportation. Une correspondance est tentée en premier lieu avec cette valeur. En cas d’échec, une recherche binaire est effectuée sur la table des pointeurs des noms d’exportation de la DLL.
2
variable
Nom
Chaîne ASCII qui contient le nom à importer. Il s’agit de la chaîne qui doit correspondre au nom public dans la DLL. Cette chaîne est sensible à la casse et se termine par un octet nul.
*
0 ou 1
 Remplir
Octet de fin avec ajout de zéro qui apparaît après l’octet null de fin, le cas échéant, pour aligner l’entrée suivante sur une limite uniforme.

 

Table des adresses d’importation

La structure et le contenu de la table des adresses d’importation sont identiques à ceux de la table de recherche d’importation, jusqu’à ce que le fichier soit lié. Pendant la liaison, les entrées de la table des adresses d’importation sont remplacées par les adresses 32 bits (pour PE32) ou 64 bits (pour PE32+) des symboles importés. Ces adresses sont les adresses mémoire réelles des symboles, bien que techniquement elles soient toujours appelées « adresses virtuelles ». Le chargeur traite généralement la liaison.

La section .pdata

La section .pdata contient un tableau d’entrées de table de fonction utilisées pour la gestion des exceptions. Il est pointé par l’entrée de la table des exceptions dans le répertoire des données d’image. Les entrées doivent être triées en fonction des adresses de fonction (le premier champ de chaque structure) avant d’être émises dans l’image finale. La plateforme cible détermine laquelle des trois variantes de format d’entrée de la table de fonctions décrites ci-dessous est utilisée.

Pour les images MIPS 32 bits, les entrées de table de fonction ont le format suivant :

Contrepartie Taille Champ Description
0
4
Adresse de début
Adresse virtuelle de la fonction correspondante.
4
4
Adresse de fin
Adresse virtuelle de fin de la fonction.
8
4
Gestionnaire d’exceptions
Pointeur vers le gestionnaire d’exceptions à exécuter.
12
4
Données du gestionnaire
Pointeur vers des informations supplémentaires à transmettre au gestionnaire.
16
4
Adresse de fin du prologue
L’adresse virtuelle de la fin du prologue de la fonction.

 

Pour les plateformes ARM, PowerPC, SH3 et SH4 Windows CE, les entrées de table de fonction ont le format suivant :

Contrepartie Taille Champ Description
0
4
Adresse de début
Adresse virtuelle de la fonction correspondante.
4
8 bits
 Longueur du prologue
Nombre d’instructions dans le prologue de la fonction.
4
22 bits
 Longueur de la fonction
Nombre d’instructions dans la fonction.
4
1 bits
 Indicateur 32 bits
S’il est défini, la fonction se compose d’instructions 32 bits. S’il est vide, la fonction se compose d’instructions 16 bits.
4
1 bits
 Indicateur d’exception
S’il est défini, un gestionnaire d’exceptions existe pour la fonction. Sinon, il n’existe aucun gestionnaire d’exceptions.

 

Pour les plateformes x64 et Itanium, les entrées de table de fonctions ont le format suivant :

Contrepartie Taille Champ Description
0
4
Adresse de début
Adresse virtuelle relative de la fonction correspondante.
4
4
Adresse de fin
Adresse virtuelle relative de fin de la fonction.
8
4
Informations de déroulement
Adresse virtuelle relative des informations de déroulement.

 

La section .reloc (image uniquement)

La table de réadressage de base contient des entrées pour tous les réadressages de base dans l’image. Le champ Table de réadressage de base dans les répertoires de données d’en-tête facultatifs indique le nombre d’octets dans la table de réadressage de base. Pour en savoir plus, consultez Répertoires de données d’en-tête facultatifs (image uniquement). La table de réadressage de base est divisée en blocs. Chaque bloc représente les réadressages de base pour une page 4K. Chaque bloc doit commencer sur une limite 32 bits.

Le chargeur n’est pas nécessaire pour traiter les réadressages de base résolus par l’éditeur de liens, sauf si l’image de chargement ne peut pas être chargée à la base d’image spécifiée dans l’en-tête PE.

Bloc de réadressage de base

Chaque bloc de réadressage de base commence par la structure suivante :

Contrepartie Taille Champ Description
0
4
Adresse virtuelle relative de page
La base d’image plus l’adresse virtuelle relative de la page sont ajoutées à chaque décalage pour créer l’adresse virtuelle où le réadressage de base doit être appliqué.
4
4
Taille de bloc
Nombre total d’octets dans le bloc de réadressage de base, y compris les champs de l’adresse virtuelle relative de la page et la taille de bloc et les champs Type/Décalage qui suivent.

 

Le champ Taille de bloc est suivi d’un nombre quelconque d’entrées de champ Type ou Décalage. Chaque entrée est un MOT (2 octets) et présente la structure suivante :

Contrepartie Taille Champ Description
0
4 bits
 Tapez .
 Stockée dans les 4 bits de poids fort du MOT, valeur qui indique le type de réadressage de base à appliquer. Pour en savoir plus, consultez Types de réadressage de base.
0
12 bits
 Décalage
Stocké dans les 12 bits restants du MOT, un décalage par rapport à l’adresse de départ spécifiée dans le champ Adresse virtuelle relative de la page pour le bloc. Ce décalage spécifie l’endroit où le réadressage de base doit être appliqué.

 

Pour appliquer un réadressage de base, la différence est calculée entre l’adresse de base préférée et la base où l’image est effectivement chargée. Si l’image est chargée à sa base préférée, la différence est nulle et il n’est donc pas nécessaire d’appliquer les réadressages de base.

Types de réadressages de base

Constant Valeur Description
IMAGE_REL_BASED_ABSOLUTE
0
Le réadressage de base est ignoré. Ce type peut être utilisé pour remplir un bloc.
IMAGE_REL_BASED_HIGH
1
Le réadressage de base ajoute les 16 bits de poids fort de la différence au champ 16 bits au niveau du décalage. Le champ 16 bits représente la valeur élevée d’un mot 32 bits.
IMAGE_REL_BASED_LOW
2
Le réadressage de base ajoute les 16 bits de poids faible de la différence au champ 16 bits au niveau du décalage. Le champ 16 bits représente la moitié inférieure d’un mot 32 bits.
IMAGE_REL_BASED_HIGHLOW
3
Le réadressage de base applique les 32 bits de la différence au champ 32 bits au niveau du décalage.
IMAGE_REL_BASED_HIGHADJ
4
Le réadressage de base ajoute les 16 bits de poids fort de la différence au champ 16 bits au niveau du décalage. Le champ 16 bits représente la valeur élevée d’un mot 32 bits. Les 16 bits de poids faible de la valeur 32 bits sont stockés dans le mot 16 bits qui suit ce réadressage de base. Cela signifie que ce réadressage de base occupe deux emplacements.
IMAGE_REL_BASED_MIPS_JMPADDR
5
L’interprétation du réadressage dépend du type d’ordinateur.
Lorsque le type d’ordinateur est MIPS, le réadressage de base s’applique à une instruction de saut MIPS.
IMAGE_REL_BASED_ARM_MOV32
5
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est ARM ou Thumb. Le réadressage de base applique l’adresse 32 bits d’un symbole à une paire d’instructions MOVW/MOVT consécutive.
IMAGE_REL_BASED_RISCV_HIGH20
5
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est RISC-V. Le réadressage de base s’applique aux 20 bits de pois fort d’une adresse absolue de 32 bits.
6
Réservée, doit être zéro.
IMAGE_REL_BASED_THUMB_MOV32
7
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est Thumb. Le réadressage de base applique l’adresse 32 bits d’un symbole à une paire d’instructions MOVW/MOVT consécutive.
IMAGE_REL_BASED_RISCV_LOW12I
7
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est RISC-V. Le réadressage de base s’applique aux 12 bits de poids faible d’une adresse absolue 32 bits formée dans le format d’instruction de type RISC-V I.
IMAGE_REL_BASED_RISCV_LOW12S
8
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est RISC-V. Le réadressage de base s’applique aux 12 bits de poids faible d’une adresse absolue 32 bits formée dans le format d’instruction de type RISC-V S.
IMAGE_REL_BASED_LOONGARCH32_MARK_LA
8
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est LoongArch 32 bits. Le réadressage de base s’applique à une adresse absolue 32 bits formée dans deux instructions consécutives.
IMAGE_REL_BASED_LOONGARCH64_MARK_LA
8
Ce réadressage est uniquement significatif lorsque le type d’ordinateur est LoongArch 64 bits. Le réadressage de base s’applique à une adresse absolue 64 bits formée dans quatre instructions consécutives.
IMAGE_REL_BASED_MIPS_JMPADDR16
9
Le réadressage est uniquement significatif lorsque le type d’ordinateur est MIPS. Le réadressage de base s’applique à une instruction de saut MIPS16.
IMAGE_REL_BASED_DIR64
10
Le réadressage de base applique la différence au champ 64 bits au niveau du décalage.

 

La section .tls

La section .tls fournit une prise en charge directe par PE et COFF du stockage local des threads de type statique (TLS). TLS est une classe de stockage spéciale prise en charge par Windows dans laquelle un objet de données n’est pas une variable (pile) automatique, tout en étant local à chaque thread individuel qui exécute le code. Ainsi, chaque thread peut conserver une valeur différente pour une variable déclarée à l’aide de TLS.

Notez que n’importe quelle quantité de données TLS peut être prise en charge en utilisant les appels API TlsAlloc, TlsFree, TlsSetValue et TlsGetValue. L’implémentation PE ou COFF est une approche alternative à l’utilisation de l’API et présente l’avantage d’être plus simple du point de vue du programmeur en langage de haut niveau. Cette implémentation permet de définir et d’initialiser des données TLS de la même façon que les variables statiques ordinaires d’un programme. Par exemple, dans Visual C++, une variable TLS statique peut être définie comme suit, sans utiliser l’API Windows :

__declspec (thread) int tlsFlag = 1;

Pour prendre en charge cette structure de programmation, la section .tls du PE et du COFF spécifie les informations suivantes : données d’initialisation, routines de rappel pour l’initialisation et l’arrêt par thread, et l’index TLS, qui sont expliqués dans la discussion suivante.

Remarque

Avant Windows Vista, les objets de données TLS déclarés statiquement ne peuvent être utilisés que dans les fichiers image chargés statiquement. Il n’est donc pas fiable d’utiliser des données TLS statiques dans une DLL, à moins de savoir que cette dernière, ou tout ce qui est lié statiquement à elle, ne sera jamais chargée dynamiquement à l’aide de la fonction API LoadLibrary. Toutefois, à partir de Windows Vista, des améliorations ont été apportées au chargeur Windows pour mieux prendre en charge le chargement dynamique des DLL avec un TLS statique. Ce changement implique que les DLL avec des objets de données TLS déclarés statiquement peuvent maintenant être utilisés de manière plus fiable, même s’ils sont chargés dynamiquement à l’aide de LoadLibrary Le chargeur est capable d’allouer des emplacements TLS pour de telles DLL au moment du chargement, ce qui atténue les limitations présentes dans les versions antérieures de Windows.

 

Remarque

Les références aux décalages de 32 bits et aux multiplicateurs d’index de 4 s’appliquent aux systèmes dotés d’architectures de 32 bits. Dans un système basé sur des architectures 64 bits, ajustez-les si nécessaire.

Le code exécutable accède à un objet de données TLS statique en suivant les étapes ci-dessous :

  1. Au moment de la liaison, l’éditeur de liens définit le champ Adresse de l’index du répertoire TLS. Ce champ pointe vers un emplacement où le programme s’attend à recevoir l’index TLS.

    La bibliothèque runtime Microsoft facilite ce processus en définissant une image mémoire du répertoire TLS et en lui donnant le nom spécial « __tls_used » (plateformes Intel x86) ou « _tls_used » (autres plateformes). L’éditeur de liens recherche cette image mémoire et utilise les données qu’elle contient pour créer le répertoire TLS. D’autres compilateurs qui prennent en charge TLS et qui fonctionnent avec l’éditeur de liens Microsoft doivent utiliser cette même technique.

  2. Lorsqu’un thread est créé, le chargeur communique l’adresse du tableau TLS du thread en plaçant l’adresse du bloc d’environnement de thread (TEB) dans le registre FS. Un pointeur vers le tableau TLS se trouve au niveau du décalage de 0x2C à partir du début du TEB. Ce comportement est spécifique à Intel x86.

  3. Le chargeur affecte la valeur de l’index TLS à l’emplacement indiqué par le champ Adresse de l’index.

  4. Le code exécutable récupère l’index TLS ainsi que l’emplacement du tableau TLS.

  5. Le code utilise l’index TLS et l’emplacement du tableau TLS (en multipliant l’index par 4 et en l’utilisant comme décalage vers le tableau) pour obtenir l’adresse de la zone de données TLS pour le programme et le module donnés. Chaque thread possède sa propre zone de données TLS, mais cela reste transparent pour le programme, qui n’a pas besoin de savoir comment les données sont allouées aux différents threads.

  6. Un objet de données TLS individuel est accessible sous la forme d’un décalage fixe dans la zone de données TLS.

Le tableau TLS est un tableau d’adresses que le système maintient pour chaque thread. Chaque adresse de ce tableau indique l’emplacement des données TLS pour un module donné (EXE ou DLL) dans le programme. L’index TLS indique le membre du tableau à utiliser. L’index est un nombre (significatif uniquement pour le système) qui identifie le module.

Le répertoire TLS

Le répertoire TLS a le format suivant :

Décalage (PE32/PE32+) Taille (PE32/PE32+) Champ Description
0
4/8
Adresse virtuelle du début des données brutes
Adresse de départ du modèle TLS. Le modèle est un bloc de données utilisé pour initialiser des données TLS. Le système copie toutes ces données chaque fois qu’un thread est créé, elles ne doivent donc pas être corrompues. Il convient de noter que cette adresse n’est pas une adresse virtuelle relative, mais une adresse pour laquelle il doit y avoir un réadressage de base dans la section .reloc.
4/8
4/8
Adresse virtuelle de fin des données brutes
Adresse du dernier octet du protocole TLS, à l’exception du remplissage de zéros. Comme avec le champ Adresse virtuelle du début des données brutes, il s’agit d’une adresse virtuelle, et non d’une adresse virtuelle relative.
8/16
4/8
Adresse de l’index
L’emplacement pour recevoir l’index TLS, que le chargeur attribue. Cet emplacement se trouve dans une section de données ordinaire, il est donc possible de lui donner un nom symbolique accessible au programme.
12/24
4/8
Adresse des rappels
Pointeur vers un tableau de fonctions de rappel TLS. Le tableau est terminé par une valeur Null, de sorte que si aucune fonction de rappel n’est prise en charge, ce champ pointe vers 4 octets définis sur zéro. Pour en savoir plus sur le prototype de ces fonctions, consultez Fonctions de rappel TLS.
16/32
4
Taille du remplissage de zéros
Taille en octets du modèle, au-delà des données initialisées délimitées par les champs Adresse virtuelle de début des données brutes et Adresse virtuelle de fin des données brutes. La taille totale du modèle doit être identique à la taille totale des données TLS dans le fichier image. Le remplissage de zéros correspond à la quantité de données qui vient après les données non nulles initialisées.
20/36
4
Caractéristiques
Les quatre bits [23:20] décrivent les informations relatives à l’alignement. Les valeurs possibles sont celles définies comme IMAGE_SCN_ALIGN_*, qui sont également utilisées pour décrire l’alignement de la section dans les fichiers objet. Les 28 bits restants sont réservés pour une utilisation future.

 

Fonctions de rappel TLS

Le programme peut fournir une ou plusieurs fonctions de rappel TLS pour prendre en charge une initialisation et une terminaison supplémentaires pour les objets de données TLS. Une utilisation typique d’une telle fonction de rappel serait d’appeler des constructeurs et des destructeurs pour les objets.

Bien qu’il n’y ait généralement pas plus d’une fonction de rappel, un rappel est implémenté sous forme de tableau pour permettre d’ajouter des fonctions de rappel supplémentaires si nécessaire. S’il existe plus d’une fonction de rappel, chacune d’entre elles est appelée dans l’ordre dans lequel son adresse apparaît dans le tableau. Un pointeur Null finit le tableau. Il est tout à fait possible d’avoir une liste vide (aucun rappel pris en charge), auquel cas le tableau de rappels ne comporte qu’un seul membre, un pointeur null.

Le prototype d’une fonction de rappel (désigné par un pointeur de type PIMAGE_TLS_CALLBACK) a les mêmes paramètres qu’une fonction de point d’entrée de DLL :

typedef VOID
(NTAPI *PIMAGE_TLS_CALLBACK) (
    PVOID DllHandle,
    DWORD Reason,
    PVOID Reserved
    );

Le paramètre Reserved doit être défini sur zéro. Le paramètre Reason peut prendre les valeurs suivantes :

Paramètre valeur Description
DLL_PROCESS_ATTACH
1
Un nouveau processus a démarré, y compris le premier thread.
DLL_THREAD_ATTACH
2
Un nouveau thread a été créé. Cette notification a été envoyée pour tous les threads, sauf le premier.
DLL_THREAD_DETACH
3
Un thread est sur le point d’être arrêté. Cette notification a été envoyée pour tous les threads, sauf le premier.
DLL_PROCESS_DETACH
0
Un processus est sur le point de se terminer, y compris le thread d’origine.

 

La structure de configuration du chargement (image uniquement)

La structure de configuration de chargement (IMAGE_LOAD_CONFIG_DIRECTORY) était auparavant utilisée dans des cas très limités dans le système d’exploitation Windows NT lui-même pour décrire diverses fonctionnalités trop difficiles ou trop importantes pour être décrites dans l’en-tête du fichier ou dans l’en-tête facultatif de l’image. Les versions actuelles de l’éditeur de liens Microsoft et de Windows XP et des versions ultérieures de Windows utilisent une nouvelle version de cette structure pour les systèmes x86 32 bits qui incluent la technologie SEH réservée. On obtient ainsi une liste des gestionnaires d’exceptions structurées sécurisés que le système d’exploitation utilise lors de la répartition des exceptions. Si l’adresse du gestionnaire réside dans la plage des adresses virtuelles d’une image et est marquée comme réservée prenant en charge SEH (autrement dit, IMAGE_DLLCHARACTERISTICS_NO_SEH est vide dans le champ DllCharacteristics de l’en-tête facultatif, comme décrit précédemment), le gestionnaire doit se trouver dans la liste des gestionnaires sécurisés connus pour cette image. Sinon, le système d’exploitation met fin à l’application. Cela permet d’empêcher l’exploitation de « détournement du gestionnaire d’exceptions x86 » qui a été utilisé dans le passé pour prendre le contrôle du système d’exploitation.

L’éditeur de liens Microsoft fournit automatiquement une structure de configuration de chargement par défaut pour inclure les données SEH réservées. Si le code utilisateur fournit déjà une structure de configuration de chargement, il doit inclure les nouveaux champs SEH réservés. Dans le cas contraire, l’éditeur de liens ne peut pas inclure les données SEH réservées et l’image n’est pas marquée comme contenant la SEH réservée.

Répertoire de configuration du chargement

L’entrée de répertoire de données d’une structure de configuration de chargement SEH préréservée doit spécifier une taille particulière de la structure de configuration de chargement, car le chargeur du système d’exploitation s’attend toujours à ce qu’elle soit d’une certaine valeur. À cet égard, la taille n’est en fait qu’une vérification de la version. Pour la compatibilité avec Windows XP et les versions antérieures de Windows, la taille doit être 64 pour les images x86.

Disposition de la configuration du chargement

La structure de configuration du chargement présente la disposition suivante pour les fichiers PE 32 bits et 64 bits :

Contrepartie Taille Champ Description
0
4
Caractéristiques
Indicateurs qui indiquent les attributs du fichier, actuellement inutilisés.
4
4
TimeDateStamp
Valeur de l’horodatage. La valeur est représentée par le nombre de secondes écoulées depuis minuit (00:00:00), le 1er janvier 1970, temps universel coordonné (UTC), d’après l’horloge système. L’horodatage peut être imprimé à l’aide de la fonction d’heure runtime C (CRT).
8
2
MajorVersion
Numéro de version majeur.
10
2
MinorVersion
Numéro de version mineur.
12
4
GlobalFlagsClear
Les indicateurs globaux du chargeur à effacer pour ce processus lorsque le chargeur démarre le processus.
16
4
GlobalFlagsSet
Les indicateurs globaux du chargeur à définir pour ce processus lorsque le chargeur démarre le processus.
20
4
CriticalSectionDefaultTimeout
Valeur de délai d’expiration par défaut à utiliser pour les sections critiques de ce processus abandonnées.
24
4/8
DeCommitFreeBlockThreshold
Mémoire qui doit être libérée avant d’être restituée au système, en octets.
28/32
4/8
DeCommitTotalFreeThreshold
Quantité totale de mémoire disponible, en octets.
32/40
4/8
LockPrefixTable
[x86 uniquement] Adresse virtuelle d’une liste d’adresses où le préfixe LOCK est utilisé afin qu’elles puissent être remplacées par un NOP sur des ordinateurs monoprocesseur.
36/48
4/8
MaximumAllocationSize
Taille maximale de l’allocation en octets.
40/56
4/8
VirtualMemoryThreshold
Taille maximale de la mémoire virtuelle, en octets.
44/64
4/8
ProcessAffinityMask
Donner à ce champ une valeur non nulle équivaut à appeler SetProcessAffinityMask avec cette valeur lors du démarrage du processus (.exe uniquement)
48/72
4
ProcessHeapFlags
Indicateurs du tas du processus correspondant au premier argument de la fonction HeapCreate. Ces indicateurs s’appliquent au tas du processus créé lors du démarrage de ce dernier.
52/76
2
CSDVersion
Identificateur de version du Service Pack.
54/78
2
DependentLoadFlags
Indicateurs de charge par défaut utilisés lorsque le système d’exploitation résout les importations liées statiquement d’un module.
56/80
4/8
EditList
Réservé à l’usage du système.
60/88
4/8
SecurityCookie
Pointeur vers un cookie utilisé par l’implémentation de Visual C++ ou de GS.
64/96
4/8
SEHandlerTable
[x86 uniquement] Adresse virtuelle de la table triée des adresses virtuelles relatives de chaque gestionnaire SE valide et unique dans l’image.
68/104
4/8
SEHandlerCount
[x86 uniquement] Nombre de gestionnaires uniques dans la table.
72/112
4/8
GuardCFCheckFunctionPointer
Adresse virtuelle où le pointeur de la fonction de vérification de la protection du flux de contrôle est stocké.
76/120
4/8
GuardCFDispatchFunctionPointer
Adresse virtuelle où le pointeur de la fonction de répartition de la protection du flux de contrôle est stocké.
80/128
4/8
GuardCFFunctionTable
Adresse virtuelle de la table triée des adresses virtuelles relatives de chaque fonction de protection du flux de contrôle dans l’image.
84/136
4/8
GuardCFFunctionCount
Nombre d’adresses virtuelles relatives uniques dans le tableau ci-dessus.
88/144
4
GuardFlags
Indicateurs associés à la protection du flux de contrôle.
92/148
12
CodeIntegrity
Informations sur l’intégrité du code.
104/160
4/8
GuardAddressTakenIatEntryTable
Adresse virtuelle où est stockée l’adresse de la protection du flux de contrôle prise dans la table IAT.
108/168
4/8
GuardAddressTakenIatEntryCount
Nombre d’adresses virtuelles relatives uniques dans le tableau ci-dessus.
112/176
4/8
GuardLongJumpTargetTable
Adresse virtuelle où est stockée la table cible de saut long de la protection du flux de contrôle.
116/184
4/8
GuardLongJumpTargetCount
Nombre d’adresses virtuelles relatives uniques dans le tableau ci-dessus.

 

Le champ GuardFlags contient une combinaison d’un ou plusieurs des indicateurs et sous-champs suivants :

  • Le module effectue des vérifications de l’intégrité du flux de contrôle en utilisant le support fourni par le système.

    #define IMAGE_GUARD_CF_INSTRUMENTED 0x00000100

  • Le module effectue des vérifications du flux de contrôle et de l’intégrité de l’écriture.

    #define IMAGE_GUARD_CFW_INSTRUMENTED 0x00000200

  • Le module contient des métadonnées cibles de flux de contrôle valides.

    #define IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT 0x00000400

  • Le module n’utilise pas le cookie de sécurité/GS.

    #define IMAGE_GUARD_SECURITY_COOKIE_UNUSED 0x00000800

  • Le module prend en charge l’IAT à chargement différé en lecture seule.

    #define IMAGE_GUARD_PROTECT_DELAYLOAD_IAT 0x00001000

  • La table d’importation à chargement différé se trouve dans sa propre section .didat (sans rien d’autre) qui peut être librement reprotégée.

    #define IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION 0x00002000

  • Le module contient des informations sur l’exportation supprimées. Cela déduit également que la table IAT prise d’adresse est également présente dans la configuration de chargement.

    #define IMAGE_GUARD_CF_EXPORT_SUPPRESSION_INFO_PRESENT 0x00004000

  • Le module permet la suppression des exportations.

    #define IMAGE_GUARD_CF_ENABLE_EXPORT_SUPPRESSION 0x00008000

  • Le module contient des informations cibles longjmp.

    #define IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 0x00010000

  • Masque pour le sous-champ qui contient le stride des entrées de la table de la fonction de protection du flux de contrôle (c’est-à-dire le nombre supplémentaire d’octets par entrée de la table).

    #define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK 0xF0000000

En outre, l’en-tête winnt.h du kit SDK Windows définit cette macro pour que la quantité de bits décale vers la droite la valeur GuardFlags pour justifier à droite le stride de la table de fonctions de protection du flux de contrôle :

#define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_SHIFT 28

La section .rsrc

Les ressources sont indexées par une arborescence triée binairement à plusieurs niveaux. La conception générale peut incorporer 2**31 niveaux. Par convention, toutefois, Windows en utilise trois :

Type Nom Langage

Une série de tables de répertoire de ressources relie tous les niveaux de la manière suivante : chaque table de répertoire est suivie d’une série d’entrées de répertoire qui indiquent le nom ou l’identifiant (ID) de ce niveau (niveau de Type, Nom ou Langage) et l’adresse d’une description de données ou d’une autre table de répertoire. Si l’adresse pointe vers une description de données, les données sont une feuille de l’arborescence. Si l’adresse pointe vers une autre table de répertoire, cette dernière répertorie les entrées de répertoire au niveau inférieur suivant.

Les ID de type, de nom et de langage d’une feuille sont déterminés par le chemin emprunté dans les tables de répertoire pour atteindre la feuille. La première table détermine l’ID de type, la deuxième table (pointée par l’entrée de répertoire dans la première table) détermine l’ID de nom, et la troisième table détermine l’ID de langage.

La structure générale de la section .rsrc est la suivante :

Données Description
Tables de répertoires de ressources (et entrées de répertoires de ressources)
Une série de tables, une pour chaque groupe de nœuds de l’arborescence. Tous les nœuds de niveau supérieur (Type) sont répertoriés dans la première table. Les entrées de ce tableau pointent vers des tables de deuxième niveau. Chaque arborescence de deuxième niveau a le même ID de Type, mais des ID de nom différents. Les arborescences de troisième niveau ont les mêmes ID de Type et de Nom, mais des ID de langage différents.
Chaque table individuelle est immédiatement suivie d’entrées de répertoire, dans lesquelles chaque entrée a un nom ou un identifiant numérique et un pointeur vers une description de données ou une table au niveau inférieur suivant.
Chaînes du répertoire de ressources
Chaînes Unicode alignées sur deux octets, qui servent de données de chaîne vers lesquelles pointes des entrées de répertoire.
Description des données des ressources
Un tableau d’enregistrements, vers lesquels pointent les tables, qui décrivent la taille et l’emplacement réels des données de la ressource. Ces enregistrements sont les feuilles de l’arborescence de description des ressources.
Données des ressources
Données brutes de la section des ressources. Les informations sur la taille et l’emplacement dans le champ Descriptions des données des ressources délimitent les régions individuelles des données de ressources.

 

Table du répertoire de ressources

Chaque table de répertoire de ressources a le format suivant. Cette structure de données doit être considérée comme l’en-tête d’une table, car la table se compose en fait d’entrées de répertoire (décrites dans la section 6.9.2, « Entrées du répertoire de ressources ») et de cette structure :

Contrepartie Taille Champ Description
0
4
Caractéristiques
Indicateurs de ressources. Ce champ est réservé à une utilisation ultérieure. Il est actuellement défini sur zéro.
4
4
Date/horodatage
Heure à laquelle les données de ressources ont été créées par le compilateur de ressources.
8
2
Version principale
Numéro de version principale défini par l’utilisateur.
10
2
Version mineure
Numéro de version mineure défini par l’utilisateur.
12
2
Nombre d’entrées de noms
Nombre d’entrées de répertoire immédiatement après la table qui utilise des chaînes pour identifier les entrées Type, Nom ou Langage (selon le niveau de la table).
14
2
Nombre d’entrées d’ID
Nombre d’entrées de répertoires immédiatement après les entrées Nom qui utilisent des ID numériques pour les entrées Type, Non ou Langage.

 

Entrées du répertoire de ressources

Les entrées de répertoire composent les lignes d’une table. Chaque entrée de répertoire de ressources a le format suivant. La table du répertoire des ressources indique s’il s’agit d’une entrée de nom ou d’une entrée d’ID, en précisant le nombre d’entrées de nom et d’ID qui la suivent ( rappelons que toutes les entrées de nom précèdent toutes les entrées d’ID de la table). Toutes les entrées de la table sont triées par ordre croissant : les entrées de Nom par chaîne sensible à la casse et les entrées ID par valeur numérique. Les décalages sont relatifs à l’adresse dans le IMAGE_DIRECTORY_ENTRY_RESOURCE DataDirectory. Pour en savoir plus, consultez Peering dans le PE : présentation du format de fichier exécutable portable Win32.

Contrepartie Taille Champ Description
0
4
Décalage du nom
Décalage d’une chaîne qui indique l’entrée Type, Nom ou ID de langage, en fonction du niveau de table.
0
4
ID entier
Entier 32 bits qui identifie l’entrée Type, Nom ou ID de langage.
4
4
Décalage d’entrée de données
Bit 0 de poids fort. Adresse d’une entrée de données de ressource (une feuille).
4
4
Décalage de sous-répertoire
Bit 1 de poids fort. Les 31 bits inférieurs sont l’adresse d’une autre table de répertoire de ressources (niveau inférieur suivant).

 

Chaîne du répertoire de ressources

La zone de la chaîne du répertoire des ressources est constituée de chaînes Unicode, alignées sur les mots. Ces chaînes sont stockées ensemble après la dernière entrée du répertoire de ressources et avant la première entrée de données de ressource. Cela réduit l’impact de ces chaînes de longueur variable sur l’alignement des entrées de répertoire de taille fixe. Chaque chaîne de répertoire de ressources a le format suivant :

Contrepartie Taille Champ Description
0
2
Longueur
Taille de la chaîne, sans compter le champ de longueur lui-même.
2
variable
Chaîne unicode
Données de chaîne Unicode de longueur variable, alignées sur le mot.

 

Entrée des données de ressources

Chaque entrée des données de ressources décrit une unité réelle de données brutes dans la zone Données de ressource. Une entrée de données de ressources a le format suivant :

Contrepartie Taille Champ Description
0
4
RVA des données
 Adresse d’une unité de données de ressources dans la zone Données de ressources.
4
4
Taille
Taille, en octets, des données de ressource pointées par le champ Adresse virtuelle relative des données.
8
4
Codepage
Page de code utilisée pour décoder les valeurs des points de code dans les données de ressources. En général, la page de code est la page de code Unicode.
12
4
Réservée, doit être 0.

 

La section .cormeta (objet uniquement)

Les métadonnées CLR sont stockées dans cette section. Elle est utilisée pour indiquer que le fichier objet contient du code managé. Le format des métadonnées n’est pas documenté, mais il peut être transmis aux interfaces CLR pour la gestion des métadonnées.

La section .sxdata

Les gestionnaires d’exceptions valides d’un objet sont répertoriés dans la section .sxdata de cet objet. La section est marquée IMAGE_SCN_LNK_INFO. Elle contient l’index de symbole COFF de chaque gestionnaire valide, en utilisant 4 octets par index.

En outre, le compilateur marque un objet COFF en tant que SEH inscrit en émettant le symbole absolu « @feat.00 » avec le LSB du champ valeur défini sur 1. Un objet COFF sans gestionnaires SEH inscrits présenterait le symbole « @feat.00 », mais aucune section .sxdata.

Format de fichier d’archive (bibliothèque)

Le format d’archive COFF fournit un mécanisme standard pour stocker des collections de fichiers objet. Dans la documentation de programmation, ces collections sont communément appelées bibliothèques.

Les 8 premiers octets d’une archive se composent de la signature du fichier. Le reste de l’archive se compose d’une série de membres de l’archive, comme suit :

  • Les premier et deuxième membres sont des « membres de l’éditeur de liens ». Chacun de ces membres a son propre format, comme décrit dans la section Type de nom d’importation. En général, un éditeur de liens place des informations dans ces membres de l’archive. Les membres de l’éditeur de liens contiennent le répertoire de l’archive.

  • Le troisième membre est le membre « longnames ». Ce membre facultatif se compose d’une série de chaînes ASCII terminées par une valeur nulle, chaque chaîne étant le nom d’un autre membre de l’archive.

  • Le reste de l’archive se compose de membres standard (fichier objet). Chacun de ces membres contient le contenu d’un fichier objet dans son intégralité.

Chaque membre est précédé d’un en-tête de membre d’archive. La liste suivante présente la structure générale d’une archive :

Signature :"!<arch>\n"
En-tête
1er membre de l’éditeur de liens
En-tête
2e membre de l’éditeur de liens
En-tête
Membre Longnames
En-tête
Contenu du fichier 1 OBJ
(format COFF)
En-tête
Contenu du fichier 2 OBJ
(format COFF)

...

En-tête
Contenu du fichier N OBJ
(format COFF)

Signature de fichier d’archive

La signature de fichier d’archive identifie le type de fichier. Tout utilitaire (par exemple, un éditeur de liens) qui accepte un fichier d’archive en entrée peut vérifier le type de fichier en lisant cette signature. La signature se compose des caractères ASCII suivants, dans lesquels chaque caractère ci-dessous est représenté littéralement, à l’exception du caractère de nouvelle ligne (\n) :

!<arch>\n

L’en-tête winnt.h du kit SDK Windows définit les macros suivantes :

#define IMAGE_ARCHIVE_START_SIZE             8
#define IMAGE_ARCHIVE_START                  "!<arch>\n"
#define IMAGE_ARCHIVE_END                    "`\n"
#define IMAGE_ARCHIVE_PAD                    "\n"
#define IMAGE_ARCHIVE_LINKER_MEMBER          "/               "
#define IMAGE_ARCHIVE_LONGNAMES_MEMBER       "//              "
#define IMAGE_ARCHIVE_HYBRIDMAP_MEMBER       "/<HYBRIDMAP>/   "

En-têtes des membres de l’archive

Chaque membre (éditeur de liens, longnames ou membre du fichier objet) est précédé d’un en-tête. Un en-tête de membre d’une archive a le format suivant, dans lequel chaque champ est une chaîne de texte ASCII justifiée à gauche et complétée par des espaces jusqu’à la fin du champ. Aucun de ces champs ne se termine par un caractère null.

Chaque en-tête de membre commence à la première adresse paire après la fin du membre d’archive précédent, un octet ’\n’ (IMAGE_ARCHIVE_PAD) peut être inséré après un membre d’archive pour que le membre suivant commence à une adresse paire.

Contrepartie Taille Champ Description
0
16
Nom
Nom du membre d’archive, avec une barre oblique (/) ajoutée pour terminer le nom. Si le premier caractère est une barre oblique, le nom a une interprétation spéciale, comme décrit dans le tableau suivant.
16
12
Date
Date et heure de création du membre d’archive : il s’agit de la représentation décimale ASCII du nombre de secondes depuis le 1/1/1970 UCT.
28
6
ID d’utilisateur
Représentation décimale ASCII de l’ID utilisateur. Ce champ ne contient pas de valeur significative sur les plateformes Windows, car les outils Microsoft génèrent tous les espaces.
34
6
ID de groupe
Représentation décimale ASCII de l’ID de groupe. Ce champ ne contient pas de valeur significative sur les plateformes Windows, car les outils Microsoft génèrent tous les espaces.
40
8
Mode
Représentation ASCII octale du mode fichier du membre. Il s’agit de la valeur ST_MODE de la fonction runtime C _wstat.
48
10
Taille
Représentation ASCII décimale de la taille totale du membre d’archive, sans inclure la taille de l’en-tête.
58
2
Fin de l’en-tête
Deux octets (0x60 0x0A) dans la chaîne C "`\n" (IMAGE_ARCHIVE_END).

Le champ Nom présente l’un des formats indiqués dans le tableau suivant. Comme indiqué précédemment, chacune de ces chaînes est justifiée à gauche et complétée par des espaces de fin dans un champ de 16 octets :

Contenu du champ Nom Description
name/
Nom du membre d’archive.
/
Le membre d’archive est l’un des deux membres de l’éditeur de liens. Les deux membres de l’éditeur de liens ont ce nom.
//
Le membre archive est le membre longnames, qui se compose d’une série de chaînes ASCII terminées par une valeur null. Le membre longnames est le troisième membre d’archive et est facultatif.
/n
Le nom du membre d’archive se trouve au niveau du décalage n dans le membre longnames. Le nombre n est la représentation décimale du décalage. Par exemple : "/26" indique que le nom du membre d’archive se trouve à 26 octets près le début du contenu du membre longnames.

 

Premier membre de l’éditeur de liens

Le nom du premier membre de l’éditeur de liens est "/" (IMAGE_ARCHIVE_LINKER_MEMBER). Le premier membre de l’éditeur de liens est inclus pour la compatibilité descendante. Il n’est pas utilisé par les éditeurs de liens actuels, mais son format doit être correct. Ce membre de l’éditeur de liens fournit un répertoire de noms de symboles, tout comme le deuxième membre de l’éditeur de liens. Pour chaque symbole, les informations indiquent où trouver le membre d’archive qui contient le symbole.

Le premier membre de l’éditeur de liens a le format suivant. Ces informations s’affichent après l’en-tête :

Contrepartie Taille Champ Description
0
4
Nombre de symboles
Long non signé qui contient le nombre de symboles indexés. Ce nombre est stocké au format big-endian. Chaque membre du fichier objet définit généralement un ou plusieurs symboles externes.
4
4 * n
Décalages
Un tableau de décalages de fichiers pour les en-têtes des membres d’archive, dans lequel n est égal au champ Nombre de symboles. Chaque nombre du tableau est de type long non signé stocké au format big-endian. Pour chaque symbole désigné dans le tableau des chaînes, l’élément correspondant du tableau des décalages indique l’emplacement du membre d’archive qui contient le symbole.
*
*
Table de chaînes
Série de chaînes terminées par la valeur null qui nomment tous les symboles du répertoire. Chaque chaîne commence immédiatement après le caractère Null de la chaîne précédente. Le nombre de chaînes doit être égal à la valeur du champ Nombre de symboles.

 

Les éléments du tableau des décalages doivent être organisés dans l’ordre croissant. Cela implique que les symboles de la table de chaînes doivent être organisés en fonction de l’ordre des membres d’archive. Par exemple, tous les symboles du premier membre du fichier objet doivent être répertoriés avant les symboles du deuxième fichier objet.

Second membre de l’éditeur de liens

Comme le premier membre de l’éditeur de liens, le deuxième membre de l’éditeur de liens a le nom "/" (IMAGE_ARCHIVE_LINKER_ME MEMBER). Les deux membres de l’éditeur de liens fournissent un répertoire des symboles et des membres d’archives qui les contiennent, mais le second est utilisé de préférence au premier par tous les éditeurs de liens actuels. Le deuxième membre de l’éditeur de liens inclut des noms de symboles dans l’ordre lexical, ce qui permet une recherche plus rapide par nom.

Le deuxième membre a le format suivant. Ces informations s’affichent après l’en-tête :

Contrepartie Taille Champ Description
0
4
Nombre de membres
Long non signé qui contient le nombre de membres d’archive.
4
4 * m
Décalages
Tableau des décalages de fichiers pour les en-têtes de membres d’archive, organisés dans l’ordre croissant. Chaque décalage est un long non signé. Le nombre m est égal à la valeur du champ Nombre de membres.
*
4
Nombre de symboles
Long non signé qui contient le nombre de symboles indexés. Chaque membre du fichier objet définit généralement un ou plusieurs symboles externes.
*
2 * n
Index
Tableau d’index basés sur 1 (court non signé) qui mappent les noms de symboles aux décalages des membres d’archive. Le nombre n est égal au champ Nombre de symboles. Pour chaque symbole nommé dans la table de chaînes, l’élément correspondant dans le tableau des Index indique un index dans le tableau des décalages. Le tableau des décalages indique quant à lui l’emplacement du membre d’archive qui contient le symbole.
*
*
Table de chaînes
Série de chaînes terminées par la valeur null qui nomment tous les symboles du répertoire. Chaque chaîne commence immédiatement après l’octet Null de la chaîne précédente. Le nombre de chaînes doit être égal à la valeur du champ Nombre de symboles. Ce tableau répertorie tous les noms de symboles dans l’ordre lexical croissant.

 

Membre Longnames

Le nom du membre longnames est "//" (IMAGE_ARCHIVE_LONGNAMES_MEMBER). Le membre longnames est une série de chaînes de noms de membres d’archive. Un nom apparaît ici uniquement lorsque le champ Nom (16 octets) ne contient pas suffisamment d’espace. Le membre longnames est facultatif. Il peut être vide, avec seulement un en-tête, ou complètement absent, sans même un en-tête.

Les chaînes sont terminées par une valeur null. Chaque chaîne commence immédiatement après l’octet Null de la chaîne précédente.

Format de la bibliothèque d’importation

Les bibliothèques d’importation traditionnelles, c’est-à-dire les bibliothèques qui décrivent les exportations d’une image en vue de leur utilisation par une autre image, sont généralement organisées selon la structure décrite dans la section 7 : Format de fichier d’archive (bibliothèque). La principale différence réside dans le fait que les membres de la bibliothèque d’importation contiennent des fichiers pseudo-objet au lieu de fichiers réels, dans lesquels chaque membre inclut les contributions de section nécessaires pour construire les tables d’importation décrites dans la section 6.4 : La section .idata L’éditeur de liens génère cette archive lors de la construction de l’application d’exportation.

Les contributions de la section pour une importation peuvent être déduites d’un petit ensemble d’informations. L’éditeur de liens peut soit générer les informations complètes et détaillées dans la bibliothèque d’importation pour chaque membre au moment de la création de cette dernière, soit écrire uniquement les informations canoniques dans la bibliothèque et laisser l’application qui l’utilisera ultérieurement générer les données nécessaires à la volée.

Dans une bibliothèque d’importation avec le format long, un seul membre contient les informations suivantes :

  • En-tête du membre d’archive
  • En-tête du fichier
  • En-têtes des sections
  • Données qui correspondent à chacun des en-têtes des sections
  • Table de symboles COFF
  • Chaînes

En revanche, une bibliothèque d’importation courte est écrite comme suit :

  • En-tête du membre d’archive
  • En-tête d’importation
  • Chaîne de nom d’importation terminée par une valeur null
  • Chaîne de nom DLL terminée par une valeur null

Ces informations sont suffisantes pour reconstituer avec précision l’ensemble du contenu du membre au moment de son utilisation.

En-tête d’importation

L’en-tête d’importation contient les champs et décalages suivants :

Contrepartie Taille Champ Description
0
2
Sig1
Doit être IMAGE_FILE_MACHINE_UNKNOWN. Pour plus d’informations, consultez Types d’ordinateurs.
2
2
Sig2
Doit être 0xFFFF.
4
2
Version
Version de la structure.
6
2
Machine
Numéro qui identifie le type d’erreur de l’ordinateur cible. Pour plus d’informations, consultez Types d’ordinateurs.
8
4
Date/horodatage
Date et heure de création du fichier.
12
4
Taille des données
Taille des chaînes qui suivent l’en-tête.
16
2
Ordinal/Indicateur
Ordinal ou indicateur de l’importation, déterminé par la valeur dans le champ Type de nom.
18
2 bits
 Tapez .
 Type d’importation. Pour obtenir des valeurs et des descriptions spécifiques, consultez Type d’importation.
3 bits
 Type de nom
Type de nom d’importation. Pour en savoir plus, consultez Type de nom d’importation.
11 bits
 Réservé
Réservée, doit être 0.

 

Cette structure est suivie de deux chaînes terminées par une valeur null qui décrivent le nom du symbole importé et la DLL dont il provient.

Type d’importation

Les valeurs suivantes sont définies pour le champ Type dans l’en-tête d’importation :

Constant Valeur Description
IMPORT_OBJECT_CODE
0
Code exécutable.
IMPORT_OBJECT_DATA
1
Données.
IMPORT_OBJECT_CONST
2
Spécifié en tant que CONST dans le fichier .def.

Ces valeurs sont utilisées pour déterminer quelles contributions de section doivent être générées par l’outil qui utilise la bibliothèque s’il doit accéder à ces données.

Type de nom d’importation

Le nom du symbole d’importation terminé par une valeur null suit immédiatement son en-tête d’importation associé. Les valeurs suivantes sont définies pour le champ Type de nom dans l’en-tête d’importation. Elles indiquent comment le nom doit être utilisé pour générer les symboles adéquats qui représentent l’importation :

Constant Valeur Description
IMPORT_OBJECT_ORDINAL 0 L’importation est effectuée par ordinal. Cela indique que la valeur dans le champ Ordinal/Indicateur de l’en-tête d’importation est l’ordinal de l’importation. Si cette constante n’est pas spécifiée, le champ Ordinal/Indicateur doit toujours être interprété comme l’indicateur de l’importation.
IMPORT_OBJECT_NAME 1 Le nom d’importation est identique au nom du symbole public.
IMPORT_OBJECT_NAME_NOPREFIX 2 Le nom de l’importation est le nom du symbole public, mais sans le premier ?, @, ou éventuellement _.
IMPORT_OBJECT_NAME_UNDECORATE 3 Le nom d’importation est le nom du symbole public, mais sans le premier ?, @ou éventuellement _, et la troncation au premier @.

Annexe A : calcul du hachage de l’image Authenticode PE

Pour vérifier l’intégrité des images, on devrait utiliser plusieurs certificats d’attributs. Toutefois, le plus courant est la signature Authenticode. Cette dernière peut permettre de vérifier que les sections concernées d’un fichier image PE n’ont pas été modifiées par rapport à la forme originale du fichier. Pour accomplir cette tâche, les signatures Authenticode contiennent ce que l’on appelle un hachage d’image PE

Qu’est-ce qu’un hachage d’image Authenticode PE ?

Le hachage d’image Authenticode PE, ou hachage de fichier en abrégé, ressemble à une somme de contrôle de fichier en ce sens qu’il produit une petite valeur qui se rapporte à l’intégrité d’un fichier. Une somme de contrôle est produite par un algorithme simple et est utilisée principalement pour détecter les défaillances de la mémoire. En d’autres termes, elle sert à détecter si un bloc de mémoire sur le disque s’est détérioré et si les valeurs qui y sont stockées ont été corrompues. Un hachage de fichier est similaire à une somme de contrôle dans la mesure où il détecte également la corruption d’un fichier. Toutefois, contrairement à la plupart des algorithmes de somme de contrôle, il est très difficile de modifier un fichier pour qu’il ait le même hachage que sa forme originale (non modifiée). Ainsi, une somme de contrôle est conçue pour détecter de simples défaillances de la mémoire qui entraînent une corruption, mais un hachage de fichier peut permettre de détecter des modifications intentionnelles et même subtiles d’un fichier, notamment celles produites par des virus, des pirates informatiques ou des programmes de chevaux de Troie.

Dans une signature Authenticode, le hachage de fichier est signé numériquement à l’aide d’une clé privée connue uniquement du signataire du fichier. L’utilisateur du logiciel peut vérifier l’intégrité du fichier en calculant la valeur de hachage du fichier et en la comparant à la valeur de hachage signée contenue dans la signature numérique Authenticode. Si les hachages du fichier ne correspondent pas, cela signifie qu’une partie du fichier concerné par le hachage de l’image PE a été modifiée.

En quoi consiste le hachage d’une image Authenticode PE ?

Il n’est ni possible ni souhaitable d’inclure toutes les données du fichier image dans le calcul du hachage de l’image PE. Parfois, cela présente simplement des caractéristiques indésirables (par exemple, les informations de débogage ne peuvent pas être supprimées des fichiers diffusés publiquement). Parfois, c’est tout simplement impossible. Il est par exemple impossible d’inclure toutes les informations d’un fichier image dans une signature Authenticode, puis d’insérer la signature Authenticode contenant le hachage de l’image PE dans l’image PE, et de pouvoir ensuite générer un hachage identique de l’image PE en incluant à nouveau toutes les données du fichier image dans le calcul, parce que le fichier contient maintenant la signature Authenticode qui ne s’y trouvait pas à l’origine.

Processus de génération du hachage d’image Authenticode PE

Cette section décrit la façon de calculer le hachage d’une image PE et les parties de cette dernière qui peuvent être modifiées sans invalider la signature Authenticode.

Remarque

Le hachage d’image PE pour un fichier spécifique peut être inclus dans un fichier catalogue séparé sans inclure un certificat d’attribut dans le fichier haché. Ce point est important, car il devient possible d’invalider le hachage de l’image PE dans un fichier catalogue signé par Authenticode en modifiant une image PE qui ne contient pas réellement de signature Authenticode.

Toutes les données des sections de l’image PE qui sont spécifiées dans le tableau des sections sont hachées dans leur intégralité, à l’exception des plages d’exclusion suivantes :

  • Le champ CheckSum du fichier des champs spécifiques à Windows de l’en-tête facultatif. Cette somme de contrôle inclut l’intégralité du fichier (y compris les certificats d’attribut dans le fichier). Il est fort probable que la somme de contrôle soit différente de la valeur originale après l’insertion de la signature Authenticode.

  • Informations relatives aux certificats d’attribut. Les zones de l’image PE liées à la signature Authenticode ne sont pas incluses dans le calcul du hachage de l’image PE, car les signatures Authenticode peuvent être ajoutées à une image ou en être retirées sans compromettre son intégrité globale. Cela ne pose pas de problème, car certains scénarios d’utilisation dépendent de la re-signature des images PE ou de l’ajout d’un horodatage. Authenticode exclut les informations suivantes du calcul de hachage :

    • Le champ Table de certificats des répertoires de données d’en-têtes facultatifs.

    • La table des certificats et les certificats correspondants vers lesquels pointe le champ de la table des certificats mentionné ci-dessus.

    Pour calculer le hachage de l’image PE, Authenticode ordonne les sections spécifiées dans la table des sections par plage d’adresses, puis hache la séquence d’octets résultante, en passant les plages d’exclusion.

  • Les informations antérieures à la fin de la dernière section. La zone située après la dernière section (définie par décalage le plus élevé) n’est pas hachée. Elle contient généralement des informations de débogage. Les informations de débogage peuvent généralement être considérées comme des conseils destinés aux débogueurs ; elles n’affectent pas l’intégrité réelle du programme exécutable. Il est parfaitement possible de supprimer les informations de débogage d’une image après la livraison d’un produit sans que cela n’affecte la fonctionnalité du programme. Cela se fait d’ailleurs parfois dans le but d’économiser de l’espace disque. Il convient de noter que les informations de débogage contenues dans les sections spécifiées de l’image PE ne peuvent pas être supprimées sans invalider la signature Authenticode.

Vous pouvez utiliser les outils makecert et signtool fournis dans le kit SDK de la plate-forme Windows pour essayer de créer et de vérifier des signatures Authenticode. Pour en savoir plus, consultez la section Références, ci-dessous.

Références

Téléchargements et outils pour Windows (y compris le kit SDK Windows)

Création, affichage et gestion des certificats

Procédure pas à pas de signature du code en mode noyau (.doc)

SignTool

Format de signature de l’exécutable portable Authenticode de Windows (.docx)

Fonctions ImageHlp