One of the most creative ways of constructing PE files come not from malware authors, but from so-called DemoScene. Squeezing in everything possible in the smallest possible file is a form of an art. It has roots in competitions that forced the participants to use very restrictive environment to produce the best demo effect possible. From a file format perspective, this resulted in many cool productions where the PE file structure looks completely non-sensical, almost like non-PE, yet when executed, still produces some sort of demo effect.

See for yourself. Is this a valid PE file?

There is no visible DOS Stub, no strings, no library names, no API names, it looks like an old DOS MZ file. At least at a first glance.

It actually is a PE file though.

Many PE Editors, Viewers, and Dumpers have a serious problem analyzing this sort of files, because they can’t handle exceptions that happen during processing. They are typically triggered by some of the PE header structure fields being re-used by demos to store actual code/data for the presentation (no byte is wasted). These values tend to be random, and definitely outside of the boundaries of a file, or image in memory. Operating system loader ignores many of such out-of-bound indexes, while PE tools tend to ‘trust’ the content, and interpret them as valid values, and… eventually fail.

I won’t be naming names, but can confirm that among a couple of tools that I tested, some failed to load this file, some didn’t show proper code from the entry point, because they miscalculated the offset where the code is located.

Overall, it’s good to test your parsers by including such PE curiosities in your test bed (Scene.org is a great source for these, but don’t forget Corkami repo – Ange took the art of hand crafted PEs to a completely new level).