Does call-graph context improve binary function embeddings? An empirical study

What happened on this date

At 11:44 UTC on 2026-08-03, arXiv received v1 of "Pretraining on Call Graphs: When Binary Analysis Tasks Profit From Context" (primary category cs.SE). Binary function embedding models encode the semantics of compiled code as vectors for reverse engineering tasks such as binary code search, vulnerability detection and malware classification, and some prior work enriches those embeddings with call-graph information. The authors ran a range of graph-based models on top of two state-of-the-art embedding models. The abstract reports several findings: gains in binary code similarity detection (BCSD) do not necessarily generalize to semantic or syntactic downstream tasks; optimizing for semantic similarity tends to correlate with worse syntactic performance; call-graph enhancements significantly improve embedding robustness, especially where the base models struggle; and the added context helps namespace-related functions more than functions that implement individual logic.

Why it matters for people protecting app logic

Binary similarity cuts both ways. Analysts use it to match functions in your binary against known code and skip a lot of reading; you can use it to look for your own code reused inside someone else's product. This paper adds two cautions. First, functions are not isolated: call relationships carry information, so even with symbols stripped, neighbors and call structure can help a model recognize a function, particularly library- or namespace-related ones. Second, benchmark numbers do not transfer automatically: a method that does well on similarity detection can do worse on other tasks. Whether you are estimating how recognizable your own code is or picking a tool to find clones, measure on the task you actually care about rather than trusting a single headline metric from a paper or vendor. These are research findings, not statements about any particular commercial tool.

Concrete checks

First, confirm that release builds really strip debug symbols and unnecessary exported symbols, and add that to the release checklist. Second, assume third-party library code will be recognized quickly; what deserves protection is not which libraries you use but your own business rules and data, and whatever can move server-side should. Third, if you plan to use a similarity tool to monitor for clones, first run an internal test against your own builds across versions and compiler settings, record recall and false positives, and only then decide whether to rely on it. Fourth, after obfuscation or other transformations, re-run the similarity measurement so that any change is measured rather than assumed.

Your checklist

• Confirm release builds strip debug symbols and extra exports
• Assume libraries are recognized; move core rules server-side
• Test similarity tools on your own builds for recall and false positives
• Re-measure similarity after transformation instead of assuming