What a version resource actually proves
The publisher name shown by most inventory tools is metadata a compiler wrote. It is useful, and it is not evidence.
Open the properties dialog on a Windows executable and you get a company name,
a product name, and a file version. Most inventory tooling surfaces the same
three fields. They come from the VS_VERSIONINFO structure in the binary’s
resource section, and it is worth being precise about what their presence
establishes.
Where the fields come from
A developer writes them into a resource script (a .rc file), or supplies
them through assembly attributes, and the linker embeds the result. The
structure is a tree: a fixed VS_FIXEDFILEINFO block holding binary version
numbers, and a StringFileInfo block holding the human-readable strings, keyed
by language and codepage.
Nothing in that process involves verification. CompanyName is a string
literal. A build that declares itself as coming from a well-known vendor will
report exactly that, and every tool reading the field will repeat it.
The two versions disagree more often than you would expect
VS_FIXEDFILEINFO carries FileVersionMS and FileVersionLS as packed
integers. StringFileInfo carries FileVersion as text. They are populated
separately and they drift: a build pipeline that stamps one and not the other
is common enough that a mismatch is weak signal rather than strong.
Where it becomes interesting is when ProductName and OriginalFilename
disagree with the file’s actual name on disk. OriginalFilename records what
the binary was called when it was linked. A file renamed after the fact keeps
the original inside it. That single field resolves a surprising number of
“what is this thing” questions on its own.
How to weight it
The useful position is that a version resource is an unauthenticated claim of identity. It is genuinely informative: most software is not lying, and for internal tooling with no signature it is frequently the only vendor information present.
But it should be weighted differently from a signature chain, and a system that reports both at the same confidence is discarding information it already has. A binary whose vendor comes from a valid Authenticode chain and a binary whose vendor comes from a string in the resource section are not equally attributed, even when they name the same company.
That distinction is exactly what a graded confidence value is for. Collapsing it into a single “vendor” column loses the part that matters.
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.