Firmware binary diffing and patch analysis: finding silently-fixed vulnerabilities

Silent patching is common, not an exception. A security fix bundled into a routine firmware update competes for release-note space with feature changes and bug fixes that have nothing to do with security, and a vendor weighing early disclosure against giving attackers a blueprint often chooses brevity. NIST frames the underlying problem — not the silence itself, but why patching discipline matters regardless of how much a vendor says — directly in NIST SP 800-40r4, the Guide to Enterprise Patch Management Planning: "there are many in the world who continuously search for and exploit flaws in software," which is exactly why a device still running the pre-patch image stays exposed for as long as the patch sits undeployed, whether or not its advisory text ever named the flaw. A firmware fleet with dozens of SKUs and a slow update cadence (see our firmware OTA update security guide for what a healthy update pipeline actually checks) can leave that gap open for months.

Comparing two firmware builds byte-for-byte mostly fails, because a recompile — even with no logic changes at all — can shift every function's address, reorder sections and change compiler-generated padding. BinDiff, described in its own manual as "the leading executable-comparison tool for reverse engineers that need to analyze patches, malware variants, or are generally interested in the differences between two executables," instead works on structure: "every function gets a signature, based on the structure of the (normalized) flow graph of the function," built from the number of codeblocks, the number of edges between them, and the number of calls to subfunctions. Functions whose signature occurs exactly once in each binary become an initial match; from there BinDiff "uses callgraphs... to generate more matches," progressively drilling down through ambiguous cases to basic-block-level comparison inside each matched function pair.

A function that keeps an identical structural signature between the two builds is unchanged — safe to ignore for this purpose. A function whose flow graph changed shape, especially one touching input parsing, memory handling or an authentication check, is exactly where to look first; our weak cryptography in embedded firmware and memory corruption in embedded firmware guides cover what those changed functions tend to look like once found.

The short answer is that diffing a patch is not a theoretical shortcut — it has been a demonstrated, automatable technique for well over a decade. Brumley, Poosankam, Song and Zheng's 2008 IEEE Symposium on Security and Privacy paper, Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications, showed that comparing a patched binary against its pre-patch version could be enough for an automated system to reconstruct a working exploit for the vulnerability the patch fixed, often faster than a defender without the same tooling could read and act on an advisory. That result is the concrete reason "the release notes didn't mention a CVE" buys a device maker far less time than it appears to: the moment an update is public, every device still on the older image is running known-vulnerable code whether or not that vulnerability has a public identifier yet. CISA's Known Exploited Vulnerabilities (KEV) catalog exists for the same reason from the defender's side — tracking what is actually being exploited in the wild, not only what a vendor chose to describe — and pairing KEV with FIRST's EPSS score is the practical way to prioritize which diffed finding needs a fix shipped first; see our KEV and EPSS prioritization guide for how that scoring actually works.

SoftWSP's automated pipeline does not run BinDiff-style, function-level structural diffing — that is the specialist analyst workflow described above, done by a person with BinDiff or the open-source Diaphora project against two unpacked images. What SoftWSP's scan actually does, across both a firmware image and a newer version of the same image, is the same binary-analysis identification our firmware SBOM guide covers: unpack each image, identify the software components and versions present (the same entropy and signature analysis our firmware entropy analysis guide describes helps separate unpacked code from encrypted or compressed regions first), and match each component version against known CVE data, CISA's KEV catalog and FIRST's EPSS score. Comparing that component inventory before and after an update shows which library or module actually changed version — the version-level signal a patch diff narrows down to before any function-level work starts.

AI's role is narration, not detection, on top of that deterministic matching: it writes the plain-language summary of which components changed, which CVEs that version bump closes, and which newly matched CVEs (KEV-listed or high-EPSS) deserve priority attention — every sentence citing the specific component, version and CVE/KEV/EPSS record behind it, the same evidence-citing rule SoftWSP applies to every report it produces. An engineer reviews every finding before it ships. If a changed component's version alone doesn't explain a known fix, that is flagged for an analyst to take further with function-level diffing tools — SoftWSP does not claim its automated scan performs that deeper structural comparison itself.

See our OWASP Firmware Security Testing Methodology guide for where this kind of component-level comparison fits into a full testing workflow, or device & firmware security services for getting a specific firmware update diffed.

This guide draws on the BinDiff manual (zynamics/Google), binwalk's README (ReFirmLabs), Brumley et al.'s 2008 IEEE S&P paper, NIST SP 800-40r4 and CISA's KEV catalog, read directly 2026-11-09.