Bin2vec: Binary Program Representation Methods
- Bin2vec is a method for representing binary programs as machine-usable vectors for security tasks, similarity analysis, and plagiarism detection.
- The graph-based variant employs computational program graphs and GCNs to improve functional classification and vulnerability detection with notable accuracy gains.
- The multi-view variant integrates static and dynamic features from sources like Ghidra and x64dbg, offering interpretable and auditable similarity scores.
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 (Arakelyan et al., 2020), and a later multi-view framework for interpretable and auditable binary similarity and plagiarism detection (Moussaoui et al., 1 Dec 2025). 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 (Arasteh et al., 20 Aug 2025).
| 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 (Arakelyan et al., 2020). 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 (Moussaoui et al., 1 Dec 2025).
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” (Grzegorczyk et al., 2016), “Near-lossless Binarization of Word Embeddings” (Tissier et al., 2018), and “Projection Bank: From High-dimensional Data to Medium-length Binary Codes” (Liu et al., 2015).
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 (Arakelyan et al., 2020).
Every node receives a one-hot feature vector derived from its label, producing the initial feature matrix . A stack of GCN layers then propagates information over the graph:
with . 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 (Arakelyan et al., 2020).
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 (Arakelyan et al., 2020). 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 (Arasteh et al., 20 Aug 2025). The graph construction is summarized as
where the merged graph is intended to encode structural and semantic properties of the function (Arasteh et al., 20 Aug 2025).
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 (Arasteh et al., 20 Aug 2025).
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 (Arasteh et al., 20 Aug 2025). 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 (Moussaoui et al., 1 Dec 2025). 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 (Moussaoui et al., 1 Dec 2025).
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 (Moussaoui et al., 1 Dec 2025).
Similarity is computed both per view and globally using cosine similarity:
where may be single-view or concatenated embeddings (Moussaoui et al., 1 Dec 2025). 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 (Moussaoui et al., 1 Dec 2025). 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 (Moussaoui et al., 1 Dec 2025).
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 (Moussaoui et al., 1 Dec 2025).
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 (Arakelyan et al., 2020). The 2025 system exemplifies an interpretable multi-view alternative that retains view-wise evidence and explicit provenance (Moussaoui et al., 1 Dec 2025). The later vulnerability-discovery analysis shows that benchmark success can conceal shortcomings in granularity, data-flow coverage, and dataset transferability (Arasteh et al., 20 Aug 2025).
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 (Artuso et al., 2022). 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.