Why Deep Binary Analysis Matters
Version numbers alone are not enough. Real systems carry renamed files, bundled libraries, installer leftovers, vendor forks, embedded firmware, signed and unsigned binaries, and archives full of software that should not be unpacked blindly on the first pass.
Windows binaries can carry version resources, publisher strings, original filenames, checksums, and Rich Header toolchain evidence. Those fields help distinguish Microsoft, Adobe, Python, Electron, and vendor-specific components that share common filenames.
PE, Mach-O, and Linux kernel-module signatures are separated into content-integrity evidence and trust verification. A signed content digest match means the file still matches the embedded signature digest; it does not prove that the signer is trusted, unrevoked, or accepted by platform policy.
Linux and embedded binaries can expose build IDs, interpreters, architecture, dynamic dependencies, linking style, and hardening posture. That context matters on routers, appliances, containers, ground systems, and offline mission hardware.
Archives are containers, not proof that their contents are installed. VersionGopher records archive format, path, size, hash, and safe follow-up guidance for formats such as ZIP, TAR, RAR, 7-Zip, Microsoft Cabinet/MSU, and firmware-style containers without unpacking untrusted data during the initial collector scan.
Signature Results
VersionGopher™ keeps signature reporting in separate lanes so analysts can tell content integrity apart from signer trust. The collector stays small: it records bounded signature evidence and, for PE files, Mach-O code signatures, and Linux kernel modules where supported, compares embedded signed-content digests without network access, catalog database lookups, keyring policy decisions, revocation checks, or CA-chain policy decisions.
- Valid platform signature: when a platform verifier such as Windows Authenticode reports a signature as valid, the UI can show that status separately from collector-only evidence.
- Signature present but suspicious: a content-digest mismatch means the signed digest does not match the scanned bytes. Treat that as strong tamper evidence. Unsupported, malformed, or parse-error signatures are review cues.
- Missing or blank: no embedded signature evidence was available, or the format has no universal signing model. Catalog-only Windows signatures, macOS trust decisions, and Linux kernel keyring acceptance require platform APIs or policy state and are not proven by portable parsing.
Expired certificate dates need context. Timestamped Authenticode
signatures can remain valid after the signer certificate's
NotAfter date. VersionGopher reports these dates as
provenance, but a date alone is not the same thing as a hash mismatch or
a failed trust decision.
Backend trust enrichment classifies CRL, OCSP, authority-information, and timestamp URLs from signature metadata without fetching them during scan browsing. Recognized public PKI providers are labeled for review; private, loopback, link-local, reserved, malformed, or unsupported endpoints are blocked and raised as suspicious trust-endpoint evidence. This prevents a malicious binary from turning certificate URLs into backend callbacks or private-network probes.
Ordinary Linux executables and shared objects still have no universal embedded signature equivalent. Linux kernel modules are the exception: they may carry an appended PKCS#7-style signature trailer that can be detected and, when supported, compared against the signed module payload.
The roadmap adds optional backend trust checks that can validate signer chains, revocation, timestamps, catalog signatures, and kernel-module keyring context when a deployment has the right trust stores and outbound policy. Those checks will remain separate from collector evidence so analysts can see exactly what was parsed locally and what was verified later.
What Analysts Get
- Better CVE triage because product, vendor, path, platform, and component evidence are visible beside the match.
- Fewer common-name false positives such as unrelated files named
fusion.dll,control.exe, orsudo.exe. - Toolchain clues such as Visual Studio family evidence from PE Rich Headers when the binary preserves it.
- Signature and provenance clues such as embedded PE Authenticode tables, signed-content digest status when available, Mach-O CodeDirectory identifiers, entitlement blob presence, and explicit ELF not-applicable status.
- ELF runtime clues such as needed libraries, loader path, static versus dynamic linking, and hardening signals.
- Archive follow-up records that tell an operator where packed software exists without turning the collector into an unpacker.
Result Row Indicators
Result rows keep the main inventory table compact. Small labels beside a name or path are evidence hints, not vulnerability verdicts.
- Signals: binary forensic evidence exists for the row, such as PE signature data, Rich Header/toolchain clues, checksum status, ELF hardening, or related provenance. Click the row to review the evidence.
- Review: one or more binary forensic signals have a higher review severity and should be inspected before treating the row as routine inventory.
- Filename only: the collector captured a filename without a directory path. This is not a CVE, trust, or malware warning. It should not appear for normal Windows paths such as
C:\Windows\System32\kernel32.dll, UNC paths such as\\server\share\tool.exe, or POSIX paths such as/usr/bin/ssh.
Managed Runtime Integrity
Windows trusted-runtime locations such as GAC_MSIL,
Framework, Framework64, and WinSxS
are handled as parent component evidence. VersionGopher™ collapses
noisy file-level .NET CVE matches into a serviced parent component so an
analyst is not told to patch the same framework DLL dozens of times.
That does not make these paths boring. They are high-trust execution surfaces. Files in those locations with unexpected publisher or product identity, missing identity, unusual hashes, or drift from peer systems should be reviewed as managed-runtime integrity signals.
- Expected Microsoft .NET/GAC/framework evidence is grouped for parent-level servicing review.
- Unexpected non-Microsoft identity in managed runtime paths is elevated as suspicious integrity evidence.
- VersionGopher™ keeps CVE exposure and tamper/integrity review in separate lanes so false positives do not hide real rootkit-style concerns.
Why This Helps In The Field
Security teams often inherit systems they did not build. A clean package manager view may not exist, and the machine may be offline, embedded, or only briefly accessible. Deep binary evidence lets an analyst answer practical questions quickly:
- Does this binary look like the product the CVE matcher thinks it is?
- Was it built with an unexpected toolchain for this environment?
- Does the format provide signing evidence, and is VersionGopher reporting evidence or verified trust?
- Is the loader, architecture, dependency set, or hardening posture unusual?
- Are there archives or FPGA/firmware-style payloads that need controlled follow-up analysis?
How This Relates To Software Genomics
Binary and archive evidence become more useful when scans are compared over time or across authorized groups. Repeatable scans of the same fleet can support drift review, while forensic images, random uploads, M&A evidence bundles, and downloads directories should usually be read as software similarity.
See Software Genomics, Groups, And Drift for guidance on when a Group represents a real fleet baseline and when it is only an organizational container.
What VersionGopher Does Not Do Automatically
The collector stays small and cautious. It does not unpack archives, execute files, install agents, or rely on internet access. When an archive needs deeper review, extract it in a controlled location and run a second scan against the extracted directory.