Cabeçalho GPT: Estrutura, Cópia de Segurança e CRC32
A Cabeçalho GPT é uma estrutura de metadados que descreve a Tabela de Partições GUID (GUID Partition Table) de um disco. Ela identifica o disco, localiza a matriz de entradas de partição, define os limites utilizáveis do disco e armazena somas de verificação utilizadas para detectar corrupção nos metadados. A GPT mantém cabeçalhos primários e de backup para fins de redundância. Compreender seu layout de bytes e os campos CRC32 ajuda a explicar como as informações das partições são validadas e por que um cabeçalho danificado não significa necessariamente que os arquivos subjacentes estejam perdidos.
Índice
O que é um cabeçalho GPT?
O cabeçalho GPT faz parte da Tabela de Partições GUID (GPT), o esquema de particionamento de disco definido pela especificação UEFI.
Ao contrário do antigo esquema do Master Boot Record (MBR), o GPT mantém duas cópias dos metadados de suas partições: uma próxima ao início do disco e outra próxima ao fim.
Cada cabeçalho GPT contém as informações necessárias para localizar e interpretar a matriz de entradas de partição a ele associada, incluindo:
- Uma assinatura que identifica o formato GPT.
- A revisão e o tamanho do cabeçalho GPT.
- A localização do cabeçalho original e a localização do cabeçalho alternativo.
- O primeiro e o último endereços de bloco lógico utilizáveis.
- Um identificador exclusivo do disco.
- A localização e as dimensões da matriz de entradas da partição.
- Somas de verificação CRC32 para garantir a integridade dos metadados.
O cabeçalho GPT não armazena diretamente nomes de arquivos, estruturas de pastas nem o conteúdo dos arquivos. Esses elementos pertencem aos sistemas de arquivos dentro das partições.
Para obter uma visão geral do esquema de particionamento, consulte GPT (tabela de partição GUID). As definições oficiais estão disponíveis no Especificação UEFI, Seção 5.3.
Onde fica o cabeçalho GPT?
O GPT armazena seus metadados principais e de backup em extremidades opostas de um disco.
Para um disco GPT convencional:
Localização | Índice |
LBA 0 | MBR de proteção |
LBA 1 | Cabeçalho principal do GPT |
Acompanhando os LBAs | Matriz de entradas de partição primária |
Intervalo de LBA utilizável | Espaço disponível para divisórias |
LBAs antes do bloco final | Matriz de entradas de partições de backup |
Último LBA | Backup do cabeçalho GPT |
O MBR de proteção ajuda a evitar que ferramentas antigas, compatíveis apenas com MBR, tratem o disco GPT como não alocado.
É diferente do próprio cabeçalho GPT. Para uma comparação com os metadados tradicionais de partição, consulte Tabela de partição MBR.
Setores lógicos e endereços de byte
O GPT utiliza endereços de bloco lógico (LBAs), e não deslocamentos absolutos em bytes, para identificar suas estruturas.
Para converter um LBA em um deslocamento em bytes:
Deslocamento em bytes = LBA × Tamanho do bloco lógico
Por exemplo:
- Em um disco com blocos lógicos de 512 bytes, o cabeçalho primário começa no deslocamento de bytes
512(0x200). - Em um disco com blocos lógicos de 4.096 bytes, o cabeçalho primário começa no deslocamento de byte
4096(0x1000).
O cabeçalho normalmente ocupa 92 bytes dentro de um bloco lógico, embora o formato permita cabeçalhos maiores, até o tamanho do bloco lógico.
Um cabeçalho de 92 bytes não deve ser confundido com um setor de 512 bytes. Os bytes restantes de um bloco de cabeçalho de 512 bytes são reservados e devem ser zero.
Estrutura do cabeçalho GPT: campos, deslocamentos e tamanhos
A estrutura do cabeçalho GPT está definida em Especificação UEFI 2.10, Tabela 5.5.
Os deslocamentos a seguir são relativos ao início do cabeçalho GPT, e não ao início do disco.
Campo | Deslocamento (hexadecimal) | Tamanho | Finalidade |
Assinatura |
| 8 bytes | Identifica o cabeçalho GPT |
Revisão |
| 4 bytes | GPT format revision |
Tamanho do cabeçalho |
| 4 bytes | Header length in bytes |
HeaderCRC32 |
| 4 bytes | Checksum of the header |
Reservado |
| 4 bytes | Must be zero |
MyLBA |
| 8 bytes | Location of this header |
LBA alternativo |
| 8 bytes | Location of the other header |
FirstUsableLBA |
| 8 bytes | First usable partition block |
LastUsableLBA |
| 8 bytes | Last usable partition block |
DiskGUID |
| 16 bytes | Unique disk identifier |
PartitionEntryLBA |
| 8 bytes | Start of the associated entry array |
Número de entradas de partição |
| 4 bytes | Number of entry slots |
Tamanho da entrada da partição |
| 4 bytes | Tamanho de cada entrada |
PartitionEntryArrayCRC32 |
| 4 bytes | Checksum of the entry array |
The defined fields occupy offsets 0x00 por meio de 0x5B, totaling 92 bytes. Bytes from 0x5C to the end of the logical block are reserved.
Signature and Revision
A valid GPT header begins with the ASCII signature PEÇA EFI.
The eight bytes are:
45 46 49 20 50 41 52 54
The standard GPT revision 1.0 is represented by the little-endian bytes:
00 00 01 00
These represent the numeric value 0x00010000. The GPT header revision is not the same as the UEFI specification version.
The commonly used header size is 92 bytes, encoded as:
5C 00 00 00
Disk GUID and Byte Order
The DiskGUID field occupies 16 bytes, beginning at offset 0x38.
It identifies the GPT disk. It is different from the unique partition GUID stored inside each individual partition entry.
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.Número de entradas de partiçãodefines its entry count.Tamanho da entrada da partiçãodefines 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 Estrutura da entrada de partição GPT, including byte offsets and GUID encoding, see our Entrada de partição GPT: campos “Structure”, “Array” e “GUID” guia.
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
0por meio 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:
Estrutura | Primary GPT | Backup GPT |
Header LBA |
|
|
MyLBA |
|
|
LBA alternativo |
|
|
PartitionEntryLBA |
|
|
Entry array extent |
|
|
FirstUsableLBA |
|
|
LastUsableLBA |
|
|
Header size | 92 bytes | 92 bytes |
These positions follow directly from the disk size and the two 32-block partition entry arrays.
Por exemplo:
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 |
|
|
|
|
| Revisão |
|
| 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:
Campo | Stored bytes | Valor decodificado |
MyLBA |
|
|
LBA alternativo |
|
|
FirstUsableLBA |
|
|
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 e LBA alternativo and changes PartitionEntryLBA para 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:
Checksum | Primary GPT | Backup GPT |
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
O HeaderCRC32 field occupies four bytes at header-relative offset 0x10.
De acordo com o 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
Tamanho do cabeçalhofield 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
Tamanho do cabeçalhobytes. - 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.
Item | Valor |
Tamanho do cabeçalho |
|
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.
Importante: 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 Zero 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.
Diferente de 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 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:
Verificar | Expected condition | Por que é importante |
Assinatura |
| Identifies the structure |
Header size | 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 |
LBA alternativo | 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 |
Intervalo de LBA utilizável | 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.
O 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 recuperação de dados de partição perdida 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 limpo 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 Tamanho do cabeçalho, 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.
Conclusão
O Cabeçalho 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 PEÇA 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.
PERGUNTAS FREQUENTES
O que é a assinatura do cabeçalho GPT?
PEÇA EFI. Em hexadecimal, é 45 46 49 20 50 41 52 54. Ela aparece no início tanto do cabeçalho principal quanto do cabeçalho de backup. A simples identificação dessa sequência não garante que todo o GPT seja válido.Quantos bytes tem um cabeçalho GPT?
Tamanho do cabeçalho O campo define seu comprimento real, que deve ser de pelo menos 92 bytes e não superior ao tamanho do bloco lógico. Os bytes restantes do bloco lógico são reservados.Onde são armazenados os cabeçalhos GPT principal e de backup?
1. O cabeçalho do backup é armazenado no último bloco lógico do disco. Cada cabeçalho MyLBA identifica sua própria localização, enquanto LBA alternativo identifica o outro cabeçalho.Por que os cabeçalhos GPT primário e de backup apresentam valores CRC32 diferentes?
MyLBA, LBA alternativo, e geralmente PartitionEntryLBA. Como esses bytes são abrangidos pelo HeaderCRC32, as somas de verificação calculadas geralmente serão diferentes, mesmo quando ambos os cabeçalhos descrevem com precisão o mesmo disco.Um cabeçalho GPT pode passar na validação CRC32 mesmo que o disco esteja danificado?
É possível recuperar um cabeçalho GPT danificado a partir do backup?
O GUID do disco GPT é o mesmo que o GUID de uma partição?
DiskGUID O campo no cabeçalho GPT identifica o disco. As entradas individuais das partições contêm identificadores distintos, incluindo um GUID do tipo de partição e um GUID exclusivo da partição. Esses valores têm funções diferentes e não devem ser confundidos.