GPT 헤더 손상 복구 테스트
A GPT 헤더 손상 복구 테스트 손상된 파티션 메타데이터를 남아 있는 백업으로 복원할 수 있는지 묻습니다. 아래에 제시된 생성된 예시에서 볼 수 있듯이, 백업 헤더와 해당 엔트리 배열이 유효하고 의도된 레이아웃을 정확히 기술하고 있다면 복원이 가능합니다. 그러나 헤더 CRC가 일치한다고 해서 파티션 테이블이 사용 가능하다는 것을 보장하지는 않습니다. 이 실험에서는 헤더 체크섬 검사를 통과하는 두 가지 반례를 포함하여 총 7가지 메타데이터 상태를 계산합니다. 그런 다음 백업에서 기본 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 결과 및 시나리오 선택기에서 사용된 7개의 생성된 샘플 상태를 확인하십시오. 이들은 하나의 디스크에 대해 연속적으로 수행된 손상 작업이 아닙니다. S0은 변경되지 않은 기준 상태이며, S1~S5는 각각 S0의 독립적인 복사본에서 시작됩니다. 오직 S6만이 S3에서 시작됩니다.
모든 변경 사항은 일회용으로 생성된 복사본에 적용되었습니다. 필요한 데이터가 포함된 드라이브에서는 이러한 삭제 작업을 수행하지 마십시오.
S0 — 기준 상태: 두 GPT 사본 모두 손상되지 않음.
보호용 MBR, 주 헤더 및 백업 헤더, 그리고 동일한 항목 배열을 생성합니다. 체크섬, 위치 필드, 배열 차원 및 파티션 경계를 검증합니다. 이 변경되지 않은 상태를 모든 비교의 기준점으로 유지합니다.
S1 — 기본 헤더 바이트가 손상되었습니다.
기본 헤더의 첫 번째 항목을 변경합니다. 디스크 GUID 헤더를 기준으로 한 오프셋 위치의 바이트 +0x38 에서 33 에 32. 저장된 헤더의 CRC는 변경하지 마십시오. 두 배열, 백업 헤더 및 파티션 내용을 모두 변경하지 마십시오. 이렇게 하면 헤더와 CRC 간의 불일치를 특정할 수 있습니다.
S2 — 기본 헤더가 없습니다.
LBA 1에 있는 512바이트 블록을 0으로 채웁니다. 주 어레이와 전체 백업 GPT는 그대로 유지합니다. 주 헤더에 식별 가능한 서명이 없을 경우, 남아 있는 백업이 유효한 재구성 소스를 제공하는지 확인합니다.
S3 — 1차 진입 배열이 손상되었습니다.
LBA 2에 있는 기본 배열의 0번 항목에서, 항목 상대 오프셋에 있는 이름 바이트를 변경하십시오. +0x38 에서 4C 에 4D, L을 M으로 변경합니다. 두 헤더는 모두 변경하지 마십시오. 이렇게 하면 주 헤더의 CRC는 여전히 통과하는 상태에서 배열 CRC 불일치만 분리할 수 있습니다.
S4 — 두 헤더 모두 누락됨.
LBA 1 및 LBA 131071에 위치한 주 헤더 블록과 백업 헤더 블록을 0으로 대체하십시오. 두 엔트리 배열과 파티션 내용은 모두 보존하십시오. 이는 유효한 헤더가 하나도 남아 있지 않은 상황에서 재구성의 한계를 테스트하는 것입니다.
S5 — 헤더를 수정 없이 복사했습니다.
백업 헤더 블록을 LBA 1에 그대로 복사하십시오. 위치 필드나 체크섬을 변경하지 마십시오. 이는 유효한 헤더 CRC가 잘못된 주 주소와 공존할 수 있는지 확인하기 위한 것입니다.
S6 — S3를 기반으로 재구축된 기본 GPT.
S3에 정의된 어레이 손상부터 시작합니다. 검증된 백업에서 주 어레이를 복원하고, 백업 헤더의 위치 필드를 주 어레이 측에 맞게 조정한 다음, 헤더 CRC를 재계산합니다. 재구성된 메타데이터를 S0과 바이트 단위로 비교합니다.
각 상태에 대해 헤더 CRC, 배열 CRC 및 위치 관계를 별도로 확인하십시오. 헤더가 누락되면 관련 검사를 수행할 수 없으며, CRC가 일치한다고 해서 유효한 GPT가 보장되는 것은 아닙니다. SHA-256을 포함한 전체 파티션 내용 범위를 S0과 별도로 비교하십시오. 통과 조건은 파티션 내용 범위가 보존된 일관된 GPT 레이아웃입니다.
GPT 헤더 손상 복구 테스트 결과
아래에 표시된 세 개의 렌더링된 화면은 화면 상단의 헤더 영역을 동일하게 유지합니다. 행에 표시된 바이트를 따라가 보세요. +0030, 칼럼 08—헤더 오프셋 +0x38—그리고 저장된 헤더 CRC와 계산된 헤더 CRC를 비교합니다. 각 뷰에서는 체크섬 및 재구성 검사에 사용된 것과 동일한 샘플 바이트를 표시합니다.
기본 GPT 손상 테스트: 손상 발생 전
기본 기본 헤더에는 다음 내용이 포함되어 있습니다. 33 에서 DiskGUID +0x38. 저장된 헤더 CRC와 계산된 헤더 CRC가 일치합니다. 주 어레이와 백업 GPT도 유효한 것으로 확인되었습니다.
GPT 헤더 16진수 비교: 1바이트가 변경된 후
S1은 다음에서 해당 바이트만 변경합니다. 33 에 32. 저장된 헤더 CRC는 변함이 없지만, 계산된 CRC는 다릅니다. 빨간색 테두리는 변경된 바이트를 표시하고, 음영 처리된 체크섬 바이트는 업데이트되지 않은 값을 나타냅니다. 이 정의된 레이아웃에서 유효한 백업은 여전히 재구성 가능한 소스로 남아 있습니다.
GPT 헤더 백업 복구 실험: 재구성 후
재구성은 주 위치에 대한 검증된 백업 헤더를 적용하고 해당 체크섬을 재계산합니다. 설명된 바이트는 33; 저장된 CRC와 계산된 CRC가 다시 일치합니다. 전체 바이트 비교 결과, 재구성된 기본 메타데이터가 기준값과 일치하는 것으로 확인되었습니다. 이렇게 계산된 S1에서 기준값으로의 전환은 아래에서 설명할 어레이 손상을 복구하는 S6과는 별개의 과정입니다.
배열 손상: 헤더 CRC가 통과되었다고 해서 충분하지 않은 이유
S3는 엔트리 배열에서 첫 번째 파티션 이름 문자를 L에서 M으로 변경합니다. 헤더 바이트는 변경되지 않으므로 헤더의 CRC는 통과하지만 배열의 CRC는 실패합니다. S6는 백업 배열을 복원하고 주 헤더를 재구축하여 원래의 메타데이터를 기준 상태로 되돌립니다.
그리고 GPT 파티션 항목 배열 안내서 이 이름이 헤더가 아닌 배열에 속하는 이유를 설명합니다.
해석을 바꾸는 오류 조건
접혀진 시나리오 테이블은 나머지 검사 항목을 유지합니다. 주 헤더가 없는 경우(S2), 손상되지 않은 백업 헤더를 통해 여전히 재구성이 가능합니다. 두 헤더가 모두 없는 경우(S4), 정의된 배열은 남아 있더라도 재구성 소스가 될 유효한 헤더가 남아 있지 않습니다. 마지막으로, 백업 헤더를 LBA 1에 그대로 복사하면(S5) 유효한 CRC는 보존되지만, 주 위치 필드는 잘못된 상태로 남게 됩니다.
이러한 결과들은 일치하는 체크섬과 일관된 파티션 맵을 구별해 줍니다. 유효한 재구성을 위해서는 체크섬과 위치 관계가 의도된 레이아웃과 일치해야 합니다.
아래의 시나리오 탐색기를 사용하여 Hex에 포함된 7개 상태를 모두 비교해 보세요. S0부터 시작하여 S1~S6 사이를 전환하며, CRC 및 위치 검사와 함께 기본 헤더와 엔트리 배열 발췌 부분을 확인해 보세요. 빨간색은 S0과 다른 바이트를 표시하며, S6의 녹색은 기준값과 일치하는 재구성된 필드를 나타냅니다.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| 시나리오 | 헤더 CRC | 배열 CRC | 위치 | GPT 백업 | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · 기준선 | PASS | PASS | PASS | 유효 | Both GPT copies validate. |
| S1 · 헤더 비트 반전 | 실패 | PASS | PASS | 유효 | Backup header and array remain usable for reconstruction. |
| S2 · 메인 헤더가 없습니다 | Unavailable | Unavailable | Unavailable | 유효 | Backup header and array remain usable for reconstruction. |
| S3 · 주 배열 손상됨 | PASS | 실패 | PASS | 유효 | 주 헤더의 CRC는 통과했으나, 해당 배열의 CRC는 실패했으며, 백업은 유효한 상태를 유지합니다. |
| S4 · 두 헤더 모두 누락됨 | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · 블라인드 백업 사본 | PASS | PASS | 실패 | 유효 | CRC passes, but MyLBA and primary array placement fail. |
| S6 · 1차 기어 재조립 | PASS | PASS | PASS | 유효 | 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 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.
결론
이 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 부팅 오류가 해결될까요?
