Teste de recuperação de danos no cabeçalho do GPT
A Teste de recuperação de danos no cabeçalho do GPT questiona se um backup intacto é capaz de reconstruir os metadados de uma partição danificada. No exemplo gerado abaixo, isso é possível — desde que o cabeçalho do backup e sua matriz de entradas sejam válidos e descrevam o layout pretendido. No entanto, um CRC de cabeçalho correspondente, por si só, não garante que a tabela de partições esteja utilizável. Este experimento calcula sete estados de metadados, incluindo dois contraexemplos que passam na verificação da soma de verificação do cabeçalho. Em seguida, ele reconstrói a GPT primária a partir do backup e compara o resultado com a linha de base.
Índice
Questão de pesquisa e escopo
A pergunta é específica: após uma alteração definida próxima ao início de um disco GPT, os metadados remanescentes permitem a reconstrução do GPT primário original?
Este teste controlado, em nível de byte, constrói metadados GPT na memória, aplica as alterações definidas e valida as somas de verificação resultantes, os campos de localização e a reconstrução em comparação com uma linha de base inalterada.
O teste avalia a integridade do mapa de partições: se cada cópia do GPT é válida, se um backup existente permite a reconstrução e se os metadados reconstruídos correspondem à linha de base. Para as definições de campos subjacentes ao experimento, consulte o Estrutura do cabeçalho GPT e guia sobre o CRC32.
Configuração de referência e premissas
A configuração de referência é um exemplo de disco lógico de 64 MiB. Esse layout compacto facilita o acompanhamento dos endereços e isola os efeitos das alterações nos cabeçalhos GPT e nas matrizes de entradas.
Parâmetro | Configuração de referência |
Capacidade lógica | 67.108.864 bytes; 131.072 blocos lógicos |
Tamanho do bloco lógico | 512 bytes |
Esquema de partição | Revisão 1.0 do GPT; MBR de proteção |
Tamanhos de cabeçalho e de matriz | Cabeçalhos de 92 bytes; 128 entradas de 128 bytes cada |
Partição ativa | Um registro de dados básico da Microsoft chamado LAB-DATA |
Conteúdo da partição | Padrão determinístico de bytes para verificações de integridade em toda a faixa |
O campo “Microsoft Basic Data” descreve o intervalo da partição e a finalidade de uso. Sua carga útil segue um padrão determinístico de bytes, permitindo uma comparação exata antes do dano e após a reconstrução.
As notas de cálculo expansíveis da comparação fornecem os locais dos metadados, os limites utilizáveis e a extensão exata da partição ativa. Todos os LBAs são relativos ao início desse disco lógico. O guia de endereçamento de blocos lógicos explica como convertê-los em deslocamentos em bytes.
Procedimento do experimento
Os rótulos S0–S6 Identifique os sete estados de amostra gerados, utilizados nos resultados e no seletor de cenários. Eles não representam operações de dano consecutivas em um único disco. S0 é a referência inalterada; S1 a S5 partem, cada um, de uma cópia independente de S0. Apenas S6 parte de S3.
Todas as alterações foram feitas em cópias descartáveis geradas. Não execute essas operações que causam danos em uma unidade que contenha dados necessários.
S0 — Linha de base: ambas as cópias do GPT estão intactas.
Crie o MBR de proteção, os cabeçalhos primário e de backup e as matrizes de entradas idênticas. Verifique as somas de verificação, os campos de localização, as dimensões das matrizes e os limites das partições. Mantenha esse estado inalterado como referência para todas as comparações.
S1 — Byte do cabeçalho primário corrompido.
Altere o primeiro elemento do cabeçalho principal DiskGUID byte no deslocamento relativo ao cabeçalho +0x38 de 33 para 32. Deixe o CRC do cabeçalho armazenado inalterado. Mantenha inalteradas ambas as matrizes, o cabeçalho de backup e o conteúdo da partição. Isso permite identificar uma incompatibilidade entre o cabeçalho e o CRC.
S2 — Falta o cabeçalho principal.
Substitua o bloco de 512 bytes no LBA 1 por zeros. Preserve a matriz primária e o GPT de backup completo. Verifique se o backup remanescente serve como fonte válida de reconstrução quando o cabeçalho primário não apresentar uma assinatura reconhecível.
S3 — Matriz de entrada primária danificada.
Na entrada 0 da matriz primária no LBA 2, altere o byte de nome no deslocamento relativo à entrada +0x38 de 4C para 4D, alterando L para M. Deixe ambos os cabeçalhos inalterados. Isso isola uma incompatibilidade entre o CRC da matriz e o CRC do cabeçalho, enquanto o CRC do cabeçalho principal ainda é válido.
S4 — Faltam os dois cabeçalhos.
Substitua os blocos de cabeçalho principal e de backup, nos LBAs 1 e 131071, por zeros. Preserve ambas as matrizes de entradas e o conteúdo da partição. Isso testa o limite da reconstrução quando nenhum dos cabeçalhos válidos sobrevive.
S5 — Cabeçalho de backup copiado sem adaptação.
Copie o bloco de cabeçalho de backup literalmente para o LBA 1. Não altere seus campos de localização nem a soma de verificação. Isso verifica se um CRC de cabeçalho válido pode coexistir com endereços incorretos no lado primário.
S6 — GPT primário reconstruído a partir do S3.
Comece com o dano ao array definido em S3. Restaure o array primário a partir de seu backup verificado, adapte os campos de localização do cabeçalho do backup para o lado primário e recalcule o CRC do cabeçalho. Compare os metadados reconstruídos, byte por byte, com os de S0.
Para cada estado, verifique separadamente o CRC do cabeçalho, o CRC da matriz e as relações de localização. A falta de um cabeçalho torna as verificações associadas indisponíveis; um CRC correspondente, por si só, não garante a validade do GPT. Compare separadamente todo o intervalo de conteúdo da partição, incluindo seu SHA-256, com o S0. A condição de aprovação é um layout GPT consistente, com o intervalo de conteúdo da partição preservado.
Resultados do teste de recuperação de danos no cabeçalho do 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 em 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 para 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.
O 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| Cenário | Header CRC | Array CRC | Localização | 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 Tamanho do cabeçalho 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.
Conclusão
Isso Teste de recuperação de danos no cabeçalho do 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
Como posso verificar se um cabeçalho GPT está corrompido?
É possível reparar um cabeçalho GPT corrompido a partir do backup?
O backup GPT preserva as partições que foram excluídas?
A recuperação do cabeçalho GPT consegue restaurar arquivos sem perda de dados?
E se tanto o cabeçalho GPT primário quanto o de backup estiverem danificados?
Como posso testar a recuperação do cabeçalho GPT com segurança?
A reparação do cabeçalho GPT resolverá uma falha na inicialização do Windows?
