NES ROM is Also a ZIP File That Contains Itself

https://vigrey.com/blog/this-nes-rom-also-zip-file

Pretty interesting. Vi Grey takes advantage of zip files' loose header specification to make a ROM that contains itself. The ROM can be burned to a cart, ripped later on, renamed to a zip, and then unzipped to retrieve the same ROM.

tl;dr: A zipfile contains the following elements in order.

1. A prefix, ignored by unzippers, often used to hold a self-extract tool.
2. The zipfile body, which consists of compressed data, a directory structure, and an "end of central directory" beginning with a 4-byte marker (50 4B 05 06).
3. Comment data. Some sources claim that this should not exceed 48000 characters (source), and the unzipper may fail to find the zipfile body if comment data contain the marker for the end of central directory.

I can see two ways to fit an iNES or NES 2.0 ROM into a zipfile: one by putting the the zipfile body in PRG ROM, the other by putting it in CHR ROM.

Zipfile body in PRG ROM
The prefix contains the 16-byte header and the executable part of PRG ROM. The zipfile body pads out the rest of PRG ROM up to just below the vectors (for NROM) or the fixed bank (for UNROM). Mappers with 32K bank switching and unspecified power-up state, such as BNROM or AOROM, are not usable, as they may power up within the zipfile body. The featured article uses this technique with NROM.

Zipfile body in CHR ROM
The prefix contains the 16-byte header, the entire PRG ROM, and the used portion of CHR ROM, and the zipfile body sits in the rest of CHR ROM. This would most commonly use oversize CNROM or another mapper that allows CHR ROM 2 to 4 times as large as PRG ROM, as the source code in the zipfile body has to correspond to everything that comes before it.

If anything, it's an interesting way to "force" GPL compliance on ROM sites.

Depending on what we get in NESdev Compo 2017 category 2, it might be possible to apply this in part to Action 53 volume 4. Of the 32 outer banks (each 32768 bytes), the entries use 21, and the menu uses 1. This leaves 10 banks or 320 KiB. The menu source zipfile is 123 KiB (or just under 4 banks) without the "make your selection now" WAVE file, which I could make lossy in the ROM version of the source code. So if we don't get more than 192 KiB of category 2 or post-compo material, I could hide the source code for the menu (even if not the individual games) in this manner. That way anyone who dumps it with a Kazzo can make a multicart.

The data doesn't have to be compressed I think, compression while most often used is fully optional.

Also I'm fairly sure there is a directory arborescence at the end of the file, something most other archive formats lacks; which makes zip unique as is it allows random access to any file without decompressing other files.

If the ROM contains a zipped copy of itself, it absolutely has to use compression, otherwise it won't fit.

The ROM contains a zipped copy of its source code. Part of the "compression" could merely involve the source code generating some humongous LUTs.

If you wanted a RAR or 7Z file, you could literally just append it onto the end of the NES file.

The idea is that even if you burn the ROM image onto a cartridge and someone else dumps the cartridge to a ROM image, she can still extract a valid zipfile. The append trick is practical only for mappers that support large CHR ROM, not for CHR RAM mappers or NROM. For CHR RAM mappers, you need somewhere to put the fixed bank, and for NROM, you need somewhere to put the vectors and CHR ROM. This trick puts them in the file comment.