A commenter on an other post of that article noted that technically there's no reason for the central directory to be right before the EOCD so seeking backwards from the EOCD by the size of CD is just incorrect. In fact zip was designed such that the central directory could be split across multiple disks (and later files), so it was not possible to guarantee a simple backwards jump from the EOCD to the start of CD.
It's talking about how the EOCD contains both the size of the central directory and the offset of the start of the central directory, which is redundant. So we end up with some tools honoring the offset, while some subtract the size from the EOCD.
There's a whole extra level of archive file format tooling gotchas that one misses out on when one assumes "UNIX" for everything, and does not account for "FAT", "NTFS", "HPFS", and even "OpenVMS".
Or ZIP64. (-:
* https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
* https://github.com/mihula/ProDotNetZip/blob/main/src/Zip/Zip...
Then you have people on Linux or macOS who might also use LibreOffice, Apples Office suite, or something else entirely.
And given MS Office is the de facto standard, you’ll often see people open OOXML documents within non-MS office suites.
After all, OOXML is an open standard (sarcasm).
ODF (the document formats favoured by most other office suites) is also ZIP-based XML. So they too could be vulnerable.
I do wonder, since a lot of tools outside of the MS ecosystem can read Office files (e.g. LibreOffice and Google Docs as well as plenty of other online tools), if indeed the hack as described by the article is possible. One would just need to figure out the ZIP stacks used by said tools.
There was a time when passing ZIP files around was a very popular method of software distribution, and things like this were gotchas that had to be watched for. It was widely known, at least amongst sysops, that the varied toolsets that handled ZIP archives were functionally different. And there were scanners and sanity checkers, and bugfixes to PKUNZIP, that dealt in this stuff for uploaded files and FREQ responses.
Did people exploit the differences? Yes. Although it was mainly on the level of creating prank ZIP files on non-Microsoft operating systems with 8.3 filenames such as "PRN" or "CLOCK$".
* https://groups.google.com/g/alt.comp.virus/c/zLV-Y2a71gs/m/U...
However, the truly terrible idea of self-extracting archives was popular, which meant that archives with "interesting" arrangements of the archive within the overall file were widespread. ZIP comments were also liberally applied and altered by pretty much every BBS that passed an archive along. And the Unix people wanted to be able to use pipes, something that the MS-DOS original never had to cater for.
Also, there were people who exploited the fact that different tools took different things as gospel. Even within the past decade one can find people still being caught out by the fact that there's a header field that instructs what the pathname separator character(s) used are; and that ZIP tools that expect non-seekable streams operate differently to ZIP tools that expect seekable regular files.