Test zur Wiederherstellung nach einer Beschädigung des GPT-Headers
A Test zur Wiederherstellung nach einer Beschädigung des GPT-Headers untersucht, ob sich beschädigte Partitionsmetadaten anhand einer erhaltenen Sicherung rekonstruieren lassen. Im unten aufgeführten Beispiel ist dies möglich – vorausgesetzt, der Sicherungsheader und sein Eintragsarray sind gültig und beschreiben das beabsichtigte Layout. Ein übereinstimmender CRC des Headers allein belegt jedoch nicht, dass die Partitionstabelle verwendbar ist. Dieses Experiment berechnet sieben Metadaten-Zustände, darunter zwei Gegenbeispiele, die die Header-Prüfsumme bestehen. Anschließend wird die primäre GPT aus dem Backup wiederhergestellt und das Ergebnis mit der Baseline verglichen.
Inhaltsübersicht
Forschungsfrage und Untersuchungsrahmen
Die Frage ist konkret: Ermöglichen die erhalten gebliebenen Metadaten nach einer definierten Änderung am Anfang einer GPT-Festplatte die Rekonstruktion des ursprünglichen primären GPT?
Dieser kontrollierte Test auf Byte-Ebene erstellt GPT-Metadaten im Arbeitsspeicher, wendet definierte Änderungen an und überprüft die daraus resultierenden Prüfsummen, Speicherortfelder und die Rekonstruktion anhand einer unveränderten Basisversion.
Der Test überprüft die Integrität der Partitionszuordnung: ob jede GPT-Kopie validiert wird, ob ein erhaltenes Backup die Rekonstruktion unterstützt und ob die wiederhergestellten Metadaten mit der Baseline übereinstimmen. Die Felddefinitionen, die dem Experiment zugrunde liegen, finden Sie im Leitfaden zur GPT-Header-Struktur und zum CRC32.
Referenzkonfiguration und Annahmen
Die Referenzkonfiguration ist ein Beispiel für eine logische Festplatte mit einer Größe von 64 MiB. Durch diesen kompakten Aufbau lassen sich die Adressen leicht nachvollziehen, und die Auswirkungen von Änderungen an den GPT-Headern und Eintragsarrays lassen sich isoliert betrachten.
Parameter | Referenzkonfiguration |
Logische Kapazität | 67.108.864 Byte; 131.072 logische Blöcke |
Logische Blockgröße | 512 Byte |
Partitionsschema | GPT-Revision 1.0; Schutz-MBR |
Größen von Headern und Arrays | 92-Byte-Kopfzeilen; 128 Einträge mit jeweils 128 Byte |
Aktive Partition | Ein Microsoft Basic-Datensatz mit dem Namen LAB-DATA |
Inhalt der Partition | Deterministisches Byte-Muster für Integritätsprüfungen über den gesamten Bereich |
Der Microsoft-Basic-Dateneintrag beschreibt den Partitionsbereich und den Verwendungszweck. Seine Nutzdaten folgen einem deterministischen Byte-Muster, was einen exakten Vergleich vor dem Schaden und nach der Wiederherstellung ermöglicht.
Die erweiterbaren Berechnungshinweise des Vergleichs geben sowohl die Speicherorte der Metadaten als auch die nutzbaren Grenzen und die genaue Ausdehnung der aktiven Partition an. Alle LBAs beziehen sich auf den Anfang dieser logischen Festplatte. Die Leitfaden zur logischen Blockadressierung erklärt, wie man sie in Byte-Offsets umrechnet.
Versuchsablauf
Die Etiketten S0–S6 Identifizieren Sie die sieben generierten Beispielzustände, die in den Ergebnissen und im Szenario-Selektor verwendet werden. Es handelt sich dabei nicht um aufeinanderfolgende Beschädigungsvorgänge auf einer Festplatte. S0 ist die unveränderte Referenz; S1–S5 beginnen jeweils mit einer unabhängigen Kopie von S0. Nur S6 beginnt mit S3.
Alle Änderungen wurden an temporären Kopien vorgenommen. Führen Sie diese Löschvorgänge nicht auf einem Laufwerk durch, das benötigte Daten enthält.
S0 – Ausgangssituation: Beide GPT-Kopien sind intakt.
Erstellen Sie den Schutz-MBR, die primären und Backup-Header sowie identische Eintrags-Arrays. Überprüfen Sie die Prüfsummen, die Speicherortfelder, die Array-Dimensionen und die Partitionsgrenzen. Behalten Sie diesen unveränderten Zustand als Referenz für jeden Vergleich bei.
S1 – Primäres Header-Byte beschädigt.
Ändere den ersten Eintrag der Hauptüberschrift DiskGUID Byte am header-relativen Offset +0x38 von 33 zu 32. Lassen Sie den gespeicherten CRC-Wert des Headers unverändert. Behalten Sie sowohl die Arrays als auch den Backup-Header und den Inhalt der Partition unverändert bei. Dadurch lässt sich eine Diskrepanz zwischen Header und CRC isolieren.
S2 – Primäre Überschrift fehlt.
Ersetzen Sie den 512-Byte-Block an LBA 1 durch Nullen. Behalten Sie das primäre Array und die vollständige GPT-Sicherung bei. Prüfen Sie, ob die erhaltene Sicherung eine gültige Quelle für die Rekonstruktion darstellt, wenn der primäre Header keine erkennbare Signatur aufweist.
S3 – Primäres Eingabe-Array beschädigt.
Ändere in Eintrag 0 des primären Arrays bei LBA 2 das Namensbyte am eintragsrelativen Offset +0x38 von 4C zu 4D, wobei L in M geändert wird. Beide Header bleiben unverändert. Dadurch wird eine Diskrepanz zwischen Array und CRC isoliert, während der CRC des primären Headers weiterhin gültig ist.
S4 – Beide Kopfzeilen fehlen.
Ersetzen Sie die primären und sekundären Header-Blöcke an LBA 1 und LBA 131071 durch Nullen. Behalten Sie dabei sowohl die Eintrags-Arrays als auch den Inhalt der Partitionen bei. Damit wird die Grenze der Rekonstruktion getestet, wenn kein gültiger Header erhalten geblieben ist.
S5 – Backup-Header ohne Anpassung kopiert.
Kopieren Sie den Backup-Header-Block wortwörtlich an LBA 1. Ändern Sie weder die Positionsfelder noch die Prüfsumme. Damit wird überprüft, ob ein gültiger Header-CRC mit fehlerhaften Adressen auf der Primärseite koexistieren kann.
S6 – Primäre GPT, neu erstellt aus S3.
Beginnen Sie mit dem in S3 definierten Array-Schaden. Stellen Sie das primäre Array anhand seiner verifizierten Sicherung wieder her, passen Sie die Speicherortfelder des Sicherungs-Headers an die Primärseite an und berechnen Sie den CRC-Wert des Headers neu. Vergleichen Sie die rekonstruierten Metadaten Byte für Byte mit S0.
Überprüfen Sie für jeden Zustand den CRC des Headers, den CRC des Arrays und die Speicherortbeziehungen separat. Ein fehlender Header macht die zugehörigen Prüfungen unzugänglich; ein übereinstimmender CRC allein reicht nicht aus, um eine gültige GPT nachzuweisen. Vergleichen Sie den gesamten Bereich des Partitionsinhalts, einschließlich seines SHA-256-Werts, separat mit S0. Die Bedingung für das Bestehen ist ein konsistentes GPT-Layout, bei dem der Bereich des Partitionsinhalts erhalten bleibt.
Testergebnisse zur Wiederherstellung nach einer Beschädigung des GPT-Headers
Bei den drei unten dargestellten Ansichten bleibt derselbe Kopfbereich auf dem Bildschirm sichtbar. Folgen Sie dem umrandeten Byte in Zeile +0030, Spalte 08—Header-Offset +0x38—und vergleichen Sie die gespeicherten und berechneten CRC-Werte des Headers. Die Ansichten zeigen dieselben Beispielbytes an, die bei den Prüfsummen- und Rekonstruktionsprüfungen verwendet wurden.
Erster GPT-Integritätstest: vor dem Schaden
Der primäre Header der Basisversion enthält 33 unter DiskGUID +0x38. Die gespeicherten und berechneten CRC-Werte der Header stimmen überein. Das Primär-Array und die GPT-Sicherung werden ebenfalls validiert.
Hexadezimaler Vergleich des GPT-Headers: nach der Änderung eines Bytes
S1 ändert nur dieses Byte von 33 zu 32. Der gespeicherte CRC des Headers bleibt unverändert, der berechnete CRC weicht jedoch davon ab. Der rote Rahmen kennzeichnet das geänderte Byte, während die schattierten Prüfsummenbytes den Wert anzeigen, der nicht aktualisiert wurde. Die gültige Sicherungskopie bleibt in diesem definierten Layout eine mögliche Quelle für die Rekonstruktion.
Experiment zur Wiederherstellung des GPT-Headers aus einem Backup: nach der Rekonstruktion
Bei der Rekonstruktion wird der verifizierte Backup-Header für den Primärstandort angepasst und dessen Prüfsumme neu berechnet. Das markierte Byte kehrt zurück zu 33; die gespeicherten und berechneten CRC-Werte stimmen wieder überein. Ein vollständiger Byte-Vergleich bestätigt, dass die wiederhergestellten primären Metadaten mit der Basislinie übereinstimmen. Dieser berechnete Übergang von S1 zur Basislinie ist unabhängig von S6, das den darunter liegenden Array-Schaden behebt.
Schäden am Array: Warum ein erfolgreicher CRC-Check beim Header nicht ausreicht
S3 ändert das erste Zeichen des Partitionsnamens im Eintragsarray von „L“ in „M“. Die Header-Bytes bleiben unverändert, sodass deren CRC-Prüfsumme erfolgreich ist, während die CRC-Prüfsumme des Arrays fehlschlägt. S6 stellt das Backup-Array wieder her und baut den primären Header neu auf, wodurch die ursprünglichen Metadaten wieder auf den Ausgangszustand zurückgesetzt werden.
Die Anleitung zum GPT-Partitionseintrags-Array erklärt, warum der Name zum Array und nicht zum Header gehört.
Fehlerzustände, die die Interpretation verändern
Die komprimierte Szenariotabelle behält die verbleibenden Prüfwerte bei. Da der primäre Header fehlt (S2), ermöglicht das intakte Backup weiterhin eine Rekonstruktion. Fehlen beide Header (S4), bleibt kein gültiger Header als Quelle für die Rekonstruktion übrig, obwohl die definierten Arrays erhalten bleiben. Schließlich bewahrt das wortgetreue Kopieren des Backup-Headers auf LBA 1 (S5) zwar dessen gültigen CRC, hinterlässt jedoch fehlerhafte Felder für den primären Speicherort.
Diese Ergebnisse unterscheiden eine übereinstimmende Prüfsumme von einer konsistenten Partitionszuordnung. Für eine gültige Rekonstruktion müssen die Prüfsummen und die Positionsbeziehungen mit dem beabsichtigten Layout übereinstimmen.
Verwenden Sie den unten stehenden Szenario-Explorer, um alle sieben Zustände in Hex zu vergleichen. Beginnen Sie mit S0 und wechseln Sie dann zwischen S1 und S6, um den Primärheader und den Ausschnitt aus dem Eintragsarray sowie die CRC- und Positionsprüfungen zu überprüfen. Rot markiert Bytes, die sich von S0 unterscheiden; grün markiert in S6 rekonstruierte Felder, die mit der Basislinie übereinstimmen.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| Szenario | Header-CRC | Array-CRC | Standort | GPT-Sicherung | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · Ausgangswert | PASS | PASS | PASS | GÜLTIG | Both GPT copies validate. |
| S1 · Bitumkehr im Header | FEHLER | PASS | PASS | GÜLTIG | Backup header and array remain usable for reconstruction. |
| S2 · Primäre Überschrift fehlt | Unavailable | Unavailable | Unavailable | GÜLTIG | Backup header and array remain usable for reconstruction. |
| S3 · Primäres Array beschädigt | PASS | FEHLER | PASS | GÜLTIG | Der CRC des primären Headers ist korrekt, der des Arrays jedoch nicht; die Sicherungskopie bleibt gültig. |
| S4 · Beide Kopfzeilen fehlen | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · Blindkopie | PASS | PASS | FEHLER | GÜLTIG | CRC passes, but MyLBA and primary array placement fail. |
| S6 · Überholtes Primärgetriebe | PASS | PASS | PASS | GÜLTIG | 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 Kopfzeilengröße bytes with HeaderCRC32 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.
Schlussfolgerung
Diese Test zur Wiederherstellung nach einer Beschädigung des GPT-Headers 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
Wie kann ich überprüfen, ob ein GPT-Header beschädigt ist?
Kann ein beschädigter GPT-Header anhand der Sicherungskopie repariert werden?
Werden in der GPT-Sicherung auch gelöschte Partitionen beibehalten?
Kann die GPT-Header-Wiederherstellung Dateien ohne Datenverlust wiederherstellen?
Was passiert, wenn sowohl der primäre als auch der Backup-GPT-Header beschädigt sind?
Wie kann ich die Wiederherstellung des GPT-Headers sicher testen?
Kann ein Windows-Startfehler durch die Reparatur eines GPT-Headers behoben werden?
