---
title: 'Bin2vec: Binary Program Representation Methods'
url: https://www.emergentmind.com/topics/bin2vec
type: topic
---

# Bin2vec: Binary Program Representation Methods

Searching arXiv for the specific Bin2vec papers and closely related binary-analysis work.
Bin2vec denotes binary-program representation methods that map compiled software into machine-usable vectors for downstream analysis. In the literature summarized here, the name is used for distinct systems: a graph-based method for learning distributed representations of binaries for security tasks [2002.03388], and a later multi-view framework for interpretable and auditable binary similarity and plagiarism detection [2512.02197]. Both operate directly on binaries rather than source code, but they differ substantially in representation, supervision, and evaluation.

## 1. Scope, naming, and main variants

The term *Bin2vec* is not monosemous. The sources here describe at least two binary-analysis systems that share the name, plus later work that re-evaluates one of them in vulnerability discovery [2508.15042].

| Variant | Core representation | Main task focus |
|---|---|---|
| Bin2vec (2020) | Computational program graphs processed by GCNs | Functional algorithm classification; vulnerability discovery |
| Bin2Vec (2025) | Five-view static and dynamic embeddings with cosine similarity | Code similarity; code plagiarism detection; auditing |

The 2020 method introduces “distributed representations of binary executable programs” learned from computational program graphs [2002.03388]. The 2025 method introduces “Interpretable and Auditable Multi-View Binary Analysis for Code Plagiarism Detection,” explicitly combining structural and behavioral evidence and keeping views separately inspectable [2512.02197].

This naming overlap is a recurrent source of confusion. It should also be distinguished from unrelated work on binary vectors in other domains, such as “Binary Paragraph Vectors” [1611.01116], “Near-lossless Binarization of Word Embeddings” [1803.09065], and “Projection Bank: From High-dimensional Data to Medium-length Binary Codes” [1509.04916].

## 2. Graph-based Bin2vec for security tasks

The 2020 Bin2vec represents a binary executable as a global program graph assembled from low-level semantics. The binary is disassembled and lifted to VEX IR using angr; an inter-procedural static control-flow graph is built; each basic block is converted into computational trees that reflect true data dependencies; synthetic source and sink nodes are added when needed; and the block-level DAGs are connected according to CFG edges to obtain a global program graph [2002.03388].

Every node receives a one-hot feature vector derived from its label, producing the initial feature matrix $X$. A stack of GCN layers then propagates information over the graph:

$$
H^{(l+1)} = \text{ReLU}\left( D^{-\frac{1}{2}} \tilde{A}\, D^{-\frac{1}{2}} H^{(l)} W^{(l)} \right)
$$

with $H^{(0)} = X$. After graph convolution, node embeddings are aggregated to produce a fixed-length high-dimensional vector representing the entire binary, and that vector is used for downstream classification [2002.03388].

The method was evaluated on 49,191 binaries for functional algorithm classification and on 30 different CWE-IDs including at least 100 CVE entries each for vulnerability discovery. The reported results include a reduction of classification error by 40% compared to the source-code-based inst2vec approach while working on binary code, and prediction accuracy over 80% for almost every vulnerability class, with over 90% in multiple classes [2002.03388]. In this formulation, Bin2vec is a whole-program or whole-function representation learner aimed at automating binary analysis tasks that had traditionally depended on manually defined rules and heuristics.

## 3. Vulnerability discovery formulation and later reassessment

A later analysis revisits Bin2vec specifically as a vulnerability classifier rather than a generic binary embedding model. In that account, Bin2vec is presented as a binary-level classifier for vulnerable and patched functions, using CFG generation, VEX IR parsing, AST construction for each basic block, merging of those ASTs according to the global CFG, and graph convolutional neural networks for embedding and classification [2508.15042]. The graph construction is summarized as

$$
\text{function\_graph} = \textrm{merge}(\{\textrm{AST}_{bb}\},~\textrm{CFG})
$$

where the merged graph is intended to encode structural and semantic properties of the function [2508.15042].

The training and testing dataset in that vulnerability setting is the Juliet Test Suite, with vulnerable and patched function pairs spanning many CWE types. On that synthetic dataset, Bin2vec achieves successful vulnerable-versus-patched classification. However, the same retrospective reports weak transfer to real-world vulnerable functions: among 24 tested real-world vulnerable programs, Bin2vec detected only 2 bugs, whereas BinHunter detected 17 out of 24 [2508.15042].

The limitations identified in that reassessment are specific and consequential. Bin2vec operates at function level, which can obscure vulnerability-relevant slices inside larger real-world functions. Its representation focuses on control flow through CFG+AST structure but does not model data flow explicitly. Training solely on the artificial Juliet dataset limits generalization to complex real-world code. The paper’s central lessons are that locality matters, control flow is not enough, and both data flow and finer granularity are necessary for reliable real-world vulnerability discovery [2508.15042]. A common misconception is therefore that strong performance on Juliet-like benchmarks implies robust vulnerability detection in the wild; the later evidence does not support that conclusion.

## 4. Multi-view Bin2Vec for interpretable and auditable similarity analysis

The 2025 Bin2Vec departs from monolithic graph embeddings and instead encodes each binary from five complementary views: functions, imports, exports, execution traces, and register usage [2512.02197]. Static features are extracted with Ghidra, dynamic features are harvested with x64dbg, the PE header is inspected to ensure correct architecture, and register mappings are normalized to canonical families so that registers such as EAX and RAX map to an accumulator group [2512.02197].

The framework is explicitly modular. Tokenizable fields such as symbol names are embedded with the all-MiniLM-L6-v2 encoder, while a seeded hashing encoder serves as a fallback for determinism and reproducibility. Features from each view are aggregated, usually by mean pooling, into a fixed-size embedding per view, with optional dimensionality reduction such as PCA for stability. The view vectors are standardized and normalized, kept distinct for auditability, and also concatenated for holistic comparison [2512.02197].

Similarity is computed both per view and globally using cosine similarity:

$$
\cos(\mathbf{x}, \mathbf{y}) = \frac{\mathbf{x}^\top \mathbf{y}}{\lVert \mathbf{x} \rVert_2 \; \lVert \mathbf{y} \rVert_2}
$$

where $\mathbf{x}, \mathbf{y} \in \mathbb{R}^d$ may be single-view or concatenated embeddings [2512.02197]. The system reports both the global cosine similarity and a weighted mean of view-level similarities. This design makes the representation simultaneously machine-friendly and decomposable into inspectable evidence.

## 5. Interpretability, auditability, and empirical behavior

Interpretability is a first-class design goal in the 2025 Bin2Vec. Each view is separately inspectable; every feature retains provenance tags linked back to Ghidra or x64dbg; the modular pipeline prevents a single defective signal from unduly dominating the outcome; and radar charts, bar plots, and related visualizations expose agreement or divergence across views [2512.02197]. The framework therefore supports auditing not only of final similarity scores but also of the structural or behavioral factors that drive them.

The reported experiments use multiple versions of two widely used Windows programs, PuTTY and 7-Zip, all PE32/32-bit. The qualitative findings are view-specific. In the functions view, PuTTY displayed richer structural patterns, including locals and control flow, while 7-Zip was more parameter/ABI-oriented. In imports and exports, 7-Zip emphasized address and names, whereas PuTTY included more namespace and grouping cues. In register usage, PuTTY versions used control and stack registers more, while 7-Zip focused on accumulators and index registers, correlating to optimized inner loops. In dynamic traces, PuTTY exhibited wider instruction and memory activity, while 7-Zip had tighter instruction-pointer locality [2512.02197].

Quantitatively, cosine similarities computed per view and overall showed clear distinctions between PuTTY and 7-Zip, with negative or low scores across views for these unrelated codebases. The paper interprets these outcomes as validation of effective differentiation. It also argues that the resulting visualizations make interpretability practical and actionable for code plagiarism detection, software provenance analysis, auditing, and rapid screening of large numbers of programs [2512.02197].

## 6. Position within binary-code representation research

Bin2vec sits within a broader shift from heuristic binary analysis to learned representations. The 2020 system exemplifies graph-centric representation learning over VEX IR and program graphs [2002.03388]. The 2025 system exemplifies an interpretable multi-view alternative that retains view-wise evidence and explicit provenance [2512.02197]. The later vulnerability-discovery analysis shows that benchmark success can conceal shortcomings in granularity, data-flow coverage, and dataset transferability [2508.15042].

Subsequent binary-code models further broaden this trajectory. BinBert, for example, introduces a transformer pre-trained on assembly instruction sequences and symbolic execution information, is fully fine-tunable, and reports state-of-the-art performance on a multi-task benchmark for binary code understanding [2208.06692]. This does not invalidate Bin2vec; rather, it situates it as one stage in an evolving design space spanning graph representations, execution-aware pre-training, and auditable multi-view similarity.

A plausible implication is that “Bin2vec” now denotes less a single canonical method than a family of attempts to bridge binary representations and machine learning. One branch emphasizes learned whole-program or whole-function embeddings for security tasks; another emphasizes view-preserving, visualization-friendly similarity analysis for plagiarism detection and software auditing. Across both branches, the shared premise is that binary code can be represented in a structured vector space rich enough for classification, retrieval, and forensic inspection, while later work makes clear that representation choice, evaluation regime, and interpretability constraints materially affect what those vectors can support in practice.

Source: https://www.emergentmind.com/topics/bin2vec