So, if you just append a ZIP file to another file, it will screw up all the internal pointers in the ZIP file. If you overlay a file on the beginning of the ZIP, most of it should be recoverable, though.
Another clever hack is that you can put a batch file in the beginning of the ZIP with the compression level set to "none", rename it to .CMD or .BAT, and run it like a batch file. If said batch file locates and unzips itself, you've got a self-extracting archive.
Now, it can break if your "other" file happens to include the magic bytes. But that's rare enough that you only have to be aware that it can happen.
A 4-byte sequence has 2^32 possible values. For the file not to contain the zip magic, all N-3 positions would have to have one of the 2^32-1 non-zip magic values. The probability that it doesn't contain a zip magic is then
P(nonzip) = ((2^32-1)/(2^32)) ^ (N-3)
And the probability that it does have a zip magic is P(zip) = 1-P(nonzip).
A 1 gigabyte file has about a 20% chance to contain a zip header. A 10 gigabyte file has about a 90% chance.
(Maybe?)
A robust zip decoder can beat those odds.
It can bail on a nominal start position by considering a bit more than the local file header signature magic word.
The next two bytes is a minimum version needed to extract and its legal values are sparse. A bit further comes 2 bytes giving the compression method which also has sparse values. I'd guess sparse values (small integers) are more likely to be found in a "random" non-zip stream but would still reduce the collision probability.
Then there are CRCs. These can greatly reduce the collision probability at the cost of the decoder doing speculative work which gets thrown away if a CRC fails to replicate.
$ file some.*
some.jpg: JPEG image data, JFIF standard 1.02, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 64x736, components 1
some.zip: Zip archive data, at least v1.0 to extract
$ cat some.* > new.jpg
$ file new.jpg
new.jpg: JPEG image data, JFIF standard 1.02, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 64x736, components 1
$ unzip -l new.jpg
Archive: new.jpg
warning [new.jpg]: 1557 extra bytes at beginning or within zipfile
(attempting to process anyway)
Length Date Time Name
--------- ---------- ----- ----
0 2022-04-28 21:53 stuff/
5 2022-04-28 21:53 stuff/a
5 2022-04-28 21:53 stuff/c
5 2022-04-28 21:53 stuff/b
--------- -------
15 4 files
$However Gmail now rebuilds images to protect against malicious code and it completely strips the appended files from the image.
Edit: he told me it was because his boss had journalling turned on and saw every email sent and received in the company and he thought it was funny to bypass the boss for personal stuff.
Example: you have duck.jpg (21500 bytes) and you want to hide flower.jpg (37733 bytes). Do this to create a larger file (59233 bytes):
Anyone looking at bigger-duck-file.jpg will see the duck. Every image viewing program I tried displays the duck and none of them complain about the extra bytes (the hidden image) at the end of the file.The recipient can extract the hidden file as follows:
You would have to tell the recipient the size of the hidden file by some other means. But there might be a simple command-line way to determine where the image data for duck.jpg really ends in the bigger file, so maybe you wouldn't need that step.