GPT 標頭損壞恢復測試
A GPT 標頭損壞恢復測試 探討尚存的備份是否能重建受損的分區元資料。在下文生成的範例中，只要備份標頭及其條目陣列通過驗證且描述了預期的佈局，便能做到這一點。 然而，僅憑匹配的標頭 CRC 並不能證明分區表可正常使用。此實驗計算了七種元資料狀態，其中包括兩個雖通過標頭校驗和檢查但實際不可用的反例。接著，系統從備份中重建主要 GPT，並將結果與基準進行比對。.
目錄
研究問題與範圍
問題很具體：在 GPT 磁碟起始處附近發生某種特定變更後，殘存的元資料是否足以支援重建原始的主要 GPT？
此項受控的位元組級測試會在記憶體中建構 GPT 元資料，套用已定義的變更，並將產生的校驗和、位置欄位以及重建結果與未經變更的基準進行比對以驗證其正確性。.
此測試旨在評估分區映射的完整性：包括每個 GPT 副本是否通過驗證、現存的備份是否足以支援重建，以及重建後的元資料是否與基準資料相符。有關此實驗背後欄位定義的詳細資訊，請參閱 GPT 標頭結構與 CRC32 指南.
參考配置與假設
參考配置是一個 64 MiB 的邏輯磁碟範例。這種緊湊的佈局使位址結構易於追蹤，並能隔離 GPT 標頭與條目陣列變更所產生的影響。.
參數 | 參考配置 |
邏輯容量 | 67,108,864 位元組；131,072 個邏輯區塊 |
邏輯區塊大小 | 512 位元組 |
分割方案 | GPT 修訂版 1.0；保護性 MBR |
標頭與陣列大小 | 92 位元組的標頭；128 個條目，每個條目 128 位元組 |
活躍分割區 | 一個名為 LAB-DATA 的 Microsoft Basic 資料欄位 |
分割區內容 | 用於全範圍完整性檢查的確定性位元組模式 |
「Microsoft Basic」資料條目描述了分割區範圍及其預期用途。其有效載荷遵循一種確定性的位元組模式，使得在損毀前與重建後皆能進行精確比對。.
此比較中的可展開計算註解會提供元資料位置、可用範圍，以及活動分割區的確切範圍。所有 LBA 皆以該邏輯磁碟的起始位置為基準。該 邏輯區塊位址指南 說明了如何將它們轉換為位元組偏移量。.
實驗程序
標籤 S0–S6 請辨識結果及「情境選擇器」中使用的七種生成的樣本狀態。這些並非對同一磁碟進行的連續損壞操作。S0 為未變更的參考狀態；S1 至 S5 各自從 S0 的獨立副本開始。僅有 S6 從 S3 開始。.
所有變更均已套用至一次性生成的副本。請勿在包含必要資料的磁碟機上執行這些損毀操作。.
S0 — 基準狀態：兩份 GPT 副本均完好無損。.
建立保護性 MBR、主分區標頭與備份標頭，以及完全相同的條目陣列。驗證校驗和、位置欄位、陣列維度及分區邊界。將此未經變更的狀態保留下來，作為每次比對的參考基準。.
S1 — 主要標頭位元組損壞。.
變更主要標題的開頭 磁碟 GUID 以標頭為基準的偏移量處的位元組 +0x38 從 33 至 32. 保持其儲存的標頭 CRC 不變。同時保持兩個陣列、備份標頭及分割區內容不變。此舉可隔離標頭與 CRC 不匹配的問題。.
S2 — 缺少主要標題。.
將位於 LBA 1 處的 512 位元組區塊替換為零。保留主陣列及完整的備份 GPT。當主標頭沒有可辨識的簽名時，檢查尚存的備份是否能提供有效的重建來源。.
S3 — 主要輸入陣列受損。.
在 LBA 2 處的主陣列第 0 個條目中，將位於條目相對偏移量處的名稱位元組變更為 +0x38 從 4C 至 4D, 將 L 改為 M。兩個標頭均保持不變。此舉可隔離陣列 CRC 不匹配的問題，同時主標頭的 CRC 仍能通過驗證。.
S4 — 兩個頭板均遺失。.
將位於 LBA 1 和 LBA 131071 處的主標頭區塊與備用標頭區塊替換為零。保留兩個條目陣列以及分割區內容。此操作旨在測試當兩個有效標頭均已遺失時，資料重建能力的極限。.
S5 — 備份標頭已複製，未經調整。.
將備份標頭區塊原封不動地複製到 LBA 1。請勿變更其位置欄位或校驗和。此操作旨在驗證：通過 CRC 驗證的標頭是否能與不正確的主側位址共存。.
S6 — 從 S3 重建的主要 GPT。.
首先，以 S3 中定義的陣列損壞情況為起點。從已驗證的備份中還原主陣列，將備份標頭中的位置欄位調整為主陣列側的設定，並重新計算其標頭的 CRC 值。將重建後的元資料與 S0 進行逐位元組比對。.
針對每個狀態，請分別檢查標頭 CRC、陣列 CRC 以及位置關聯性。 若缺少標頭，則相關檢查將無法進行；僅憑 CRC 值匹配並不能證明 GPT 有效。請分別將整個分割區內容範圍（包含其 SHA-256 值）與 S0 進行比對。通過的條件是 GPT 佈局一致，且分割區內容範圍完整無缺。.
GPT 標頭損壞恢復測試結果
以下三個渲染視圖在螢幕上保留了相同的頁首區域。請參照第 行中勾勒出的位元組 +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.
的 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| 場景 | Header CRC | Array CRC | 地點 | 備份 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 標題大小 bytes with 標頭CRC32 temporarily zeroed. The array CRC covers 分區條目數 × 分區條目大小 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.
總結
這個 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
該如何檢查 GPT 標頭是否已損壞？
損壞的 GPT 標頭能否透過備份進行修復？
備份的 GPT 會保留已被刪除的磁碟區嗎？
GPT 區塊頭修復能否在不造成資料遺失的情況下恢復檔案？
如果主 GPT 標頭和備用 GPT 標頭都損壞了，該怎麼辦？
該如何安全地測試 GPT 標頭的復原？
修復 GPT 標頭能否解決 Windows 開機失敗的問題？
