Test de récupération après endommagement de l'en-tête GPT
A Test de récupération après endommagement de l'en-tête GPT se demande si une sauvegarde intacte permet de reconstituer les métadonnées d’une partition endommagée. Dans l’exemple généré ci-dessous, c’est possible — à condition que l’en-tête de la sauvegarde et son tableau d’entrées soient valides et décrivent la structure prévue. Cependant, un CRC d’en-tête correspondant ne suffit pas à lui seul à garantir que la table de partition est utilisable. Cette expérience calcule sept états de métadonnées, dont deux contre-exemples qui satisfont à la somme de contrôle de l’en-tête. Elle reconstruit ensuite la GPT principale à partir de la sauvegarde et compare le résultat à la référence.
Table des matières
Problématique et portée de la recherche
La question est précise : après une modification bien définie survenue près du début d'un disque GPT, les métadonnées restantes permettent-elles de reconstituer le GPT primaire d'origine ?
Ce test contrôlé, au niveau des octets, construit les métadonnées GPT en mémoire, applique les modifications définies, puis valide les sommes de contrôle, les champs d'emplacement et la reconstruction obtenus par rapport à une référence inchangée.
Le test évalue l'intégrité de la carte de partition : il vérifie si chaque copie GPT est valide, si une sauvegarde intacte permet la reconstruction et si les métadonnées reconstruites correspondent à la référence. Pour les définitions des champs utilisées dans le cadre de l'expérience, voir le Guide sur la structure de l'en-tête GPT et le CRC32.
Configuration de référence et hypothèses
La configuration de référence est un exemple de disque logique de 64 Mio. Cette structure compacte permet de suivre facilement les adresses et d'isoler les effets des modifications apportées aux en-têtes GPT et aux tableaux d'entrées.
Paramètres | Configuration de référence |
Capacité logique | 67 108 864 octets ; 131 072 blocs logiques |
Taille de bloc logique | 512 octets |
Schéma de partitionnement | GPT version 1.0 ; MBR de protection |
Tailles des en-têtes et des tableaux | En-têtes de 92 octets ; 128 entrées de 128 octets chacune |
Partition active | Une entrée de données Microsoft Basic nommée LAB-DATA |
Contenu de la partition | Séquence d'octets déterministe pour les contrôles d'intégrité sur l'ensemble de la plage |
L'entrée « Microsoft Basic Data » décrit la plage de partition et l'utilisation prévue. Sa charge utile suit un modèle d'octets déterministe, ce qui permet une comparaison exacte avant la détérioration et après la reconstruction.
Les notes de calcul extensibles de la comparaison indiquent à la fois les emplacements des métadonnées, les limites exploitables et l'étendue exacte de la partition active. Tous les LBA sont exprimés par rapport au début de ce disque logique. Le Guide sur l'adressage par blocs logiques explique comment les convertir en décalages en octets.
Déroulement de l'expérience
Les étiquettes S0–S6 Identifiez les sept états d'échantillon générés utilisés dans les résultats et dans le sélecteur de scénario. Il ne s'agit pas d'opérations de détérioration consécutives sur un même disque. S0 correspond à la référence inchangée ; S1 à S5 partent chacun d'une copie indépendante de S0. Seul S6 part de S3.
Toutes les modifications ont été effectuées sur des copies jetables. N'effectuez pas ces opérations pouvant endommager les données sur un disque contenant des données dont vous avez besoin.
S0 — Situation de référence : les deux copies du GPT sont intactes.
Créez le MBR de protection, les en-têtes principal et de sauvegarde, ainsi que des tableaux d'entrées identiques. Vérifiez les sommes de contrôle, les champs d'emplacement, les dimensions des tableaux et les limites des partitions. Conservez cet état inchangé comme référence pour chaque comparaison.
S1 — Octet d'en-tête principal endommagé.
Modifier le premier élément de l'en-tête principal GUID du disque octet à l'offset par rapport à l'en-tête +0x38 de 33 à 32. Ne modifiez pas le CRC de l'en-tête enregistré. Ne modifiez ni les deux tableaux, ni l'en-tête de sauvegarde, ni le contenu de la partition. Cela permet d'identifier une divergence entre l'en-tête et le CRC.
S2 — En-tête principal manquant.
Remplacer le bloc de 512 octets situé à l'adresse LBA 1 par des zéros. Conserver la matrice principale et la table GPT de sauvegarde dans son intégralité. Vérifier si la sauvegarde restante constitue une source de reconstruction valide lorsque l'en-tête principal ne comporte aucune signature identifiable.
S3 — Matrice d'entrée principale endommagée.
Dans l'entrée 0 du tableau principal à l'adresse LBA 2, modifiez l'octet de nom à l'offset relatif à l'entrée +0x38 de 4C à 4D, en remplaçant L par M. Ne modifiez aucun des deux en-têtes. Cela permet d'identifier une divergence entre le CRC du tableau et celui de l'en-tête, alors que le CRC de l'en-tête principal reste valide.
S4 — Les deux en-têtes manquent.
Remplacez les blocs d'en-tête principal et de secours, situés respectivement aux adresses LBA 1 et LBA 131071, par des zéros. Conservez les deux tableaux d'entrées ainsi que le contenu des partitions. Ce test permet d'évaluer les limites de la reconstruction lorsque aucun en-tête valide n'est conservé.
S5 — En-tête de sauvegarde copié tel quel, sans adaptation.
Copiez le bloc d'en-tête de sauvegarde tel quel à l'adresse LBA 1. Ne modifiez ni ses champs d'emplacement ni sa somme de contrôle. Cela permet de vérifier si un CRC d'en-tête valide peut coexister avec des adresses incorrectes du côté primaire.
S6 — GPT principal reconstruit à partir de S3.
Commencez par les dommages subis par la matrice définis dans S3. Restaurez la matrice principale à partir de sa sauvegarde vérifiée, adaptez les champs d'emplacement de l'en-tête de sauvegarde pour le côté principal, puis recalculez le CRC de son en-tête. Comparez les métadonnées reconstruites octet par octet avec celles de S0.
Pour chaque état, vérifiez séparément le CRC de l'en-tête, le CRC du tableau et les relations d'emplacement. L'absence d'en-tête rend les vérifications associées indisponibles ; un CRC correspondant ne suffit pas à lui seul à établir la validité d'un GPT. Comparez séparément l'intégralité de la plage de contenu de la partition, y compris son SHA-256, avec S0. La condition de réussite est une structure GPT cohérente avec la plage de contenu de la partition préservée.
Résultats des tests de récupération après endommagement de l'en-tête GPT
The three rendered views below keep the same header region on screen. Follow the outlined byte at row +0030, column 08—header offset +0x38—and compare the stored and calculated header CRCs. The views render the same sample bytes used in the checksum and reconstruction checks.
Primary GPT corruption test: before damage
The baseline primary header contains 33 à DiskGUID +0x38. Its stored and calculated header CRCs match. The primary array and the backup GPT also validate.
GPT header hex comparison: after one byte changes
S1 changes only that byte from 33 à 32. The stored header CRC remains unchanged, but the calculated CRC differs. The red outline identifies the changed byte, while the shaded checksum bytes show the value that was not updated. The valid backup remains a possible reconstruction source in this defined layout.
Backup GPT header recovery experiment: after reconstruction
The reconstruction adapts the verified backup header for the primary location and recalculates its checksum. The outlined byte returns to 33; the stored and calculated CRCs match again. A full byte comparison confirms that the rebuilt primary metadata equals the baseline. This calculated S1-to-baseline transition is separate from S6, which repairs the array damage below.
Array damage: why a passing header CRC is not enough
S3 changes the first partition-name character from L to M in the entry array. The header bytes remain unchanged, so its CRC passes while the array CRC fails. S6 restores the backup array and rebuilds the primary header, returning the original metadata to the baseline.
Les GPT partition entry array guide explains why the name belongs to the array rather than the header.
Failure conditions that change the interpretation
The collapsed scenario table retains the remaining checks. With the primary header missing (S2), the intact backup still supports reconstruction. With both headers missing (S4), no valid header remains as a reconstruction source, even though the defined arrays survive. Finally, copying the backup header verbatim to LBA 1 (S5) preserves its valid CRC but leaves incorrect primary location fields.
These outcomes distinguish a matching checksum from a consistent partition map. A valid reconstruction requires checksums and location relationships to agree with the intended layout.
Use the scenario explorer below to compare all seven states in Hex. Start with S0, then switch between S1–S6 to inspect the primary header and the entry-array excerpt alongside the CRC and location checks. Red marks bytes that differ from S0; green in S6 marks reconstructed fields that match the baseline.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| Scénario | Header CRC | Array CRC | Localisation | Backup GPT | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · Baseline | PASS | PASS | PASS | VALID | Both GPT copies validate. |
| S1 · Header bit flip | FAIL | PASS | PASS | VALID | Backup header and array remain usable for reconstruction. |
| S2 · Primary header missing | Unavailable | Unavailable | Unavailable | VALID | Backup header and array remain usable for reconstruction. |
| S3 · Primary array damaged | PASS | FAIL | PASS | VALID | Primary header CRC passes, but its array CRC fails; backup remains valid. |
| S4 · Both headers missing | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · Blind backup copy | PASS | PASS | FAIL | VALID | CRC passes, but MyLBA and primary array placement fail. |
| S6 · Rebuilt primary | PASS | PASS | PASS | VALID | Primary GPT equals the baseline; both copies validate. |
Header CRC: 92 bytes with +0x10–+0x13 zeroed. Array CRC: 128 × 128 = 16,384 bytes. Location checks validate MyLBA and primary-array placement. Missing headers make these checks unavailable.
Generated 64 MiB sample · 512-byte blocks · header and entry bytes switch with the scenario; checks are precomputed.
Why the Results Follow from the Mechanism
UEFI 2.11, Section 5.3.2 defines separate header and entry-array checks. The header CRC covers Taille de l'en-tête bytes with CRC32 d'en-tête temporarily zeroed. The array CRC covers NumberOfPartitionEntries × SizeOfPartitionEntry bytes. Location checks add information that neither checksum supplies.
In this sample, S1 changes a header-CRC input. S3 changes an array-CRC input. S5 preserves the header-CRC input but violates the primary location requirements. These controlled differences explain the three distinct validation outcomes shown in the explorer.
The sample also explains why the primary and backup header checksums differ at baseline: their location-dependent fields differ. Identical arrays can share a checksum while their associated headers do not.
Practical Interpretation and Limitations
On a real disk, first preserve the source and identify the correct device by model or serial number, capacity, and logical block size. Perform any proposed metadata writes on a disposable working copy. A USB bridge, a resized image, or a truncated acquisition can change the address context; do not substitute this sample’s last LBA for the actual device boundary.
Next, establish whether a surviving backup describes the intended current layout. A correct CRC detects certain byte changes; it does not prove freshness or authenticity. UEFI specifically warns about stale backup GPT metadata after a disk has been reformatted for legacy MBR use. Conflicting copies require investigation before either is accepted as authoritative.
Microsoft’s Windows and GPT FAQ provides background on GPT redundancy and CRC protection. Recovery behavior depends on the operating system, the tool, and platform policy. Confirm which GPT copy a tool accepts and which metadata ranges it proposes to change before approving a repair.
After metadata reconstruction, confirm the expected partition boundaries, inspect the file system without modifying the source, and verify representative files against known copies where available. For a system disk, follow this with a boot check on the intended target. These checks establish file accessibility and startup readiness after the partition map has been validated.
When File Recovery Comes Before GPT Repair
When a partition disappears or its volume becomes inaccessible, securing important files may take priority over writing changes to the GPT. Magic Data Recovery’s lost-partition workflow can scan for recoverable files, preview supported file types, and save selected data to another drive. After recovering the files you need, assess the partition layout and plan any metadata repair on a working copy. Keep file recovery and GPT reconstruction as separate tasks, with separate checks for recovered files and partition-table integrity.
Conclusion
Le présent Test de récupération après endommagement de l'en-tête GPT demonstrates how a valid backup can support reconstruction after primary-header corruption or loss. In the tested sample, restoring the entry array and adapting the header’s location fields returned the primary GPT to its baseline bytes. The decisive condition is that the surviving backup header and its associated array both validate and describe the intended partition layout.
The comparisons also show why a passing header CRC32 is insufficient: entry-array damage can leave the header checksum unchanged, while an unmodified backup header can retain a valid checksum at the wrong location. Reliable GPT recovery therefore requires agreement between header checksums, array checksums, and location fields. After reconstruction, verify partition boundaries, file-system access, and important files separately; system disks also need a boot check. A restored partition map establishes metadata consistency, while these additional checks determine whether the disk is usable again.
FAQ About GPT Header Damage and Recovery
Comment vérifier si un en-tête GPT est endommagé ?
Est-il possible de réparer un en-tête GPT endommagé à partir d'une sauvegarde ?
La sauvegarde GPT conserve-t-elle les partitions qui ont été supprimées ?
La récupération de l'en-tête GPT permet-elle de restaurer des fichiers sans perte de données ?
Que se passe-t-il si les en-têtes GPT principal et de secours sont tous deux endommagés ?
Comment puis-je tester la récupération de l'en-tête GPT en toute sécurité ?
La réparation d'un en-tête GPT permet-elle de résoudre un problème de démarrage sous Windows ?
