Zip64 signature found in "standard" file. As a result of "357. LocateBlockWithSignature returns false position.

[JanneSaare]

Got a file, ziped by SharpZipLib, that obviously has the signature of ZIP64 some where inside. When unzipping the LocateBlockWithSignature returns a position. This leads to End of Stream error in ZIP64 processing.
I can not send an example file (GDPR)

Steps to reproduce

1. ZIP archive that in its bitsream has by random the ZIP64 signature.
2. Try open archive new ZipFile(SelectedCaseFilePath)
3. LocateBlockWithSignature returns a position resulting in wrong execution path
4. To debug:
   If, in debug, force "standard" decompression the file opens OK.
   // Zip64 Central Directory skipped if not explicitly needed #357 - always check for the existance of the Zip64 central directory.
   long locatedZip64EndOfCentralDir = LocateBlockWithSignature(ZipConstants.Zip64CentralDirLocatorSignature, locatedEndOfCentralDir, 0, 0x1000); //Returns a position
   if (locatedZip64EndOfCentralDir < 0)

Force execution>> {
if (requireZip64)

Expected behavior

A ZipFile object

Actual behavior

End of Stream error.

Version of SharpZipLib

1.2.0

Obtained from (only keep the relevant lines)

• Compiled from source, commit: 56cbe99 on 9 Aug
• Downloaded from GitHub
• Package installed using NuGet

[Numpsy]

hmm, I hadn't noticed when I made that previous change for zip64 handling, but looking now I wonder if the 3rd and 4th parameters to LocateBlockWithSignature are correct?

If it's looking for the zip 64 end of central directory locator block and the definition of that is

zip64 end of central dir locator 
      signature                       4 bytes  (0x07064b50)
      number of the disk with the
      start of the zip64 end of 
      central directory               4 bytes
      relative offset of the zip64
      end of central directory record 8 bytes
      total number of disks           4 bytes

The setting minimumBlockSize to 0 and maximumVariableData to 0x1000 seems wrong? (i.e. should it be 20/0?)

[piksel]

@Numpsy It should, but that would only speed up the search.

What I gather from this is that the problematic zip file contains the magic signature 0x07064b50 in it's content data. This could be due to it containing zip files as content and using Stored compression (or lack thereof), or it could be because of the file being corrupted. Either way, to handle this (somewhat) gracefully we could verify that the offset64 is sane (not greater than the input stream for example) and fall back to using the non-64 central directory.

@JanneSaare would you mind posting the output of

unzip -Z -v -h badfile.zip

(you can remove the file names from the output if they're sensitive)

[Numpsy]

@Numpsy It should, but that would only speed up the search.

Should reduce the chance of finding an incorrect matching magic number by just looking where it should be rather than looking at a range of places?

Either way, to handle this (somewhat) gracefully we could verify that the offset64 is sane (not greater than the input stream for example) and fall back to using the non-64 central directory.

the offset should always be a location prior to the locator block, so could check for that? (and probably also check that it's a reasonable location including the minimum size of the zip 64 directory)

[piksel]

This should be fixed by #408