ZIP 파일 구조 분석｜Local File Header·Central Directory 확인 방법

디지털 파일 검증 연구소 2026년 10월 27일 최종 수정 11월 4일 읽는 시간 약 28분

ZIP 파일은 여러 파일과 폴더를 하나의 압축파일로 묶을 때 사용하는 대표적인 아카이브 형식이다.

Windows에서는 ZIP 파일을 마우스 오른쪽 버튼으로 클릭해 압축을 해제하거나, 파일 탐색기에서 압축파일 내부 목록을 확인할 수 있다.

하지만 ZIP 파일 내부에는 단순히 압축된 데이터만 저장되는 것이 아니다.

각 파일의 위치와 크기를 설명하는 헤더, 압축 방식, CRC-32 검사값, 파일 목록을 관리하는 중앙 디렉터리, 압축파일의 끝을 식별하는 종료 레코드 등이 함께 저장된다.

이러한 구조를 이해하면 ZIP 파일이 어떤 방식으로 구성되어 있는지 파악하고, 파일 목록이 표시되지 않거나 압축 해제 과정에서 오류가 발생하는 원인을 분석하는 데 도움이 된다.

이번 글에서는 ZIP 파일 구조 분석을 중심으로 Local File Header, Central Directory, EOCD(End of Central Directory)의 역할을 살펴본다.

또한 Windows PowerShell을 이용해 ZIP 헤더 바이트와 내부 파일 목록을 확인하고, CRC-32와 SHA-256 검증의 차이, ZIP64 및 압축파일 분석 시 주의사항까지 정리한다.

1. ZIP 파일 구조 분석이 필요한 이유

ZIP 파일은 문서, 이미지, 프로그램 설치 자료, 백업 파일 등을 전달할 때 널리 사용된다.

일반적인 상황에서는 압축파일을 열어 내부 파일을 확인하고 필요한 항목을 추출하면 된다.

그러나 다음과 같은 문제가 발생하면 ZIP 내부 구조를 분석할 필요가 있다.

ZIP 파일을 열 수 없다는 오류가 발생하는 경우
압축파일 내부 목록이 정상적으로 표시되지 않는 경우
일부 파일만 압축 해제되는 경우
전송 이후 파일 손상이 의심되는 경우
확장자가 ZIP인 파일의 실제 형식을 확인하려는 경우
압축파일의 파일 목록과 내부 메타데이터를 점검하려는 경우
CRC 오류와 파일 전체 해시 불일치의 차이를 이해하려는 경우

ZIP 구조 분석은 아카이브를 구성하는 레코드와 내부 파일 정보를 확인하는 작업이다.

반면 SHA-256 검증은 압축파일 전체의 바이트가 신뢰할 수 있는 기준 파일과 동일한지 비교하는 작업이다.

따라서 ZIP 구조가 정상이라는 사실만으로 압축파일이 원본과 동일하거나 안전하다고 판단할 수는 없다.

2. ZIP 파일의 전체 구조

일반적인 ZIP 파일은 각 파일의 로컬 헤더와 데이터, 중앙 디렉터리, 종료 레코드로 구성된다.

기본 구조

ZIP Archive
│
├── Local File Header 1
├── File Data 1
├── Data Descriptor 1 (선택)
│
├── Local File Header 2
├── File Data 2
├── Data Descriptor 2 (선택)
│
├── ...
│
├── Central Directory
│   ├── File Header 1
│   ├── File Header 2
│   └── ...
│
├── ZIP64 Records (필요한 경우)
│
└── End of Central Directory
    (EOCD)

위 구조는 일반적인 ZIP 아카이브의 구성을 단순화한 예시다.

실제 ZIP 파일은 암호화, 분할 압축, ZIP64 확장, 추가 필드 등의 사용 여부에 따라 더 복잡해질 수 있다.

주요 구성 요소

구성 요소	역할
Local File Header	개별 파일 데이터의 시작과 속성 기록
File Data	압축되거나 저장된 실제 파일 데이터
Data Descriptor	일부 메타데이터를 파일 데이터 뒤에 기록
Central Directory	아카이브 내부 파일의 목록과 위치 정보 관리
EOCD	중앙 디렉터리의 위치와 크기 등 종료 정보 기록
ZIP64 Records	기존 필드 크기의 한계를 넘는 정보를 표현

ZIP 파일을 해석하는 프로그램은 일반적으로 파일 끝부분의 EOCD를 찾아 중앙 디렉터리 위치를 확인한 뒤, 개별 파일의 로컬 헤더와 데이터에 접근한다.

3. ZIP 파일 시그니처와 Magic Number

ZIP 파일 내부의 주요 레코드는 고유한 시그니처(Signature)를 가진다.

이 시그니처는 레코드 유형을 구분하는 데 사용된다.

대표적인 ZIP 시그니처

구조	16진수 바이트
Local File Header	`50 4B 03 04`
Central Directory File Header	`50 4B 01 02`
EOCD	`50 4B 05 06`
Data Descriptor의 선택적 시그니처	`50 4B 07 08`
ZIP64 EOCD	`50 4B 06 06`
ZIP64 EOCD Locator	`50 4B 06 07`

첫 두 바이트인 50 4B는 ASCII 문자로 PK에 해당한다.

이는 ZIP 형식의 역사와 관련된 특징적인 식별 문자열이다.

ZIP 파일의 시작 바이트

일반적인 비어 있지 않은 ZIP 파일은 다음 바이트로 시작할 수 있다.

50 4B 03 04

반면 파일이 하나도 없는 빈 ZIP 아카이브는 EOCD 레코드만 포함할 수 있다.

따라서 다음 바이트로 시작하는 정상적인 ZIP 파일도 존재한다.

50 4B 05 06

또한 실행 파일과 ZIP 데이터를 결합한 자동 압축 해제 파일 등은 ZIP 관련 데이터가 파일 시작 위치에 있지 않을 수도 있다.

따라서 ZIP 파일의 첫 4바이트만 확인하는 방식은 모든 ZIP 파일에 적용되는 완전한 검증 방법이 아니다.

4. Local File Header의 구조

Local File Header는 ZIP 내부에 저장된 개별 파일의 데이터 앞에 위치하는 레코드다.

파일의 압축 방식과 일부 메타데이터를 기록한다.

Local File Header의 주요 필드

필드	크기
Header Signature	4바이트
Version Needed to Extract	2바이트
General Purpose Bit Flag	2바이트
Compression Method	2바이트
Last Modification Time	2바이트
Last Modification Date	2바이트
CRC-32	4바이트
Compressed Size	4바이트
Uncompressed Size	4바이트
File Name Length	2바이트
Extra Field Length	2바이트

고정 길이 필드의 합계는 30바이트다.

그 뒤에는 파일 이름과 추가 필드가 가변 길이로 이어진다.

구조 예시

50 4B 03 04
14 00
00 00
08 00
...

위 코드는 로컬 헤더의 시작 부분을 설명하기 위한 예시이며, 완전한 ZIP 레코드는 아니다.

주요 필드 해석

Version Needed to Extract

파일을 해제하기 위해 필요한 ZIP 기능 수준을 나타낸다.

General Purpose Bit Flag

암호화, 데이터 디스크립터 사용 여부, 파일 이름 인코딩 등과 관련된 정보를 나타낸다.

Compression Method

파일 데이터에 적용된 압축 방식을 나타낸다.

CRC-32

일반적인 ZIP 엔트리의 압축 해제된 데이터에 대한 오류 검출값이다.

Compressed Size

저장된 압축 데이터의 크기와 관련된 필드다.

Uncompressed Size

압축 해제 후 파일 데이터의 크기를 나타낸다.

단, ZIP64 확장이 사용되는 경우 일부 크기 정보는 추가 필드에서 표현될 수 있다.

5. ZIP 압축 방식과 Compression Method

ZIP은 하나의 압축 알고리즘만 사용하는 형식이 아니다.

각 파일 엔트리에 서로 다른 압축 방식이 지정될 수 있다.

대표적인 압축 방식

Method 값	압축 방식
`0`	Stored, 압축하지 않고 저장
`8`	Deflate
`12`	BZIP2
`14`	LZMA
`93`	Zstandard

지원 가능한 방식은 ZIP 처리 프로그램과 라이브러리 버전에 따라 달라진다.

Stored 방식

Stored 방식은 데이터를 압축하지 않고 ZIP 컨테이너에 저장한다.

이 경우 일반적으로 파일 데이터의 압축 전후 크기가 동일하다.

Deflate 방식

Deflate는 ZIP에서 널리 사용되는 압축 방식이다.

반복되는 데이터 패턴 등을 활용해 저장 공간을 줄일 수 있다.

다만 파일의 특성에 따라 압축률은 달라질 수 있다.

압축 방식이 중요한 이유

ZIP 파일의 구조가 정상이어도 압축 해제 프로그램이 해당 Compression Method를 지원하지 않으면 파일을 추출하지 못할 수 있다.

따라서 압축 해제 실패가 발생했을 때는 파일 손상뿐 아니라 압축 방식의 호환성도 확인해야 한다.

6. Central Directory의 구조와 역할

Central Directory는 ZIP 아카이브에 포함된 파일들의 목록과 주요 메타데이터를 관리하는 구조다.

각 파일에 대응하는 Central Directory File Header가 존재한다.

Central Directory Header의 시작 바이트

50 4B 01 02

이 시그니처는 Central Directory File Header를 나타낸다.

주요 정보

Central Directory에는 다음과 같은 정보가 기록될 수 있다.

파일 이름
압축 방식
CRC-32
압축된 크기
압축 해제 후 크기
파일 수정 시각
파일 속성
Local File Header의 상대적 위치
추가 필드
파일별 설명 정보

Local File Header와 Central Directory의 차이

구분	Local File Header	Central Directory
주요 위치	개별 파일 데이터 앞	일반적으로 ZIP 끝부분
주요 목적	파일 데이터의 구조 설명	전체 파일 목록과 위치 관리
파일 이름	포함	포함
압축 방식	포함	포함
CRC-32	조건에 따라 후속 레코드에 기록 가능	일반적으로 포함
로컬 헤더 위치	별도 위치 필드 없음	위치 정보 포함

Central Directory는 아카이브의 파일 목록을 효율적으로 파악하는 데 중요한 역할을 한다.

일반적인 ZIP 분석에서는 중앙 디렉터리 정보를 바탕으로 각 파일 엔트리의 위치와 속성을 확인한다.

7. EOCD(End of Central Directory)의 역할

EOCD는 ZIP 아카이브의 중앙 디렉터리와 관련된 종료 정보를 기록하는 레코드다.

EOCD의 시그니처는 다음과 같다.

50 4B 05 06

EOCD의 주요 필드

필드	크기
Signature	4바이트
Number of This Disk	2바이트
Disk with Central Directory	2바이트
Entries on This Disk	2바이트
Total Entries	2바이트
Central Directory Size	4바이트
Central Directory Offset	4바이트
ZIP File Comment Length	2바이트

고정 길이 EOCD 레코드는 22바이트다.

ZIP 파일 설명(Comment)이 있으면 그 뒤에 가변 길이 데이터가 이어진다.

EOCD를 확인하는 이유

EOCD에는 중앙 디렉터리의 위치와 크기를 찾는 데 필요한 정보가 포함된다.

따라서 ZIP 파일을 해석할 때 중요한 출발점이 된다.

다만 단순히 파일 끝부분에서 50 4B 05 06 바이트가 발견되었다고 해서 해당 위치가 유효한 EOCD라고 확정할 수는 없다.

파일 설명 영역의 길이와 실제 파일 경계, 중앙 디렉터리 정보 등을 함께 검증해야 한다.

8. Data Descriptor와 General Purpose Bit Flag

ZIP 파일은 압축 데이터를 기록하는 시점에 최종 CRC-32나 크기 정보를 확정하기 어려운 경우가 있다.

이러한 상황에서 Data Descriptor가 사용될 수 있다.

Data Descriptor의 역할

Data Descriptor는 파일 데이터 뒤에 CRC-32와 크기 정보를 기록할 수 있는 구조다.

General Purpose Bit Flag의 비트 3이 설정된 경우 이 방식을 사용한다.

개념적 구조

Local File Header
       |
       v
Compressed File Data
       |
       v
Data Descriptor
       |
       v
Next ZIP Record

Data Descriptor는 선택적 시그니처를 포함할 수 있다.

따라서 50 4B 07 08이라는 문자열이 항상 존재하는 것은 아니다.

또한 ZIP64 사용 여부에 따라 크기 필드의 길이가 달라질 수 있다.

분석 시 주의사항

Local File Header의 CRC-32 또는 크기 필드가 0으로 기록되어 있다고 해서 반드시 파일이 손상된 것은 아니다.

데이터 디스크립터 사용 여부와 Central Directory의 정보를 함께 확인해야 한다.

9. CRC-32 검증의 의미와 한계

CRC-32는 데이터 전송이나 저장 과정에서 발생한 우발적인 오류를 검출하는 데 사용되는 검사값이다.

ZIP 형식에서도 일반적인 파일 엔트리의 데이터 오류를 확인하는 데 활용된다.

CRC-32의 특징

32비트 검사값을 사용한다.
우발적인 데이터 손상 탐지에 유용하다.
일반적인 ZIP 엔트리 메타데이터에 포함된다.
암호학적 무결성 보장을 위한 해시 함수는 아니다.

CRC-32와 SHA-256 비교

구분	CRC-32	SHA-256
출력 크기	32비트	256비트
주요 목적	우발적인 오류 검출	암호학적 해시 검증
ZIP 내부 사용	일반적인 엔트리 검사값	별도 검증 등에 활용
의도적인 변조에 대한 저항성	적합하지 않음	강한 충돌 저항성을 목표로 설계
기준값 비교 필요	필요	필요

CRC-32 값이 일치하더라도 의도적인 데이터 조작이 없었다고 증명할 수는 없다.

또한 압축파일 내부의 CRC-32 값 자체가 변경되었을 가능성도 고려해야 한다.

따라서 출처가 중요한 파일의 동일성을 확인하려면 신뢰할 수 있는 SHA-256 기준값과 비교하는 것이 더 적합하다.

10. ZIP64 구조가 필요한 이유

기본 ZIP 형식의 일부 필드는 16비트 또는 32비트 크기로 정의되어 있다.

이러한 필드에는 표현 가능한 값의 범위가 존재한다.

ZIP64는 기존 필드의 크기 제한을 넘어서는 파일 크기, 아카이브 크기, 엔트리 수 등을 지원하기 위한 확장 구조다.

ZIP64 관련 레코드

구조	시그니처
ZIP64 End of Central Directory	`50 4B 06 06`
ZIP64 EOCD Locator	`50 4B 06 07`

ZIP64를 사용하는 경우 실제 크기와 위치 정보가 확장 필드 또는 ZIP64 종료 레코드에 기록될 수 있다.

ZIP64 분석 시 주의사항

기존 ZIP 필드에서 0xFFFFFFFF 또는 0xFFFF와 같은 특수한 값이 사용되면 확장 정보를 확인해야 하는 경우가 있다.

따라서 기본 EOCD 값만 읽고 전체 파일 크기나 엔트리 수를 확정해서는 안 된다.

또한 ZIP64를 지원하지 않는 오래된 프로그램에서는 정상적인 ZIP64 파일을 열지 못할 수 있다.

11. Windows PowerShell로 ZIP Header 확인하기

이제 Windows에서 ZIP 파일의 시작 바이트를 직접 확인해 보자.

이번 실습은 ZIP 파일을 수정하지 않고 읽기 전용으로 검사한다.

① 실습 파일 준비

다음 경로에 ZIP 파일이 있다고 가정한다.

C:\FileTest\sample.zip

실제 실행할 때는 본인의 ZIP 파일 경로로 변경한다.

② PowerShell 실행 코드

$path = "C:\FileTest\sample.zip"
$stream = [System.IO.File]::OpenRead($path)

try {
    $buffer = New-Object byte[] 16
    $count = $stream.Read($buffer, 0, $buffer.Length)

    if ($count -gt 0) {
        $bytes = $buffer[0..($count - 1)]
        [BitConverter]::ToString($bytes)
    }
}
finally {
    $stream.Dispose()
}

③ 결과 해석

일반적인 ZIP 파일의 시작 부분에서는 다음과 같은 바이트가 확인될 수 있다.

50-4B-03-04

이는 Local File Header의 시그니처에 해당한다.

빈 ZIP 아카이브에서는 다음과 같은 바이트가 확인될 수도 있다.

50-4B-05-06

이는 EOCD의 시그니처다.

④ 실습의 한계

이 코드는 ZIP 파일의 첫 16바이트를 출력한다.

따라서 다음 사항은 확인하지 못한다.

Central Directory의 정상 여부
모든 내부 파일의 CRC-32 일치 여부
압축 해제 가능 여부
ZIP64 구조의 정확성
악성 파일 포함 여부

파일의 시작 바이트는 형식 식별을 위한 단서일 뿐, 전체 ZIP 구조의 정상 여부를 증명하지 않는다.

12. PowerShell로 ZIP 내부 파일 목록 확인하기

이번에는 Windows PowerShell에서 ZIP 내부에 포함된 파일 목록과 크기 정보를 확인해 보자.

.NET의 System.IO.Compression.ZipArchive 클래스를 이용한다.

① PowerShell 코드

$path = "C:\FileTest\sample.zip"

Add-Type -AssemblyName System.IO.Compression

$stream = [System.IO.File]::OpenRead($path)

try {
    $archive = $path = "C:\FileTest\sample.zip"

Add-Type -AssemblyName System.IO.Compression

$stream = [System.IO.File]::OpenRead($path)

try {
    $archive = [System.IO.Compression.ZipArchive]::new(
        $stream,
        [System.IO.Compression.ZipArchiveMode]::Read
    )

    try {
        $archive.Entries |
            Select-Object FullName, Length, CompressedLength
    }
    finally {
        $archive.Dispose()
    }
}
finally {
    $stream.Dispose()
}

② 출력 정보의 의미

항목	의미
FullName	ZIP 내부 파일 또는 디렉터리의 경로
Length	압축 해제 후 데이터 크기
CompressedLength	압축된 데이터 크기

③ 결과 예시

FullName       Length   CompressedLength
--------       ------   ----------------
report.txt       2048                850
image.png      125000             124200
notes/data.csv   4096               1200

위 숫자는 출력 형식을 설명하기 위한 예시이며 실제 측정값은 아니다.

④ 파일 목록 확인의 한계

이 실습은 ZIP 내부 엔트리 목록과 크기를 확인하는 방법이다.

하지만 내부 파일을 모두 읽어 압축 해제하거나 CRC-32를 직접 비교하는 코드는 아니다.

따라서 목록이 정상적으로 표시된다는 사실만으로 모든 파일의 데이터가 손상되지 않았다고 결론 내릴 수 없다.

또한 ZIP 파일이 사용하는 압축 방식이나 암호화 기능에 따라 라이브러리의 지원 범위가 달라질 수 있다.

13. ZIP 파일 손상 시 확인할 주요 항목

ZIP 파일이 열리지 않거나 압축 해제에 실패하면 다음 요소를 점검할 수 있다.

점검 항목	확인 목적
Local File Header	파일 데이터 시작 구조 확인
Central Directory	내부 파일 목록과 참조 정보 확인
EOCD	중앙 디렉터리 위치 정보 확인
Compression Method	압축 방식 지원 여부 확인
CRC-32	파일 데이터 오류 가능성 확인
Data Descriptor	후속 크기 및 검사값 정보 확인
ZIP64	확장 크기 및 위치 정보 확인
파일 전체 크기	전송 중 잘림 또는 누락 가능성 확인

ZIP 파일이 손상되었을 가능성이 있는 경우

압축파일의 마지막 부분이 누락되면 EOCD나 Central Directory가 손상되어 파일 목록을 읽지 못할 수 있다.

또한 내부 압축 데이터가 손상되면 일부 파일의 압축 해제 과정에서 오류가 발생할 수 있다.

그러나 오류가 발생했다고 해서 항상 파일 자체가 손상된 것은 아니다.

압축 프로그램의 호환성, 암호화 방식, 지원하지 않는 압축 알고리즘 등도 원인이 될 수 있다.

14. ZIP 구조 분석 시 보안 주의사항

ZIP 파일은 여러 파일을 포함하는 컨테이너 형식이므로 분석 과정에서 보안 문제도 고려해야 한다.

① 출처가 불분명한 ZIP 파일

알 수 없는 출처의 ZIP 파일에는 실행 파일이나 악성 스크립트 등이 포함될 수 있다.

압축파일의 구조가 정상이라는 사실은 내부 파일이 안전하다는 의미가 아니다.

② ZIP Bomb

ZIP Bomb은 압축된 크기에 비해 압축 해제 후 데이터가 매우 커져 시스템 자원을 과도하게 소비하게 만들 수 있는 압축파일이다.

따라서 신뢰할 수 없는 ZIP 파일은 압축 해제 전에 파일 크기, 엔트리 수, 압축률 등을 검토할 필요가 있다.

③ 경로 탐색 문제

ZIP 내부 파일 이름에 ../와 같은 상대 경로 요소가 포함될 수 있다.

안전하지 않은 압축 해제 프로그램은 이러한 경로를 부적절하게 처리해 의도하지 않은 위치에 파일을 기록할 위험이 있다.

이러한 문제는 흔히 Zip Slip과 관련해 설명된다.

④ 원본 파일 보존

구조 분석 과정에서는 원본 ZIP 파일을 보존하고 별도의 복사본을 사용하는 것이 좋다.

분석을 위해 파일 내부 바이트를 임의로 수정하면 이후의 해시 검증이나 손상 원인 분석에 영향을 줄 수 있다.

15. ZIP 구조 검증과 파일 무결성 검증의 차이

ZIP 파일의 구조를 확인하는 작업과 파일 전체의 무결성을 검증하는 작업은 서로 다른 목적을 가진다.

ZIP 구조 검증

Local File Header, Central Directory, EOCD 등의 구조가 규격에 맞게 연결되어 있는지 확인한다.

CRC-32 검증

일반적인 ZIP 엔트리의 압축 해제된 데이터가 저장된 CRC-32 검사값과 일치하는지 확인한다.

SHA-256 검증

ZIP 파일 전체의 바이트를 대상으로 SHA-256 해시값을 계산하고 신뢰할 수 있는 기준값과 비교한다.

세 가지 검증 방법 비교

구분	주요 확인 대상	한계
ZIP 구조 분석	레코드와 참조 관계	원본 동일성 증명 불가
CRC-32	개별 엔트리의 우발적 데이터 오류	의도적 변조 방어에 부적합
SHA-256	압축파일 전체 바이트	기준값의 신뢰성 필요

따라서 파일 검증 목적에 따라 세 방법을 구분해서 활용해야 한다.

16. 자주 묻는 질문

Q1. ZIP 파일의 Magic Number는 무엇인가요?

일반적인 ZIP 파일의 Local File Header는 50 4B 03 04로 시작한다. 다만 빈 ZIP 파일이나 특수한 구조의 ZIP 파일은 시작 바이트가 다를 수 있다.

Q2. Central Directory는 무엇인가요?

ZIP 아카이브 내부 파일의 이름, 크기, 압축 방식, 위치 정보 등을 관리하는 중앙 디렉터리 구조다.

Q3. EOCD가 없으면 ZIP 파일이 손상된 것인가요?

ZIP 규격상 EOCD는 중요한 필수 종료 레코드다. 유효한 EOCD를 찾을 수 없다면 파일이 잘렸거나 구조에 문제가 있을 가능성이 있다. 다만 단순 문자열 검색 실패만으로 최종 결론을 내려서는 안 된다.

Q4. CRC-32 값이 일치하면 ZIP 파일이 안전한가요?

아니다. CRC-32는 주로 우발적인 데이터 오류 검출에 사용된다. 악성 파일 포함 여부나 의도적인 변조 가능성을 판단하는 보안 검증 수단은 아니다.

Q5. ZIP64는 일반 ZIP과 다른 압축 형식인가요?

ZIP64는 ZIP 형식의 확장 기능이다. 더 큰 파일 크기와 아카이브 정보 등을 표현하기 위해 사용된다.

Q6. ZIP 파일 목록이 정상적으로 표시되면 모든 파일이 정상인가요?

아니다. Central Directory를 읽어 목록을 표시할 수 있어도 실제 파일 데이터가 손상되어 압축 해제에 실패할 수 있다.

Q7. ZIP 파일의 SHA-256 값은 어떻게 확인하나요?

Windows PowerShell의 Get-FileHash 명령으로 ZIP 파일 전체의 SHA-256 값을 계산할 수 있다. 다만 원본과의 동일성을 확인하려면 신뢰할 수 있는 기준 해시값이 필요하다.

마무리

ZIP 파일은 여러 파일을 단순히 하나로 합친 데이터가 아니라, 개별 파일 헤더와 압축 데이터, 중앙 디렉터리, 종료 레코드가 연결된 구조화된 아카이브 형식이다.

Local File Header는 개별 파일 데이터의 시작과 속성을 설명한다.

Central Directory는 아카이브 내부 파일 목록과 위치 정보를 관리한다.

EOCD는 중앙 디렉터리의 위치와 크기 등을 찾는 데 필요한 정보를 제공한다.

또한 ZIP 파일에는 Data Descriptor, ZIP64 확장, 다양한 압축 방식과 암호화 기능이 적용될 수 있다.

따라서 ZIP 파일 구조 분석은 단순히 PK 시그니처를 확인하는 것이 아니라 내부 레코드와 참조 관계를 종합적으로 검토하는 과정으로 이해해야 한다.

ZIP 구조 분석, CRC-32 오류 검출, SHA-256 무결성 검증은 서로 다른 목적을 가지며, 분석 상황에 따라 보완적으로 활용할 수 있다.

핵심 내용 3줄 요약

ZIP 파일은 Local File Header, 파일 데이터, Central Directory, EOCD 등을 중심으로 구성된다.
CRC-32는 일반적인 ZIP 엔트리의 오류 검출에 사용되지만 암호학적 무결성 보장 수단은 아니다.
ZIP 구조가 정상이라고 해서 압축파일이 원본과 동일하거나 내부 파일이 안전하다는 의미는 아니다.

공식 및 기술 참고자료

PKWARE — APPNOTE.TXT, ZIP File Format Specification
https://support.pkware.com/pkzip/appnote
Library of Congress — ZIP File Format (PKWARE)
https://www.loc.gov/preservation/digital/formats/fdd/fdd000354.shtml
Microsoft Learn — ZipArchive Class
https://learn.microsoft.com/dotnet/api/system.io.compression.ziparchive
Microsoft Learn — ZipArchiveEntry Class
https://learn.microsoft.com/dotnet/api/system.io.compression.ziparchiveentry

※ 본문에 제시된 시그니처, 코드 및 출력 결과는 ZIP 구조를 이해하기 위한 기술 설명과 실습 예시다. 실제 ZIP 파일은 압축 방식, 암호화, 분할 압축, ZIP64 사용 여부 등에 따라 구조와 분석 결과가 달라질 수 있다.

디지털 파일 검증 연구소

디지털 파일 검증 연구소는 파일 형식, 확장자, 무결성 확인, 데이터 손상 예방 및 디지털 자료 관리 방법을 다루는 정보 사이트입니다. 파일 오류의 원인과 점검 절차를 이해하기 쉽게 정리하고, 공식 문서와 검증 가능한 자료를 바탕으로 실생활에 도움이 되는 해결 방법을 안내합니다.