Skip to content
Sparkle In Technology

How SourceGuard finds vulnerabilities in a compiled binary

Disassembly, intermediate representation, simulated execution, and signature comparison — in four stages, with no source code and no reliance on version metadata

InputCompiled binary
ReferenceVulSource database
VerdictUnpatched, fixed, not vulnerable
The four stages, left to right

The method

The engine first disassembles the target binary and converts its executable instructions into a structured intermediate representation. That lets us analyse program behaviour rather than version strings or file fingerprints

Building on that representation, the analysis engine simulates key execution paths to extract stable behavioural and structural features. Those features are compared against reference signatures in VulSource — both vulnerable and remediated patterns — so the platform can determine whether the observed binary more closely matches an unpatched state, a fixed state, or a state that was never vulnerable

This matters most where version metadata is incomplete, altered or unreliable — vendor firmware, statically linked libraries, backported patches. By reading what the binary contains and how it behaves, precision improves and both false positives and false negatives fall

A version number is a claim,
the instruction stream is the evidence

SourceGuard · vulnerable vs. patched
Side-by-side comparison of a vulnerable binary and its patched counterpart, showing the matched code region

Evidence

Vulnerable and patched, side by side

The matched region is shown in both states, so an engineer can confirm the finding — and a vendor can be shown exactly what still needs fixing