This is an easy and popular bug to write. The ZIP file format (which is used for JAR files as well), which puts the header at the end, is truly the sin that kee

This is an easy and popular bug to write. The ZIP file format (which is used for JAR files as well), which puts the header at the end, is truly the sin that keeps on giving. A consequence of this choice is that ANY file concatenated with a ZIP file is a ZIP file (and the same therefore goes for JAR files as well.) So if you concatenate an MSI file with a ZIP/JAR file, your MSI file detector will look at the file and go "yeah, looks good!", and your ZIP/JAR file detector will also say yes. (This also shows off the hazards of automatic filetype sniffing.) This is related to one of the very oldest Android rooting vulnerabilities. The update.zip files use the signed JAR file format, where the file contains a signature on its own contents. Naturally the signature can't cover the entire file; it only covers the contents referenced by the header. But the sin-that-keeps-on-giving strikes even harder here: The end-of-file ZIP header also has an end-of-header comment field, of arbitrary size! This means that a single file can actually have MULTIPLE valid ZIP headers. Which means two different tools can interpret the file as two different ZIP files (much as the bug here can interpret the same file as either a ZIP or an MSI.) Don't do drugs, kids. And don't do automatic filetype detection. And don't do ZIP/JAR files if you can avoid it. And for the love of god, don't put your header at the end.