3

While trying to analyze zip files, one section Im a little confused by is the Zip64 Extra Information Field. It is expected to be generated when specific fields can't fit in the file header(Central directory or Local) and thus we insert 0xffffffff in the header and place the actual value in the extra info field.
According to the documentation here, this can be found as one of the extra fields following the structure:

        Value      Size       Description
        -----      ----       -----------
(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Original 
        Size       8 bytes    Original uncompressed file size
        Compressed
        Size       8 bytes    Size of compressed data
        Relative Header
        Offset     8 bytes    Offset of local header record
        Disk Start
        Number     4 bytes    Number of the disk on which
                              this file starts

This implies that I should expect the extended info entry size to be 28 bytes always.
However, when analyzing an actual Zip64 archive, I found one Central directory entry where the file offset was 0xffffffff. Next step was to look in the Extra data field for the 0x0001 header-id(expecting the data size to be 28 bytes).
However, instead I found 00 01 00 08 00 36 d4 6b ab 02 00 00 00(which translates to 0x0001 header-id, 8 bytes size and 1 field of value 0x02ab6bd436) which correctly represents the local file header offset. Why aren't the other fields mentioned in the documentation in the Zip64 Extra Information Field?
I'm using the standard zip utility available on Linux machines.

Improve this question
1
  • In our testing, we found that this particular case the value refers to the offset of the local entry, and not the uncompressed size. So in your case, the corresponding local entry can be found at offset 0x02ab6bd436.
    – rdvdijk
    Jun 10, 2021 at 14:01

1 Answer 1

Reset to default
2

I'm sure you don't need the answer anymore, but for future readers. The 64 extra block fields should only appear if needed, as per the specification:

   4.5.3 -Zip64 Extended Information Extra Field (0x0001):

      The following is the layout of the zip64 extended 
      information "extra" block. If one of the size or
      offset fields in the Local or Central directory
      record is too small to hold the required data,
      a Zip64 extended information record is created.
      The order of the fields in the zip64 extended 
      information record is fixed, but the fields MUST
      only appear if the corresponding Local or Central
      directory record field is set to 0xFFFF or 0xFFFFFFFF.

      Note: all fields stored in Intel low-byte/high-byte order.

        Value      Size       Description
        -----      ----       -----------
(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Original 
        Size       8 bytes    Original uncompressed file size
        Compressed
        Size       8 bytes    Size of compressed data
        Relative Header
        Offset     8 bytes    Offset of local header record
        Disk Start
        Number     4 bytes    Number of the disk on which
                              this file starts

So only those marked as 0xFFFF or 0xFFFFFFFF in the local/central directory record should appear in the 64 extra block.

In the case you mentioned the rest of the fields (uncompressed, compressed and disk) must be properly informed and read from the local/central.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.