Failure to extract a file from an encrypted archive

Oct 18, 2010 at 5:05 PM

Hi Cheeso,

Still loving this library, however I've just encountered the following error whilst using DotNetZip (1.9) to extract a zip file that has been encrypted using AES 256 (encrypted by DotNetZip):

"The final hash has not been computed"

After some investigation, I have isolated the file in question, and tried to unzip it with the DotNetZip unzip.exe tool - I get the following output:

exception: Ionic.Zip.BadStateException: The final hash has not been computed.
   at Ionic.Zip.WinZipAesCipherStream.get_FinalAuthentication()
   at Ionic.Zip.ZipEntry.VerifyCrcAfterExtract(Int32 ActualCrc32)
   at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, String password)
   at Ionic.Zip.ZipEntry.ExtractWithPassword(String baseDirectory, ExtractExistingFileAction extractExistingFile, String password)
   at Ionic.Zip.Examples.UnZip.Main(String[] args)

The problem is reproducible with the same original file, and the resulting zip files do unzip successfully using 7-zip, so I don't think the file itself is corrupted - I have never seen this problem before, so I was wondering if it is some kind of rare block alignment issue causing the _NextXFormWillBeFinal or _finalBlock flag to not be set correctly in the WinZipAesCipherStream class?  I've tried running the UnZip.exe project in my debugger to step through the decryption code, but am having some dev studio setup issues at the moment.  The compressed file is 294943 bytes long, which doesn't strike me as a multiple of anything significant, but then I'm not sure what size the salt and checksums are etc...

Obviously none of this is much use to you without the sample .zip file!

Coordinator
Oct 18, 2010 at 9:29 PM

yes, exactly.  If I had the same zip I'd be able to troubleshoot and diagnose much more easily.

Any chance you can send it to me?

Oct 19, 2010 at 9:51 AM
Hi Cheeso,
Thanks for the response, I've attached the file in question!

As a bit more background:

The password is 'logan12'

If I try and extract using DotNetZip-WinFormsTool.exe I get an error
message box:
"Failed to extract the password-encrypted entry PAT1/STD1/SER1/IMG203 --
The final hash has not been computed"

If I try using the unzip.exe I get the following:

G:\DotNetZip\tools 1.9>unzip g:\ziptest\decryptFail.zip -p logan12 -d
g:\ziptest\img203

Zipfile: g:\ziptest\decryptFail.zip

Modified Size Ratio Packed pw? CRC Filename
---------------------------------------------------------------------

2010-10-18 15:43:38 0 0% 0 N 00000000 PAT1/
2010-10-18 15:43:38 0 0% 0 N 00000000 PAT1/STD1/
2010-10-18 15:44:14 0 0% 0 N 00000000 PAT1/STD1/SER1/
2010-10-18 15:43:48 528220 44% 294943 Y 7873BA97 PAT1/STD1/SE
R1/IMG203
exception: Ionic.Zip.BadStateException: The final hash has not been
computed.
at Ionic.Zip.WinZipAesCipherStream.get_FinalAuthentication()
at Ionic.Zip.ZipEntry.VerifyCrcAfterExtract(Int32 ActualCrc32)
at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream
outstream, String password)
at Ionic.Zip.ZipEntry.ExtractWithPassword(String baseDirectory,
ExtractExistingFileAction extractExistingFile, String password)
at Ionic.Zip.Examples.UnZip.Main(String[] args)

However 7-Zip and WinRar can both extract the file IMG203 successfully,
so I think the file itself is ok.


The original file is an anonymised medical image which has been
encrypted with the following C++ pseudo code options:

ZipFile^ zipArchive = gcnew ZipFile;
zipArchive->Encryption = EncryptionAlgorithm::WinZipAes256;
zipArchive->Password = "logan12"; // in this instance anyway!
zipArchive->UseZip64WhenSaving = Zip64Option::AsNecessary;
zipArchive->CompressionLevel = CompressionLevel::BestSpeed;
zipArchive->Strategy = CompressionStrategy::HuffmanOnly;
zipArchive->AddDirectory(srcDirectory, archiveDirectory);
zipArchive->Save(targetFile);

... which may or may not be relevant - the same original file encrypted
with different options using zipit.exe (specifically strategy not set
because you can't) extracts just fine, so I think it is something
fundamental to do with the resulting bit pattern (my first guess would
be its length aligning with block sizes, but only because that has
tripped me up in the past when parsing blocks from streams, but that may
just be my coding blind spot!) rather than anything to do with the
original data itself.

Anyway, I hope you can reproduce the problem with this info, otherwise
I'll look pretty foolish!
Many thanks for your time,
Stephen



On 18/10/2010 22:29, Cheeso wrote:
>
>
> From: Cheeso
>
> yes, exactly. If I had the same zip I'd be able to troubleshoot and
> diagnose much more easily.
>
> Any chance you can send it to me?
>
> Read the full discussion online
> <http://dotnetzip.codeplex.com/Thread/View.aspx?ThreadId=231352&ANCHOR#Post509001>.
>
> To add a post to this discussion, reply to this email
> ([email removed]
> <mailto:[email removed]?subject=[DotNetZip:231352]>)
>
> To start a new discussion for this project, email
> [email removed]
> <mailto:[email removed]>
>
> You are receiving this email because you subscribed to this discussion
> on CodePlex. You can unsubscribe
> <http://www.codeplex.com/site/discussions/thread/unsubscribe/231352> on
> CodePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any
> posts to this discussion will also be available online at CodePlex.com
>
Oct 19, 2010 at 10:03 AM
Having said that I've just spotted this at the bottom of your reply, so
now I am looking pretty foolish! How do I get a file to you?!

> Images and attachments will be removed from emails.
Coordinator
Oct 24, 2010 at 12:59 PM

You can just open a work item.  go to http://dotnetzip.codeplex.com, then click the "Issue Tracker" link on the top horizontal navbar.

Create a new workitem, and upload your relevant files there.

I monitor both the discussions and the work item lists.  (Work items are for things that almost certainly require changes to DotNetZip code, Discussions are for questions, clarifications, example code, etc).

 

Oct 28, 2010 at 4:15 PM

Hi Cheeso,

Just to let you know I'm also finding the same problem. I;ve encrypted in 128 and 254, but still the same issue.  Like Bobby, it works with 7-zip, but not anythingelse I tried.  Also the DotNetZip extract code I created, which works fine for unencrypted files, takes an extra long time to extract the zip of an ecrypted zip, upto the point before it fails.  7-Zip extracted the same zip of 400MB in less than a minuite, the DotNetZip code seems to take 5-10 mins before it crashed.

Unfortunatly I've not got any zip doing this which hasn;t got sensitive data included.  Let know know if you need one and I'l try and create one.

Apart from this bug, which made me want to cry when I found it!!...DotNetZip has been a joy to work with..Thankyou and well done!!

Regards,

Dave.

Oct 29, 2010 at 11:17 AM

Hi Dave,

Interesting to see you having a similar issue - I have raised a work item (12361) and attached my example files (thankfully the data had been anonymised as part of testing prior to discovering this issue) there's a bit more info on there aswell, as I stepped through some of the decryption process with a debugger.  Out of interest, what if any options do you set for Compression Level (speed vs size), and Compression Strategy (huffman, filtered or default), and what size is the resulting zipped file (7-zip should be able to tell you 'packed size' in bytes if you open the archive and do right click/properties on the file entry)?  These may throw up some commonality with my example which may help rule out or highlight places to look for the issue.

Cheers,

Stephen

Feb 14, 2012 at 11:37 PM
Edited Feb 15, 2012 at 4:43 PM

I'm having this same issue as well.  It appears to occur for me for no apparent reason, and then appears to resolve itself just as quickly.

Here's the stack trace:

Ionic.Zip.BadStateException: The final hash has not been computed.
   at Ionic.Zip.WinZipAesCipherStream.get_FinalAuthentication()
   at Ionic.Zip.ZipEntry.VerifyCrcAfterExtract(Int32 actualCrc32)
   at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, String password)
   at Ionic.Zip.ZipFile._InternalExtractAll(String path, Boolean overrideExtractExistingProperty)
   at DeployPrototype.ExtractionConfiguration.ExtractDeploymentFiles(String zipfiletoextract, String installdir)

Jul 5, 2012 at 9:47 PM

Hi Dave,

I'm seeing this issue as well.  My applications processes zip archives created with version 1.9.1.5 of the library that fail to extract using either 1.9.1.5 or 1.9.1.8 of the library.  The archives extract fine using either 7-Zip or WinRAR.

Unfortunately, the data in the archives is highly proprietary so I can't provide samples for debugging.  I process several hundred archives per day and the problem only affects a small fraction of them.  So far I've been unable to reproduce the problem using "sanitized" contents that I could submit.

Suggestions?

May 24, 2013 at 2:59 PM
Hi, has there been any progress with this issue?

I am also experiencing this with a particular set of files. Other sets of files decompress fine.
There are 3937 files and 3405 of them get unzipped successfully and it fails on the same file each time. Even if the files are compressed again the same thing happens.