GPT-Header: Struktur, Sicherung und CRC32
A GPT-Kopfzeile ist eine Metadatenstruktur, die die GUID-Partitionstabelle (GPT) einer Festplatte beschreibt. Sie identifiziert die Festplatte, lokalisiert das Partitionseintrags-Array, definiert die nutzbaren Festplattengrenzen und speichert Prüfsummen, mit denen eine Beschädigung der Metadaten erkannt werden kann. Die GPT verwaltet aus Redundanzgründen einen primären und einen Backup-Header. Das Verständnis ihres Byte-Layouts und ihrer CRC32-Felder hilft zu erklären, wie Partitionsinformationen validiert werden und warum ein beschädigter Header nicht zwangsläufig bedeutet, dass die zugrunde liegenden Dateien verloren sind.
Inhaltsübersicht
Was ist ein GPT-Header?
Der GPT-Header ist Teil der GUID Partition Table (GPT), dem in der UEFI-Spezifikation definierten Schema zur Festplattenpartitionierung.
Im Gegensatz zum älteren Master-Boot-Record-Schema (MBR) verwaltet GPT zwei Kopien seiner Partitionsmetadaten: eine am Anfang der Festplatte und eine weitere am Ende.
Jeder GPT-Header enthält Informationen, die zum Auffinden und Interpretieren des zugehörigen Partitionseintrags-Arrays erforderlich sind, darunter:
- Eine Signatur, die das GPT-Format kennzeichnet.
- Die Version und Größe des GPT-Headers.
- Die Position der Hauptüberschrift und die Position der alternativen Überschrift.
- Die erste und letzte nutzbare logische Blockadresse.
- Eine eindeutige Festplatten-ID.
- Die Position und die Abmessungen des Arrays mit den Partitionseinträgen.
- CRC32-Prüfsummen zur Sicherstellung der Integrität der Metadaten.
Der GPT-Header speichert keine Dateinamen, Ordnerstrukturen oder Dateiinhalte direkt. Diese gehören zu den Dateisystemen innerhalb der Partitionen.
Einen Überblick über das Partitionierungsschema finden Sie unter GPT (GUID-Partitionstabelle). Die offiziellen Definitionen finden sich in der UEFI-Spezifikation, Abschnitt 5.3.
Wo befindet sich der GPT-Header?
GPT speichert seine primären und sekundären Metadaten an den gegenüberliegenden Enden einer Festplatte.
Bei einer herkömmlichen GPT-Festplatte:
Standort | Inhaltsverzeichnis |
LBA 0 | Schutz-MBR |
LBA 1 | Primäre GPT-Kopfzeile |
Befolgung der LBAs | Array der primären Partitionseinträge |
Verfügbarer LBA-Bereich | Verfügbarer Platz für Trennwände |
LBAs vor dem letzten Block | Array der Backup-Partitions-Einträge |
Letzte LBA | GPT-Header sichern |
Der Schutz-MBR verhindert, dass ältere, ausschließlich auf den MBR ausgerichtete Tools die GPT-Festplatte als nicht zugewiesen behandeln.
Er unterscheidet sich vom GPT-Header selbst. Einen Vergleich mit herkömmlichen Partitionsmetadaten finden Sie unter MBR-Partitionstabelle.
Logische Sektoren und Byte-Adressen
GPT verwendet logische Blockadressen (LBAs) und keine absoluten Byte-Offsets, um seine Strukturen zu identifizieren.
So wandeln Sie einen LBA in einen Byte-Offset um:
Byte-Offset = LBA × logische Blockgröße
Zum Beispiel:
- Auf einer Festplatte mit logischen Blöcken von 512 Byte beginnt der Primär-Header beim Byte-Offset
512(0x200). - Auf einer Festplatte mit logischen Blöcken von 4.096 Byte beginnt der Primärheader beim Byte-Offset
4096(0x1000).
Der Header nimmt in der Regel 92 Byte innerhalb eines logischen Blocks ein, obwohl das Format größere Header bis zur Größe des logischen Blocks zulässt.
Ein 92-Byte-Header darf nicht mit einem 512-Byte-Sektor verwechselt werden. Die übrigen Bytes eines 512-Byte-Header-Blocks sind reserviert und müssen den Wert Null haben.
Struktur des GPT-Headers: Felder, Offsets und Größen
Die GPT-Header-Struktur ist definiert in UEFI-Spezifikation 2.10, Tabelle 5.5.
Die folgenden Offsets beziehen sich auf den Anfang des GPT-Headers, nicht auf den Anfang der Festplatte.
Feld | Offset (Hex) | Größe | Zweck |
Unterschrift |
| 8 Bytes | Identifiziert den GPT-Header |
Überarbeitung |
| 4 Bytes | Überarbeitung des GPT-Formats |
Kopfzeilengröße |
| 4 Bytes | Header-Länge in Byte |
HeaderCRC32 |
| 4 Bytes | Prüfsumme des Headers |
Reserviert |
| 4 Bytes | Muss Null sein |
MyLBA |
| 8 Bytes | Position dieser Kopfzeile |
AlternateLBA |
| 8 Bytes | Position der anderen Kopfzeile |
Erste nutzbare LBA |
| 8 Bytes | Erster nutzbarer Partitionsblock |
LastUsableLBA |
| 8 Bytes | Letzter nutzbarer Partitionsblock |
DiskGUID |
| 16 Byte | Eindeutige Festplatten-Kennung |
PartitionEntryLBA |
| 8 Bytes | Anfang des zugehörigen Eintrags-Arrays |
Anzahl der Partitionseinträge |
| 4 Bytes | Anzahl der Startplätze |
Größe des Partitions-Eintrags |
| 4 Bytes | Umfang der einzelnen Einträge |
PartitionEntryArrayCRC32 |
| 4 Bytes | Prüfsumme des Eintrags-Arrays |
Die definierten Felder belegen Offsets 0x00 durch 0x5B, insgesamt 92 Byte. Byte aus 0x5C bis zum Ende des logischen Blocks sind reserviert.
Unterschrift und Überarbeitung
Ein gültiger GPT-Header beginnt mit der ASCII-Signatur EFI-TEIL.
Die acht Bytes lauten:
45 46 49 20 50 41 52 54
Der GPT-Standard, Revision 1.0, wird durch die folgenden Bytes im Little-Endian-Format dargestellt:
00 00 01 00
Diese stellen den numerischen Wert dar 0x00010000. Die Revisionsnummer des GPT-Headers entspricht nicht der Versionsnummer der UEFI-Spezifikation.
Die üblicherweise verwendete Header-Größe beträgt 92 Byte und wird wie folgt kodiert:
5C 00 00 00
Festplatten-GUID und Byte-Reihenfolge
Das Feld „DiskGUID“ belegt 16 Byte, beginnend bei Offset 0x38.
Sie identifiziert die GPT-Festplatte. Sie unterscheidet sich von der eindeutigen Partitions-GUID, die in jedem einzelnen Partitionseintrag gespeichert ist.
Ein GUID bringt zudem ein wichtiges Detail bei der Interpretation von rohen Hexadezimal-Daten mit sich: Die ersten drei Komponenten verwenden die Little-Endian-Byte-Reihenfolge, während die letzten acht Bytes ihre angezeigte Reihenfolge beibehalten.
Beispielsweise die folgende GUID:
f0e1d2c3-b4a5-4c6d-8e9f-102030405060
wird wie folgt gespeichert:
C3 D2 E1 F0 A5 B4 6D 4C 8E 9F 10 20 30 40 50 60
Würde man alle 16 Rohdaten-Bytes direkt von links nach rechts lesen, würde dies zu einer falschen textuellen GUID führen.
Felder des Partitions-Eintrags-Arrays
Das Array der Partitionseinträge wird durch drei Felder definiert:
PartitionEntryLBAGibt an, wo das Array beginnt.Anzahl der Partitionseinträgelegt die Anzahl der Einträge fest.Größe des Partitions-Eintragslegt die Größe jedes Eintrags fest.
Die Byte-Länge des Arrays wird wie folgt berechnet:
Array-Größe = Anzahl der Einträge × Eintragsgröße
Für ein Array mit 128 Elementen à 128 Byte:
128 × 128 = 16.384 Byte
Bei logischen Blöcken von 512 Byte:
16.384 ÷ 512 = 32 logische Blöcke
Dies ist der reservierte Speicherplatz des Partitionseintrags-Arrays, nicht der Speicherplatz, der von den eigentlichen Dateidaten belegt wird.
Die aktuelle UEFI-Spezifikation definiert die Eintragsgröße wie folgt: 128 × 2^n Bytes, wobei n ist eine nicht-negative ganze Zahl. Typische GPT-Festplatten verwenden Einträge mit einer Größe von 128 Byte.
Primäre und Backup-GPT-Header: Was ändert sich?
Der primäre und der Backup-GPT-Header weisen zwar dieselbe Feldstruktur auf, enthalten jedoch nicht identische Bytes.
Ihre Speicherorte und einige interne Verweise unterscheiden sich.
Betrachten wir eine beispielhafte GPT-Festplatte mit folgenden Eigenschaften:
- 100.000 logische Blöcke, nummeriert
0durch99,999. - Eine logische Blockgröße von 512 Byte.
- Ein Eintragsarray mit 128 Einträgen zu je 128 Byte.
- An jedem Ende ein Array mit 32 Blockpartitionseinträgen.
Der Aufbau ist wie folgt:
Struktur | Primäre GPT | GPT-Sicherung |
Header-LBA |
|
|
MyLBA |
|
|
AlternateLBA |
|
|
PartitionEntryLBA |
|
|
Umfang des Eintrags-Arrays |
|
|
Erste nutzbare LBA |
|
|
LastUsableLBA |
|
|
Kopfzeilengröße | 92 Byte | 92 Byte |
Diese Positionen ergeben sich direkt aus der Festplattengröße und den beiden Partitionseintrags-Arrays mit jeweils 32 Blöcken.
Zum Beispiel:
Start des Backup-Arrays = Letzte LBA − Array-Blöcke
99.999 − 32 = 99.967
Der letzte nutzbare Block muss diesem Backup-Array vorangehen:
99.967 − 1 = 99.966
Beide Header beschreiben daher denselben nutzbaren Festplattenbereich, verweisen jedoch auf unterschiedliche physische Speicherorte für ihre Partitionseintrags-Arrays.
Diese Vorgehensweise ermöglicht es GPT-kompatibler Software, die Metadaten der Sicherungskopie zu überprüfen, wenn die Primärkopie beschädigt ist.
Das Vorhandensein von zwei Kopien garantiert jedoch nicht, dass eine der beiden Kopien gültig oder aktuell ist.
Beispiel: Dekodierung des GPT-Headers aus hexadezimalen Bytes
Im folgenden Beispiel werden bewusst konstruierte GPT-Metadaten verwendet, keine von einer physischen Festplatte erfassten Bytes.
Es beschreibt dieselbe Festplatte mit 100.000 Blöcken, die oben verwendet wurde.
Das Beispiel enthält keine gefüllten Partitionen. Alle 128 Einträge für Partitionen sind mit Nullen gefüllt, sodass beide Prüfsummen des Eintragsarrays anhand einer vollständig definierten Eingabe berechnet werden können.
Schritt 1: Identifizieren Sie die Kopfzeile
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 |
|
|
|
|
| Überarbeitung |
|
| 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:
Feld | Stored bytes | Decoded value |
MyLBA |
|
|
AlternateLBA |
|
|
Erste nutzbare LBA |
|
|
LastUsableLBA |
|
|
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 und AlternateLBA and changes PartitionEntryLBA zu 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:
Prüfsumme | Primäre GPT | GPT-Sicherung |
HeaderCRC32 |
|
|
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:
HeaderCRC32verifies 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
Die HeaderCRC32 field occupies four bytes at header-relative offset 0x10.
Laut der 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
Kopfzeilengrößefield 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
Kopfzeilengrößebytes. - 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 0xFFFFFFFF, and a final XOR of 0xFFFFFFFF.
Example: Verifying a GPT Header CRC32
Consider the synthetic GPT header used earlier in this article.
Artikel | Wert |
Kopfzeilengröße |
|
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.
Das ist wichtig: 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 Null to see how the input is prepared.0xEDB88320 · Init 0xFFFFFFFF · Final XOR 0xFFFFFFFF. Teaching sample, not captured disk data.PartitionEntryArrayCRC32: Validating Partition Entries
The second checksum, PartitionEntryArrayCRC32, is stored at header-relative offset 0x58.
Anders als HeaderCRC32, 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 Byte
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:
Siehe | Expected condition | Warum das wichtig ist |
Unterschrift |
| Identifies the structure |
Kopfzeilengröße | At least 92 bytes; no larger than a logical block | Defines the checksum range |
HeaderCRC32 | Matches recalculated CRC32 | Detects header-byte changes |
MyLBA | Matches the physical header location | Detects misplaced metadata |
AlternateLBA | 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 |
Verfügbarer LBA-Bereich | 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.
Die 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 Wiederherstellung verlorener Partitionsdaten 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 sauber 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 Kopfzeilengröße, 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.
Schlussfolgerung
Die GPT-Kopfzeile 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 EFI-TEIL. 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.
Häufig gestellte Fragen
Was ist die GPT-Header-Signatur?
EFI-TEIL. In Hexadezimal lautet dies 45 46 49 20 50 41 52 54. Sie erscheint sowohl am Anfang des primären als auch des Backup-Headers. Das bloße Auffinden dieser Sequenz reicht nicht aus, um die Gültigkeit der gesamten GPT zu bestätigen.Wie viele Byte umfasst ein GPT-Header?
Kopfzeilengröße Das Feld legt seine tatsächliche Länge fest, die mindestens 92 Byte und höchstens die logische Blockgröße betragen darf. Die verbleibenden Byte des logischen Blocks sind reserviert.Wo werden der primäre und der Backup-GPT-Header gespeichert?
1. Der Backup-Header wird im letzten logischen Block der Festplatte gespeichert. Jeder Header enthält MyLBA ermittelt seinen eigenen Standort, während AlternateLBA identifiziert den anderen Header.Warum weisen der primäre und der Backup-GPT-Header unterschiedliche CRC32-Werte auf?
MyLBA, AlternateLBA, und in der Regel PartitionEntryLBA. Da diese Bytes vom HeaderCRC32 abgedeckt werden, weichen die berechneten Prüfsummen in der Regel voneinander ab, selbst wenn beide Header genau dieselbe Festplatte beschreiben.Kann ein GPT-Header die CRC32-Prüfung bestehen, wenn die Festplatte beschädigt ist?
Kann ein beschädigter GPT-Header aus dem Backup wiederhergestellt werden?
Ist die GPT-Datenträger-GUID dasselbe wie eine Partitions-GUID?
DiskGUID Das Feld im GPT-Header identifiziert die Festplatte. Die einzelnen Partitionseinträge enthalten separate Kennungen, darunter eine GUID für den Partitionstyp und eine eindeutige Partitions-GUID. Diese Werte haben unterschiedliche Funktionen und sollten nicht verwechselt werden.