They serve no purpose, except proving that file formats not starting at offset
0 are a bad idea.
Au contraire–they are a wonderful idea. If, say, a polyglot pdf+executable could gain code execution enough to execute itself as a binary, it could just as easily execute far more dangerous code while being far less likely to tip off an automated scanner. So it goes for many of the other stackable formats.
The benefits seem to far outweigh the drawbacks. As an example, look at the concept behind ext[234]fs migration in btrfs (which is not fixed to block 0 in a volume)–Take an ext4 filesystem, generate new inodes pointing at the original b-trees, and away you go! You get a filesystem that is valid ext4 (retaining the old data), and valid btrfs (which, being copy-on-write, doesn't destroy the old data.)
Also, these aren't all "file formats not starting at offset 0". For example, PDF files must start with %PDF. The problem is that several tools are happy with a PDF prefixed by noise. That probably is because PDF, originally, was a text format (just as PostScript still is). Compression of content was added later, but the structure still is pure ASCII (for example, the table of contents at the end of a file has file offsets in ASCII, and you can find the start of the table of contents as an ASCII string, too).
Ange was at 44CON[1] this month and did a great talk about Windows PE binary formats. He also ran a workshop on the PE binary format. Awesome guy to talk to, just make sure you don't have any fez's lying around ;)
How one of the comments suggests to have the COM write-out an EXE, you could do something similar on OS X. Applescripts can be entirely in a resource fork, have that write-out a macho-o and have the data fork be your previous polyglot.
Is it possible to do the (somewhat) simpler (in concept, not process) task of making gif or png that is also a valid HTML file? It might be kind of tricky given they both have magic numbers at the head...but perhaps there is some way to trick a browser into ignoring the "garbagey" bits?
I remember that the NE executable files had hardly any virus I always wondered why?
Is it the format or the fact that they where not used that much (due to the short presence of Win3)?
The benefits seem to far outweigh the drawbacks. As an example, look at the concept behind ext[234]fs migration in btrfs (which is not fixed to block 0 in a volume)–Take an ext4 filesystem, generate new inodes pointing at the original b-trees, and away you go! You get a filesystem that is valid ext4 (retaining the old data), and valid btrfs (which, being copy-on-write, doesn't destroy the old data.)