The bytes after the last section
A PE file often does not end where its sections do. What sits in the gap is frequently the entire point of the file.
Add up where every section in a PE file ends. Compare that to the size of the file on disk. The two frequently disagree, and the difference is the overlay: data appended past the end of the mapped image.
The loader does not map it. Nothing in the section table describes it. As far as execution is concerned it is not there, and the program reads it back off disk itself if it wants it.
Which it usually does, because the overlay is where installers keep the thing they install. A self-extracting archive is a small extractor with a large archive appended. An NSIS or Inno installer is a stub plus a compressed payload. In those files the overlay is not an oddity, it is the cargo, and the executable part is the crane.
Two things follow that are worth holding onto.
The signature lives out there too. The Authenticode certificate table sits in the same region past the sections, which is why signature verification deliberately excludes its own bytes from the hash it computes.
Size is a readable field. You do not need to parse the overlay to learn something from it. A utility that presents itself as a few hundred kilobytes of code and carries forty megabytes behind the last section is describing a payload, and whether that payload is a legitimate bundled runtime or something else is a question you now know to ask.
The overlay is not suspicious. Most of the installers on any Windows machine have one. It is simply a part of the file that a parser reading only the section table will never look at, and it is regularly the largest part.
More of this
New posts on what a file tells you before you run it: headers, signatures, manifests, overlays, the fields most inventory never reads. Only when there is something worth the write-up.
We intend to offer a tool that does this across every file on an endpoint. You get one message when you can use it.