How 7-Zip Handles Corrupted Encrypted Headers

When an encrypted 7-Zip archive encounters header corruption, the software's behavior depends entirely on whether the damage affects the unencrypted outer signature or the encrypted internal metadata stream. If the primary file signature is damaged, 7-Zip fails to detect the file as a valid container, preventing any extraction attempts before a password can even be entered. If the damage resides within an encrypted header block, the program typically mistakes the corrupted payload for an invalid decryption attempt, returning ambiguous errors such as "Wrong password" or "Headers Error."

Outer Signature vs. Encrypted Headers

Every native .7z file begins with a 32-byte Start Header containing a 6-byte magic signature (7z\xBC\xAF\x27\x1C), version numbers, and CRC32 checks pointing to the main metadata blocks. In archives protected by full header encryption (the "Encrypt file names" feature), this initial 32-byte signature remains unencrypted so the extraction utility knows how to interpret the container.

If these initial signature bytes are modified or corrupted:

  • Archive Detection Failure: 7-Zip fails to identify the file format. It returns a generic "Cannot open file as archive" error message and does not display a password prompt.
  • Heuristic Scanning: In some cases, 7-Zip scans beyond the initial offset to check if the file is an executable self-extracting archive (SFX) or if arbitrary data was prepended. If no valid signature block can be located via heuristics, processing stops completely.

Behavior During Encrypted Header Corruption

When the outer signature is intact but the encrypted header block—located at the end of the archive or pointed to by the Start Header—contains bit rot or bad sectors, the extraction workflow proceeds differently:

  1. Password Request: 7-Zip prompts the user for the decryption key as normal, because the basic container framework is intact.
  2. Key Derivation and AES Decryption: 7-Zip processes the provided password through a SHA-256 hashing loop (typically 2^19 cycles) to derive the AES-256 key and attempts to decrypt the header stream.
  3. Integrity Validation Failure: Decrypted headers end with specific property identifiers, sizes, and CRC32 checksums. Because AES-256 in CBC mode exhibits error propagation, even a single altered bit in the encrypted block turns the decrypted result into random, unparseable data.
  4. Indistinguishable Error Codes: 7-Zip cannot distinguish between mathematically valid data decrypted with the wrong password and corrupted data decrypted with the correct password. As a result, the application aborts and displays a "Wrong password" or "Headers Error" prompt.

Recovery and Parsing Limits

7-Zip does not natively contain forward error correction (FEC) data unless the user manually created parity files (such as PAR2) prior to archive damage.

If the Start Header's CRC32 check fails, 7-Zip attempts to locate backup metadata blocks or inspect the end of the physical file for an alternative header descriptor. However, if the encryption layer itself is compromised, the parsing engine cannot reconstruct file boundaries, directory structures, or compression parameters, rendering standard GUI and CLI extraction impossible without manual binary reconstruction or specialized hex repair tools.