Beyond Hashes: Detecting Supply Chain Backdoors with Code Genome

TLDR: Supply chain attacks like the xz-utils backdoor (CVE-2024-3094) prove that traditional file-hash verification is insufficient for detecting malicious code injection. The Code Genome framework offers a solution by lifting binary code into a canonical intermediate representation to compare functional semantics rather than static bytes. This approach allows researchers to identify anomalous code changes even when attackers use sophisticated obfuscation or build-time modifications to bypass standard integrity checks.

Software supply chain security has reached a breaking point. We have spent years relying on cryptographic hashes and Software Bills of Materials (SBOMs) to verify that the code we pull from repositories matches the code we deploy. The xz-utils incident shattered the illusion that these methods are sufficient. When an attacker can compromise a build pipeline or inject malicious code during the compilation process, a static hash becomes a liability rather than a security control. We need a way to verify that the behavior of the binary matches our expectations, regardless of how the binary was packaged or compiled.

The Semantic Gap in Binary Analysis

The core problem in supply chain verification is the semantic gap between the source code and the final distributed binary. When you compile code, compiler optimizations, different build environments, and even minor version changes in dependencies can result in vastly different binary structures. If you rely on simple byte-level comparisons or cryptographic hashes, you will trigger false positives constantly.

Attackers exploit this noise. By introducing subtle, functional changes—like the indirect function calls used in the xz backdoor—they can hide malicious logic that performs a specific task, such as hooking into sshd for remote code execution, while keeping the overall binary footprint looking "normal" to standard scanners.

The Code Genome framework addresses this by moving the analysis from the byte level to the functional level. Instead of looking at the binary as a blob, the framework disassembles the code into individual functions and lifts them into an intermediate representation (IR) using RetDec. Once in this IR format, the framework applies a series of optimization and canonicalization passes. These passes strip away the noise introduced by different compilers or optimization flags, leaving behind a "gene"—a semantically meaningful fingerprint of what that specific function actually does.

From Fingerprints to Detection

When you compare two binaries using Code Genome, you are not comparing hashes. You are comparing the functional genes of every function within those binaries. If a function in a new update has a different gene than the corresponding function in a known-good version, you have a high-fidelity indicator of an anomalous change.

During the research presentation, the team demonstrated this by analyzing various versions of the xz library. While the file hashes changed frequently due to legitimate updates, the functional genes remained consistent across stable releases. However, when the backdoor was introduced in version 5.6.0, the framework immediately flagged a divergence in the functional logic.

To use this in your own research or penetration testing, you can integrate the framework into your CI/CD pipeline or use it to audit third-party dependencies. The tool provides a command-line interface, genediff, which allows for rapid comparison:

# Compare two binary files to identify functional differences
./cg genediff liblzma.so.5.6.0.github liblzma.so.5.6.1.distro

The output provides a clear view of which functions have changed, allowing you to focus your manual reverse engineering efforts on the specific code blocks that deviate from the baseline. This is significantly more efficient than diffing entire binaries in a disassembler like IDA Pro or Ghidra without knowing where to look.

Real-World Pentesters and SBOM Integrity

For those of us performing security assessments, this framework changes how we approach OWASP A06:2021-Vulnerable and Outdated Components. We often see organizations blindly trusting the SBOM provided by a vendor. As the researchers highlighted, an SBOM is just metadata. If a vendor makes a mistake or intentionally omits a library to avoid licensing issues or security scrutiny, the SBOM will not reflect the reality of the binary.

By generating your own SBOM from the binary using Code Genome and comparing it against the vendor-provided metadata, you can identify discrepancies. If the vendor claims a package contains specific components but your functional analysis reveals the presence of additional, undocumented code, you have found a critical finding. This is a powerful technique for auditing closed-source software or verifying the integrity of critical infrastructure components where you cannot afford to trust the vendor's word.

Moving Forward

Defenders must stop treating binaries as black boxes. While the Code Genome framework is a significant step forward, it is not a silver bullet. Disassembly remains an undecidable problem, and function boundary identification can be tricky in stripped binaries. However, by focusing on functional semantics, we move the goalposts in favor of the defender.

If you are currently auditing software supply chains, start by establishing a baseline of functional genes for your critical dependencies. When the next major supply chain vulnerability hits, you will not be waiting for a vendor advisory or a CVE update. You will be able to verify the integrity of your own environment by checking if the functional behavior of your binaries has shifted. The tools are open-source and ready for integration. Start building your own knowledge graph of functional genes today, because the next backdoor is likely already sitting in your dependency tree.