3 ms·
Why can't this algorithm work reliably: 1. Begin linear search backwards from end of file 2. If magic constant found, push onto stack of possible locations 3.
by xenadu02 10y ago
Why can't this algorithm work reliably:
1. Begin linear search backwards from end of file
2. If magic constant found, push onto stack of possible locations
3. Once 32k has been reached stop searching
4. For each location on the stack, validate the rest of the header and that the remaining comment length matches the recorded length.
5. The first location to validate as a correct header is chosen
This should account for the appearance of the magic header in comments or data preceding the end of directory entry.
Have I missed something?
- diggernet 10y agoThat should work reasonably reliably, and is essentially what TFA describes as the behavior of 'unzip'. But it then goes on to say, "The zip file spec does not allow this arbitrary data [at the end of a zipfile], so unzip is non-conformantly tolerating this data." So I think what you missed is pedantry. :)
- ambrop7 10y agoYes you have missed that a valid header may appear by chance somewhere near the end of main zip data. Because your algorithm will prefer picking up headers toward the front, it might misinterpret a valid file, even one without a magic number in the comment; if the last 64k-(actual header+comment size) happens to contain an apparently valid header.
- j_s 10y agoThis happens with nested .ZIPs.
- grkvlt 10y agoYes. Step 4, specifically "the remaining comment length matches the recorded length" will fail in the presence of appended data, as there is no end of comment or end of record marker. This is exactly how the file failed in the article, it used that algorithm and found zero valid headers.