Recover corrupted password protected Zip

Question

Good evening. I have a password protected zip archive (Zip 2.0 CryptoZip) with a .txt file with sensitive info inside. The problem is that I can't extract it.

• 7Zip:"Data error : Wrong password?"
• WinRar:"CRC failed in the encrypted file. Corrupt file or wrong password"

I'm pretty sure I enter the right password, because when I try any different passwords it just ends up with "wrong password".

I reproduced the same error by the following steps:

• Created a password protected zip with a single txt file inside
• Edited some of the bytes using Hex editor
• Tried to extract the zip using my password and got the same error.

My question is simple: is there any way now to extract the txt file from this corrupted password protected zip?

I tried to "repair" the zip using WinRAR, Object Fix Zip, DiskInternals Zip Repair, Recovery Zip Toolbox, Zip2Fix. None of them could help me, the "repaired" zip is still broken and I get the same error.

Thank you.

Answer 1

If the ZIP file only holds that one TXT file, then I'm afraid chances of recovery are low.

Try visually inspecting the file's hex dump. A "true", undamaged ZIP file should contain high-entropy, random values (all the more so if it's encrypted too). If there are large swaths of repeated filler characters (0x00, 0xC0, 0xA9, 0xFF...), then that section of file is almost certainly corrupt.

On some systems (e.g. Linux console with no buffering) you can try and extract the file with unzip -c. This will result in the file beginning decryption and output, and failing as soon as it hits the corrupted block. The data up to that point will be extracted normally.

Special cases

• A whole block of size 512, 1024, 2048 or 4096 bytes in the ZIP is empty (filled with zeroes, FFs, or the like). This is almost certainly due to the hardware support the ZIP file was on, going corrupt. The sector has been replaced by nulls. If you still have the original support you may try recovering that. If it was a hard disk, it was a bad hard remap of a damaged sector, and the data is lost (unless you can interface at a very low level with the disk itself, which is brand- and disk- dependent). Chances of recovery are essentially nil.

• The ZIP file appears intact. No obvious blanks inside. There is a possibility: the file was transferred with CRLF conversion, and ALL its LF's have become CRLF's pairs. This happens once every 256 bytes on average and you can verify it by counting how many naked CR's, how many naked LF's, and how many CRLF pairs are in the file. If this is the case, you will have to locate all those pairs and remove the extra CR, and each time verify whether the decoding progresses or not. Usually, by re-zipping the partially recovered file (after truncating any ending garbage) with the same algorithm, you can come up with an intact ZIP file that you can compare with the damaged one to determine the position, in the ZIP stream, of the error (i.e.: if the zipped fragment is 7291 bytes long, then in the damaged zip file, at around offset 7291 relative, there is an error). I had this happen to me once, and was able to recover the file; I remember it took a whole night, though.