I don't understand the code itself, but here's Debian's patch to detect overlapping zip bombs in `unzip`:
https://sources.debian.org/patches/unzip/6.0-29/23-cve-2019-...
The detection maintains a list of covered spans of the zip files
so far, where the central directory to the end of the file and any
bytes preceding the first entry at zip file offset zero are
considered covered initially. Then as each entry is decompressed
or tested, it is considered covered. When a new entry is about to
be processed, its initial offset is checked to see if it is
contained by a covered span. If so, the zip file is rejected as
invalid.
So effectively it seems as though it just keeps track of which parts of the zip file have already been 'used', and if a new entry in the zip file starts in a 'used' section then it fails.
I wonder if this has actually been used for backing up in real use cases (think how LVM or ZFS do snapshotting)?
I.e. an advanced compressor could abuse the zip file format to share base data for files which only incrementally change (get appended to, for instance).
And then this patch would disallow such practice.