En-tête GPT : structure, sauvegarde et CRC32
A En-tête GPT Il s'agit d'une structure de métadonnées qui décrit la table de partition GUID (GUID Partition Table) d'un disque. Elle identifie le disque, localise le tableau des entrées de partition, définit les limites utilisables du disque et stocke les sommes de contrôle utilisées pour détecter la corruption des métadonnées. La GPT gère des en-têtes principaux et de secours à des fins de redondance. Comprendre la disposition de leurs octets et leurs champs CRC32 permet de mieux comprendre comment les informations de partition sont validées et pourquoi un en-tête endommagé ne signifie pas nécessairement que les fichiers sous-jacents sont perdus.
Table des matières
Qu'est-ce qu'un en-tête GPT ?
L'en-tête GPT fait partie de la table de partition GUID (GPT), le schéma de partitionnement de disque défini par la spécification UEFI.
Contrairement à l'ancien système Master Boot Record (MBR), le GPT conserve deux copies de ses métadonnées de partition : l'une près du début du disque et l'autre près de la fin.
Chaque en-tête GPT contient les informations nécessaires pour localiser et interpréter le tableau d'entrées de partition qui lui est associé, notamment :
- Une signature identifiant le format GPT.
- La version et la taille de l'en-tête GPT.
- L'emplacement de l'en-tête d'origine et celui de l'en-tête de remplacement.
- Les première et dernière adresses de blocs logiques utilisables.
- Un identifiant unique de disque.
- L'emplacement et les dimensions du tableau d'entrées de partition.
- Sommes de contrôle CRC32 pour garantir l'intégrité des métadonnées.
L'en-tête GPT ne stocke pas directement les noms de fichiers, les structures de dossiers ni le contenu des fichiers. Ces informations relèvent des systèmes de fichiers présents au sein des partitions.
Pour un aperçu du schéma de partitionnement, voir GPT (table de partition GUID). Les définitions officielles figurent dans le Spécification UEFI, section 5.3.
Où se trouve l'en-tête GPT ?
GPT place ses métadonnées principales et de secours aux extrémités opposées d'un disque.
Pour un disque GPT classique :
Localisation | Sommaire |
LBA 0 | MBR de protection |
LBA 1 | En-tête principal GPT |
Conformément aux accords de collaboration (LBA) | Tableau d'entrées de partition principale |
Plage LBA utilisable | Espace disponible pour les cloisons |
Les LBA avant le bloc final | Tableau des entrées de partition de sauvegarde |
Dernier LBA | Sauvegarde de l'en-tête GPT |
Le MBR de protection permet d'éviter que les anciens outils fonctionnant uniquement avec le MBR ne considèrent le disque GPT comme non alloué.
Cela diffère de l'en-tête GPT lui-même. Pour une comparaison avec les métadonnées de partition traditionnelles, voir Table de partition MBR.
Secteurs logiques et adresses en octets
Le GPT utilise des adresses de blocs logiques (LBA), et non des décalages absolus en octets, pour identifier ses structures.
Pour convertir une adresse LBA en décalage en octets :
Décalage en octets = LBA × taille de bloc logique
Par exemple :
- Sur un disque comportant des blocs logiques de 512 octets, l'en-tête principal commence à l'offset de
512(0x200). - Sur un disque comportant des blocs logiques de 4 096 octets, l'en-tête principal commence à l'offset de
4096(0x1000).
L'en-tête occupe généralement 92 octets au sein d'un bloc logique, bien que le format autorise des en-têtes plus volumineux, jusqu'à la taille du bloc logique.
Il ne faut pas confondre un en-tête de 92 octets avec un secteur de 512 octets. Les octets restants d'un bloc d'en-tête de 512 octets sont réservés et doivent être à zéro.
Structure de l'en-tête GPT : champs, décalages et tailles
La structure de l'en-tête GPT est définie dans Spécification UEFI 2.10, tableau 5.5.
Les décalages suivants sont calculés par rapport au début de l'en-tête GPT, et non par rapport au début du disque.
Champ d'application | Décalage (hexadécimal) | Taille | Objectif |
Signature |
| 8 octets | Identifie l'en-tête GPT |
Révision |
| 4 octets | Révision du format GPT |
Taille de l'en-tête |
| 4 octets | Longueur de l'en-tête en octets |
CRC32 d'en-tête |
| 4 octets | Somme de contrôle de l'en-tête |
Réservé |
| 4 octets | Doit être égal à zéro |
MyLBA |
| 8 octets | Emplacement de cet en-tête |
LBA alternatif |
| 8 octets | Emplacement de l'autre en-tête |
Premier LBA utilisable |
| 8 octets | Premier bloc de partition utilisable |
Dernier LBA utilisable |
| 8 octets | Dernier bloc de partition utilisable |
GUID du disque |
| 16 octets | Identifiant unique du disque |
PartitionEntryLBA |
| 8 octets | Début du tableau d'entrées associé |
Nombre d'entrées de partition |
| 4 octets | Nombre de créneaux d'inscription |
Taille de l'entrée de partition |
| 4 octets | Taille de chaque entrée |
PartitionEntryArrayCRC32 |
| 4 octets | Somme de contrôle du tableau d'entrées |
Les champs définis occupent des décalages 0x00 par le biais de 0x5B, soit un total de 92 octets. Les octets provenant de 0x5C jusqu’à la fin du bloc logique sont réservés.
Signature et révision
Un en-tête GPT valide commence par la signature ASCII PIÈCE EFI.
Les huit octets sont les suivants :
45 46 49 20 50 41 52 54
La norme GPT version 1.0 est représentée par les octets en format « little-endian » :
00 00 01 00
Ces chiffres représentent la valeur numérique 0x00010000. La révision de l'en-tête GPT ne correspond pas à la version de la spécification UEFI.
La taille d'en-tête couramment utilisée est de 92 octets, codée comme suit :
5C 00 00 00
GUID du disque et ordre des octets
Le champ « DiskGUID » occupe 16 octets, à partir de l'offset 0x38.
Il identifie le disque GPT. Il diffère du GUID unique de partition stocké dans chaque entrée de partition individuelle.
A GUID also introduces an important detail when interpreting raw hexadecimal data: its first three components use little-endian byte order, while its final eight bytes retain their displayed order.
For example, the illustrative GUID:
f0e1d2c3-b4a5-4c6d-8e9f-102030405060
is stored as:
C3 D2 E1 F0 A5 B4 6D 4C 8E 9F 10 20 30 40 50 60
Reading all 16 raw bytes directly from left to right would produce an incorrect textual GUID.
Partition Entry Array Fields
Three fields define the partition entry array:
PartitionEntryLBAidentifies where the array starts.Nombre d'entrées de partitiondefines its entry count.Taille de l'entrée de partitiondefines the size of each entry.
The array byte length is calculated as:
Array size = Number of entries × Entry size
For an array containing 128 entries, each 128 bytes:
128 × 128 = 16,384 bytes
With 512-byte logical blocks:
16,384 ÷ 512 = 32 logical blocks
This is the partition entry array’s reserved space, not the space occupied by actual file data.
The current UEFI specification defines the entry size as 128 × 2^n bytes, where n is a nonnegative integer. Typical GPT disks use 128-byte entries.
Each slot in the partition entry array describes one partition through its type GUID, unique partition GUID, LBA boundaries, attributes, and name. For a field-by-field explanation of the Structure d'une entrée de partition GPT, including byte offsets and GUID encoding, see our Entrée de partition GPT : champs « Structure », « Array » et « GUID » guide.
Primary and Backup GPT Headers: What Changes?
The primary and backup GPT headers have the same field structure, but they do not contain identical bytes.
Their locations and some internal pointers differ.
Consider an illustrative GPT disk with:
- 100,000 logical blocks, numbered
0par le biais de99,999. - A logical block size of 512 bytes.
- An entry array containing 128 slots of 128 bytes each.
- A 32-block partition entry array at each end.
The layout is:
Structure | Primary GPT | Backup GPT |
Header LBA |
|
|
MyLBA |
|
|
LBA alternatif |
|
|
PartitionEntryLBA |
|
|
Entry array extent |
|
|
Premier LBA utilisable |
|
|
Dernier LBA utilisable |
|
|
Header size | 92 bytes | 92 bytes |
These positions follow directly from the disk size and the two 32-block partition entry arrays.
Par exemple :
Backup array start = Last LBA − Array blocks
99,999 − 32 = 99,967
The final usable block must precede that backup array:
99,967 − 1 = 99,966
Both headers therefore describe the same usable disk range but point to different physical locations for their partition entry arrays.
This arrangement allows GPT-aware software to check the backup metadata when the primary copy is damaged.
However, the presence of two copies does not guarantee that either copy is valid or current.
Worked Example: Decoding the GPT Header from Hexadecimal Bytes
The following example uses deliberately constructed GPT metadata, not bytes captured from a physical disk.
It describes the same 100,000-block disk used above.
The example contains zero populated partitions. All 128 partition entry slots are zero-filled, allowing both entry array checksums to be calculated from a completely defined input.
Step 1: Identify the Header
At the beginning of the primary header, the first 16 bytes are:
45 46 49 20 50 41 52 54 00 00 01 00 5C 00 00 00
Split the sequence by field:
Byte range | Hex bytes | Decoded meaning |
|
|
|
|
| Révision |
|
| Header size: 92 bytes |
The signature, revision, and header size match the expected format.
That establishes a plausible header, but it does not by itself prove that the GPT is valid.
Step 2: Decode the Location Fields
The primary header contains:
Champ d'application | Stored bytes | Decoded value |
MyLBA |
|
|
LBA alternatif |
|
|
Premier LBA utilisable |
|
|
Dernier LBA utilisable |
|
|
PartitionEntryLBA |
|
|
These values use little-endian byte order.
For example, the bytes 9F 86 01 00 00 00 00 00 represent 0x000000000001869F, or decimal 99,999.
The backup header reverses MyLBA et LBA alternatif and changes PartitionEntryLBA à 99,967.
Step 3: Compare the Header Checksums
For this specific synthetic example, using the DiskGUID shown earlier and a zero-filled 16,384-byte partition entry array, the calculated values are:
Somme de contrôle | Primary GPT | Backup GPT |
CRC32 d'en-tête |
|
|
PartitionEntryArrayCRC32 |
|
|
The header checksums differ because the headers contain different location fields.
The partition entry array checksums match because the two arrays contain identical zero-filled bytes.
These are calculated example values, not universal GPT checksum constants. A different disk GUID, partition layout, or metadata change would produce different results.
How GPT Header CRC32 Validation Works
GPT uses two separate CRC32 checksums to detect changes in its partition metadata:
CRC32 d'en-têteverifies the GPT header itself.PartitionEntryArrayCRC32verifies the associated partition entry array.
Both use the standard CRC-32 algorithm, but they cover different byte ranges.
HeaderCRC32: How the Checksum Is Calculated
Les CRC32 d'en-tête field occupies four bytes at header-relative offset 0x10.
Selon le UEFI Specification, the checksum must be calculated with this field temporarily set to zero.
The verification process follows five steps:
- Read the header. Obtain the GPT header bytes from a disk image and determine the
Taille de l'en-têtefield at offset0x0C. - Record the stored CRC32. Read the four bytes at offsets
0x10–0x13as a little-endian 32-bit value. - Zero the checksum field. In a temporary copy, replace these four bytes with
00 00 00 00. - Calculate CRC32. Compute the standard CRC-32 checksum over exactly
Taille de l'en-têtebytes. - Compare the results. If the calculated value matches the stored value, the header passes its CRC32 integrity check.
For a standard 92-byte GPT header, the calculation covers offsets 0x00–0x5B, not the entire 512-byte logical sector.
A standard CRC-32 calculator or Python’s zlib.crc32() can perform the calculation. The algorithm uses the reflected polynomial 0xEDB88320, an initial register value of 0xFFFFFF, and a final XOR of 0xFFFFFF.
Example: Verifying a GPT Header CRC32
Consider the synthetic GPT header used earlier in this article.
Objet | Valeur |
Taille de l'en-tête |
|
Stored HeaderCRC32 |
|
Stored bytes |
|
CRC field during calculation |
|
Calculated CRC32 |
|
Validation result | Match |
The calculated checksum matches the stored value, indicating that the example header passes its CRC32 check.
If even one covered byte changes without updating the stored checksum, the calculation will generally produce a different result.
Important : Always perform the calculation on a temporary copy or read-only working data. Do not overwrite checksum bytes on the original disk.
0x76EF8C67 in little-endian order. Select Zéro to see how the input is prepared.0xEDB88320 · Init 0xFFFFFF · Final XOR 0xFFFFFF. Teaching sample, not captured disk data.PartitionEntryArrayCRC32: Validating Partition Entries
The second checksum, PartitionEntryArrayCRC32, is stored at header-relative offset 0x58.
Contrairement à CRC32 d'en-tête, it covers the partition entry array rather than the header.
Its calculation length is:
NumberOfPartitionEntries × SizeOfPartitionEntry
For an array containing 128 entries of 128 bytes each:
128 × 128 = 16,384 bytes
To verify this checksum, calculate CRC32 over the entire 16,384-byte array and compare the result with the checksum stored in the GPT header.
No checksum field needs to be zeroed within the partition entry array.
The primary and backup arrays must be checked separately because they occupy different locations. Any unused padding after the array’s final entry is excluded from the calculation.
Why Both Checksums Matter
The two checksums answer different questions:
- HeaderCRC32: Do the header bytes match the checksum stored in the header?
- PartitionEntryArrayCRC32: Do the partition entry bytes match the checksum stored in the header?
A GPT header may pass its own CRC32 check while its partition entry array is corrupted.
Similarly, both checksums may pass even when partition boundaries are logically incorrect or the metadata is outdated.
CRC32 verifies metadata integrity, not disk health or file recoverability. Additional checks are necessary to determine whether partition entries are consistent and the underlying file systems remain accessible.
How to Check Whether a GPT Header Is Valid
UEFI specifies that GPT-aware software must check the header signature, header CRC, MyLBA, and the CRC of the associated partition entry array. For the primary GPT, it must also examine the alternate header.
A practical inspection should include these additional consistency checks:
Vérifier | Expected condition | Pourquoi c'est important |
Signature |
| Identifies the structure |
Header size | At least 92 bytes; no larger than a logical block | Defines the checksum range |
CRC32 d'en-tête | Matches recalculated CRC32 | Detects header-byte changes |
MyLBA | Matches the physical header location | Detects misplaced metadata |
LBA alternatif | Points to the other header | Supports redundant layout validation |
PartitionEntryLBA | Points to an array within disk bounds | Prevents invalid array addressing |
PartitionEntryArrayCRC32 | Matches actual array bytes | Detects entry-array corruption |
Plage LBA utilisable | Ordered, in bounds, and outside metadata regions | Checks layout consistency |
Primary/backup metadata | Consistent where required | Detects conflicting copies |
Passing these checks does not verify individual file systems or files. Partition entry boundaries also need to be checked for validity and overlap.
Les UEFI GPT validation requirements provide the normative basis for deciding whether GPT metadata is valid.
What Happens When a GPT Header Is Corrupted?
The consequences depend on which metadata remains usable.
Primary Header Damaged, Backup Valid
If the primary GPT is invalid, GPT-aware software must examine the header at the last logical block and validate its associated partition entry array.
A valid backup can provide the metadata necessary to reconstruct the primary copy, subject to the platform’s recovery policies.
Such a repair writes partition metadata and should not be attempted casually on a disk containing important, unsecured data.
Backup Header Damaged, Primary Valid
The primary partition layout may still be readable.
However, the backup needs restoration to preserve GPT redundancy.
An apparently accessible disk can therefore still have damaged backup metadata.
Both Headers Invalid
If neither header is valid, the disk has no valid GPT header under the UEFI validation rules.
This does not necessarily mean that every partition or file has been physically erased.
Partition metadata, file system metadata, and file contents occupy different areas of the disk.
When important files are involved, preserve the original disk and distinguish récupération des données de la partition perdue from rewriting the partition table.
Valid Header but Incorrect Partition Information
A structurally valid header is not sufficient to establish that its partition entries describe the current disk correctly.
For example, stale GPT metadata can remain at the end of a disk after legacy partitioning software changes the disk layout.
A valid-looking backup must therefore be evaluated alongside the protective MBR, current disk capacity, partition entries, and other available evidence.
UEFI specifically warns against relying on stale GPT structures after a disk has been reformatted to legacy MBR.
How to Inspect a GPT Header Safely
For detailed analysis, use a disk image or a hexadecimal viewer with read-only access.
- Confirm the correct physical disk and its reported logical block size.
- If the disk has important data, capture a suitable image before modifying any metadata. An unstable or failing disk requires an appropriate acquisition approach.
- Open the image in a hex editor without enabling write operations.
- Locate the primary header at LBA
1, corresponding to byte offsetLogicalBlockSize × 1. - Check the signature at offset
0x00and interpret the other fields using the header-relative offsets. - Determine the last LBA from the image or disk capacity, then inspect the backup header.
- Compare field values, header checksums, and the associated partition entry arrays.
Windows Disk Management and PowerShell’s Get-Disk can identify the disk’s partition style, but their ordinary summary views do not provide a complete byte-level GPT header validation.
Do not initialize, format, or run DiskPart propre merely because a disk reports an invalid or missing partition. Likewise, CHKDSK is a file system repair tool, not a general GPT header reconstruction method.
Limitations and Important Edge Cases
Several conditions affect GPT header interpretation.
Different logical block sizes. A 4Kn disk uses 4,096-byte logical blocks. The primary header remains at LBA 1, but its absolute byte offset differs from that on a 512-byte logical-sector disk.
Larger GPT headers. A header may exceed 92 bytes within the permitted logical block size. CRC32 must use the actual validated Taille de l'en-tête, not an assumed constant.
Disk resizing or cloning. If a disk is enlarged, the old backup header may no longer be at the final LBA. GPT metadata must be evaluated against the current device size before making corrections.
CRC32 is not cryptographic authentication. Matching checksums do not prove that metadata is authentic or free from deliberate manipulation.
Physical media problems. Read errors, intermittent connections, or controller failures can prevent reliable inspection. Repeated attempts on failing hardware may make recovery more difficult.
These limitations explain why GPT validation requires several related checks rather than a single signature or checksum comparison.
Conclusion
Les En-tête GPT provides the location, boundaries, identifiers, and integrity information required to interpret a GUID Partition Table. Its structure is defined by explicit byte offsets, and its primary and backup copies provide redundant metadata at opposite ends of a disk.
Correct analysis requires more than locating PIÈCE EFI. The header CRC32, partition entry array CRC32, LBA pointers, usable boundaries, and primary/backup consistency must be evaluated together.
Understanding these relationships makes it possible to recognize valid GPT metadata, identify inconsistencies, and distinguish partition-table corruption from actual loss of file data.
FAQ
Qu'est-ce que la signature d'en-tête GPT ?
PIÈCE EFI. En hexadécimal, cela donne 45 46 49 20 50 41 52 54. Elle apparaît au début des en-têtes principal et de secours. La simple détection de cette séquence ne suffit pas à garantir la validité de l'ensemble du GPT.Combien d'octets compte un en-tête GPT ?
Taille de l'en-tête Ce champ définit sa longueur réelle, qui doit être d'au moins 92 octets et ne pas dépasser la taille du bloc logique. Les octets restants du bloc logique sont réservés.Où sont stockés les en-têtes GPT principal et de secours ?
1. L'en-tête de sauvegarde est stocké dans le dernier bloc logique du disque. Chaque en-tête MyLBA identifie sa propre position, tandis que LBA alternatif identifie l'autre en-tête.Pourquoi les en-têtes GPT principal et de sauvegarde ont-ils des valeurs CRC32 différentes ?
MyLBA, LBA alternatif, et généralement PartitionEntryLBA. Étant donné que ces octets sont inclus dans le HeaderCRC32, les sommes de contrôle calculées seront généralement différentes, même lorsque les deux en-têtes décrivent exactement le même disque.Un en-tête GPT peut-il passer la validation CRC32 alors que le disque est endommagé ?
Est-il possible de récupérer un en-tête GPT endommagé à partir de la sauvegarde ?
Le GUID d'un disque GPT est-il identique au GUID d'une partition ?
GUID du disque Le champ de l'en-tête GPT identifie le disque. Les entrées de partition individuelles contiennent des identifiants distincts, notamment un GUID de type de partition et un GUID de partition unique. Ces valeurs ont des rôles différents et ne doivent pas être confondues.