7-Zip Archive Header Integrity and CRC32 Checksums
7-Zip protects the structural metadata of its archives by embedding 32-bit Cyclic Redundancy Check (CRC32) checksums directly within the archive header layout. This article explains how the 7z format uses CRC32 algorithms to validate the Start Header and the Main Header, ensuring that directory layouts, compression parameters, and file boundaries remain uncorrupted before extraction begins.
The 7z Header Architecture
The 7z archive format separates compressed payload data from the metadata required to decompress it. The metadata is housed in structured blocks known as headers. To ensure these headers have not suffered from disk corruption, transmission errors, or incomplete downloads, 7-Zip implements a two-tier verification mechanism using CRC32.
An unencrypted 7z archive primarily contains two critical header structures:
- The Start Header: A fixed 32-byte structure located at the very beginning of the archive.
- The Next Header (Main Header): A variable-length structure, typically located at the end of the archive, containing metadata such as filenames, file sizes, timestamps, and compression filters.
Verifying the Start Header
When 7-Zip opens an archive, it first reads the 32-byte Start Header. This fixed-size block contains the following layout:
- Bytes 0–5: The 7z signature
(
'7', 'z', 0xBC, 0xAF, 0x27, 0x1C). - Bytes 6–7: Major and minor format version numbers.
- Bytes 8–11: CRC32 of the Start Header data (bytes 12 through 31).
- Bytes 12–19: 64-bit integer pointing to the relative offset of the Next Header.
- Bytes 20–27: 64-bit integer representing the size of the Next Header.
- Bytes 28–31: CRC32 of the Next Header.
Integrity verification begins at byte 8. 7-Zip computes the CRC32 hash of bytes 12 through 31. It compares the resulting value with the 4-byte checksum stored at bytes 8–11. If these values do not match, the archive is immediately flagged as damaged because the pointer to the main catalog is unreliable.
Validating the Main Header
Once the Start Header passes verification, 7-Zip uses the offset and size values to locate and read the Next Header.
Before parsing the streams and properties defined in the Next Header,
7-Zip calculates the CRC32 hash of the entire Next Header block. It
compares this newly computed checksum against the
NextHeaderCRC value stored in bytes 28–31 of the Start
Header.
If the hashes match, 7-Zip proceeds with decompression. If they differ, 7-Zip triggers a "Headers Error" and aborts processing, preventing crashes caused by attempting to parse malformed data structures.
Encoded and Compressed Headers
The 7z format allows the Main Header to be compressed (typically with LZMA) or encrypted (using AES-256). In these configurations, header integrity verification functions in stages:
- Encoded Stream Verification: The
NextHeaderCRCin the Start Header validates the compressed or encrypted byte stream before decompression or decryption occurs. - Internal Structure Verification: Within the decoded header stream, individual metadata blocks (such as file lists, folder descriptors, and property streams) can include their own embedded CRC32 values to ensure internal consistency after decoding.
By validating both the location pointers and the metadata payload through standard CRC32 algorithms, 7-Zip prevents corrupted archives from causing memory faults or silent file corruption during extraction.