arXiv CS open access

N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching

2026 · arxiv_cs

arXiv CS · Papers · 2026

software-architecture software-engineering testing

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching

arXiv:2608.10043v1 [cs.SE] 10 Aug 2026

Ang Jia, He Jiang, Zhipeng Yang, Zhilei Ren, Xiaochen Li

Abstract—Program-level Binary Code Similarity Analysis (BCSA) aims to identify semantically similar code regions across binary programs, serving as a fundamental technique for software plagiarism detection, vulnerability search, and malware analysis. Existing approaches often decompose binaries into modules following the structure of function call graphs (FCGs) and then match these modules by their contained functions. However, function inlining changes both FCG structures and binary function semantics, making existing decomposition and module matching methods less effective. In this work, we propose N2NMatcher, an inlining-resilient framework for binary decomposition and module matching. We first conduct an empirical study to examine whether binaries still contain functions that provide stable module boundaries across compilation settings. N2NMatcher learns to predict such functions as anchors using a hierarchical graph neural network that encodes binary ACFG–FCG representations built from opcode sequences, control-flow structures, and FCG calling context. It then performs anchor-bounded decomposition and matches the generated modules using learned module graph embeddings. Experimental results show that N2NMatcher improves both the decomposition quality and module matching accuracy, compared to existing works, enabling more effective program-level BCSA. Index Terms—Program-level Binary Code Similarity Analysis, Binary Decomposition, Module Matching, Function Inlining

I. I NTRODUCTION OST software today is not developed entirely from scratch. Instead, developers rely on a range of opensource components to create their applications [1]. According to a recent report [2], 97% of software contains open-source components. Although code reuse helps to finish projects more quickly and reduce costs, improper reuse introduces security and legal risks [3]. As reported in [2], 65% of organizations experienced a software supply chain attack in 2025. Moreover, downstream software often depends on closed-source binaries. Security and legal risks embedded in the binaries generated by upstream suppliers may be unintentionally transferred to downstream users. To address these code reuse issues, Program-level Binary Code Similarity Analysis (BCSA) identifies semantically similar code regions across different binary programs. In general, program-level BCSA consists of two stages: binary decomposition and module matching. In the binary decomposition stage, a binary is decomposed into modules that serve as the

Corresponding author: He Jiang. This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible. • Ang Jia, He Jiang, Zhipeng Yang, Zhilei Ren, and Xiaochen Li are with the School of Software, Dalian University of Technology, China.

basic units for comparison, while module matching compares these modules across binaries to identify reused regions. Existing methods usually rely on function call graphs (FCGs) to decompose binaries and compare modules, assuming that reused code preserves similar FCG structures and functionlevel semantics. However, as binaries are compiled using diverse compilers, optimizations, and architectures, their function call relationships undergo significant changes. Figure 1 illustrates a reuse detection example between two software components: Zlib [4] and Curl [5]. Zlib is a widely reused compression library. Curl integrates the inflate module from Zlib to handle compressed HTTP responses. In this example, the two components are compiled under different optimization settings: Zlib is compiled with GCC at O1, while the Zlib code integrated into Curl is compiled with GCC at the more aggressive O3 level. This difference in optimization leads to distinct inlining decisions. As shown in Figure 1, function inlining changes both the topology of FCGs and the semantics of their nodes. For example, the function crc32_z in Curl inlines crc_word from Zlib, so crc_word no longer exists as a standalone binary function in Curl. Similarly, inflate inlines inflateStateCheck and updatewindow; as a result, a single binary function in Curl may correspond to multiple binary functions in Zlib. This variance directly undermines the core assumption of existing binary decomposition methods. Once the decomposed modules are no longer semantically aligned, downstream module matching also becomes unreliable. When applying existing state-of-the-art decomposition methods, such as ModX [6], to this example, we observe that they face two main challenges. Challenge 1: unstable module boundaries. Function inlining changes the FCG structures used for modularization, so modules generated from the two binaries may no longer cover the same source-level regions. Challenge 2: unstable function-level semantics. ModX also relies on function-level semantics to calculate module similarity, but inlining changes semantics in the binary functions. For example, crc32_z in Curl contains the semantics of both crc32_z and crc_word in Zlib. Although these modules cover related source semantics, ModX may fail to identify their equivalence. These mismatches show that existing methods cannot effectively handle the module boundary changes and function semantic changes caused by function inlining. To resolve Challenge 1, we first conduct an empirical study to determine whether binaries still contain functions that can serve as stable module boundaries across compilation settings. The study shows that although function-level equivalence is often

Zlib compiled by gcc O1

Zlib decomposed by ModX

inflate_table

inflate_fast

Unmatched Modules in Zlib

crc_word

crc32

crc32_z

adler32

adler32_z

inflateStateCheck

crc32

crc32_z

adler32

adler32_z

inflateStateCheck

adler32

crc_word

inflate

inflate_table adler32_z updatewindow

inflateStateCheck Matched Modules

inflate

updatewindow

inflate

updatewindow inflate_fast

Decompose

Match

Curl compiled by gcc O3

Curl decomposed by ModX

inflate_table

inflate_fast

crc32

crc32_z crc32

…

inflate_fast

… inflate_stream

crc32

crc32_z

adler32

adler32_z

inflate_stream

crc32

crc32_z

adler32

adler32_z

crc_word

crc32_z

Unmatched Modules in Curl adler32 inflate

inflate

inflate_fast

adler32_z inflate_table

inflate_table

inflate

Reused API

Reused Function

Semantically equivalent

Generated Modules

Other Functions

Fig. 1. A motivating example for binary decomposition in program-level BCSA.

disrupted, source-verified stable boundary functions still exist and can delimit source-equivalent binary regions. Motivated by this observation, we propose N2NMatcher, an inlining-resilient framework for binary decomposition and module matching. The key insight behind N2NMatcher is to identify functions that can serve as stable boundaries and use them as anchors. To identify anchors in a binary, N2NMatcher first constructs a binary ACFG–FCG representation by combining function-level attributed control-flow graphs (ACFGs) with interprocedural call relationships. It then applies a hierarchical graph neural network to encode opcode, control-flow, and calling-context information and predict which FCG nodes are anchors. Following the predicted anchors, N2NMatcher decomposes a binary into anchor-bounded regions whose boundaries are less sensitive to inlining-induced FCG changes. To address Challenge 2, N2NMatcher further performs matching at the module level. Instead of relying only on unstable one-to-one function-level similarities, N2NMatcher represents each generated module as a graph and compares the resulting module graph embeddings. This design reduces the impact of inlining-induced function granularity changes and enables program-level BCSA to compare module similarities rather than isolated functions. Our main contributions are listed as follows:

3) Building on this observation, we propose N2NMatcher, which predicts anchors with a hierarchical ACFG– FCG graph neural network, decomposes binaries through anchor-bounded traversal, and performs module matching using module graph embeddings. 4) We evaluate N2NMatcher under project-level crossvalidation. The results show N2NMatcher improves both the decomposition quality and module matching accuracy when compared to existing works. To facilitate further research, we have made the implementation of N2NMatcher publicly available on GitHub.1

1) To the best of our knowledge, we propose the first inlining-resilient framework that supports binary decomposition and module matching for program-level BCSA. 2) We conduct an empirical study to reveal that sourceverified stable boundary nodes widely exist under compilation variance and can serve as effective boundaries for binary decomposition.

A. Binary Decomposition for Program-level BCSA

II. R ELATED W ORK Our work studies program-level BCSA under function inlining. In this setting, binary analysis often involves two stages: decomposing a binary into module-level regions and comparing these regions across binaries. Function inlining affects both stages because it changes the topology of FCGs used for decomposition and the semantic granularity of binary functions used for matching. Therefore, we discuss related work in two areas: binary decomposition for program-level BCSA and binary code similarity analysis under function inlining.

Binary decomposition is an important step in program-level binary analysis, especially for C/C++ third-party library detection and component reuse detection [6]–[15]. Compared with Java library detection [16]–[22], C/C++ binary decomposition 1 https://github.com/island255/N2NMatcher

faces more diverse compilation settings and architectures, making module boundaries harder to preserve. Existing fine-grained binary decomposition methods can be broadly divided into two classes: anchor-based methods and clustering-based methods. Anchor-based methods [7]–[10] first identify highly similar function pairs as anchor nodes, and then follow the function call relationships around these anchors to search for additional matched functions. ISRD [8] identifies functions with identical instructions or identical library calls as anchors, and then compares functions that share many anchor neighbors. LibDB [10] selects similar function pairs whose similarity is larger than 80%, and then uses the FCG structure to examine the matched functions. LibAM [7] first identifies highly similar function pairs as anchors, extends these anchors to construct function areas, and finally compares function areas to identify reused third-party libraries (TPLs). Though anchor-based methods use different strategies to detect reused TPLs, they all rely on the local structure around anchor nodes to match more functions. Clustering-based methods [6], [12]–[14] first cluster binary functions into modules, and then compare these modules to identify reused TPLs. BCD [13] uses three properties, including code locality, data references, and function calls, to construct a graph for clustering. Then BCD uses Newman’s generalized community detection algorithm [23] to group binary functions into modules. ModX [6] first defines a module quality score to assess the coherence of the function clusters, and then it starts to group individual functions to form modules while maximizing the overall module quality score. BMVul [14] introduces directed binary modularization (DBM), an overlapping community detection algorithm for binary function clustering. Though clustering-based methods use different features to construct their clustering graphs, the FCG is usually the core structure from which clustering starts. B. BCSA Under Function Inlining Existing works [24]–[36] have taken preliminary steps toward binary code analysis under function inlining. The first binary function similarity detection work that considers function inlining is Bingo [24], which summarizes several patterns that a caller function may use to inline its callee functions and conducts inlining to simulate the resulting binaries. Asm2Vec [25] also adopts Bingo’s strategies to handle function inlining. However, their simulation-based inlining strategies have been proven inaccurate [26] and thus cannot fully address the challenges that function inlining brings. Jia et al. [26] conducted the first systematic empirical study to investigate the effect of function inlining on binary function similarity analysis. They evaluated four existing works on an inlining-aware dataset and observed a 30%– 40% performance loss when detecting functions affected by inlining. To tackle these challenges, they proposed two methods, O2NMatcher [27] and CI-Detector [28], for binary-tosource and binary-to-binary function-level similarity detection, respectively. Abusabha et al. [37] systematically analyzed how inlining distorts static features in machine-learning (ML)-based binary

analysis and showed that compiler settings can be exploited to craft evasive binary variants. Moreover, several works aim to identify inlined functions. ReIFunc [29] identifies inlined functions by detecting repeated code fragments in binaries. A number of works [31]–[34] focus on identifying inlined library functions. Besides, OpTrans [30] uses a binary rewriting technique to reoptimize binaries toward similar inlining decisions. However, the above works mostly focus on function-level binary similarity analysis. Jia et al. [38] conducted an empirical study on binary decomposition under compilation variance and found that existing decomposition methods suffer from under-aggregation and over-aggregation failures. In this work, we propose a binary decomposition method designed to be robust to function inlining. Our work provides a new perspective for subsequent research from a program-level view. III. E MPIRICAL S TUDY The motivating example reveals that function inlining introduces changes at two levels: it changes the topology of FCGs used for decomposition and alters the semantic granularity of binary functions used for function-level matching. As a result, modules generated from different compilation variants may no longer cover the same source-level semantics, and individual binary functions may no longer preserve one-to-one semantic equivalence. In this section, we conduct an empirical study to investigate whether stable semantic regions still exist under such changes and, if so, at what binary granularity semantic equivalence can be preserved. We therefore formulate the following study question: How does function inlining affect semantic equivalence across compilation variants, and can semantic equivalence be preserved at a certain binary granularity? We decompose this question into three study questions that progressively examine FCG equivalence, function-level semantic equivalence, and region-level semantic equivalence: • SQ1. To what extent do FCGs remain structurally equivalent across compilation variants? • SQ2. How does function inlining affect function-level semantic equivalence? • SQ3. Can semantic equivalence be preserved at a coarser binary-region granularity? A. Study Design 1) Dataset: We conduct the empirical study on x86-64 binaries from the link-time optimization (LTO) subset of BinKit [39], [40]. We choose this dataset for two reasons. First, BinKit is a widely used BCSA benchmark and has also been adopted in recent binary decomposition evaluation [38], making it suitable for studying decomposition under controlled compilation variance. Unlike datasets such as BinaryCorp [41], which mainly emphasize scale and diversity for function-level similarity learning, BinKit provides an explicit LTO subset for studying decomposition under aggressive whole-program optimization. Second, the LTO subset is closely aligned with our research objective because it exposes substantial FCG

750 500 250 0

g an Cl

3 cO

(a) FCG nodes Avg. #edges

changes. Link-time optimization enables interprocedural optimization across compilation units and supports whole-program optimization, including cross-file inlining [42]. Since prior work has shown that function inlining significantly affects binary similarity analysis [26], this subset allows us to further investigate how inlining affects program-level binary decomposition and module matching. The dataset contains 84 executable targets derived from 28 projects. Each executable target is compiled using 9 compiler versions, including Clang 4.0, 5.0, 6.0, 7.0, and GCC 4.9.4, 5.5.0, 6.4.0, 7.3.0, 8.2.0, with four optimization levels, including O0, O1, O2, and O3. This process produces 3,024 binary variants in total. All binaries are compiled with debug information to facilitate labeling. In this empirical study, we use IDA Pro [43] to disassemble these binaries and construct one FCG for each binary. In summary, we obtain 3,024 FCGs with 1,403,680 nodes and 7,417,670 edges. 2) Binary-to-Source Function Mapping: We construct binary-to-source function mappings from binaries compiled with debug information to provide a source-level semantic oracle for the empirical study. Specifically, we extract records that map binary instruction addresses to source lines from debug-line tables. We also extract source function ranges from the corresponding source files. A binary function is mapped to a source function if its instructions map to source lines within the source function range. For a binary function b, let M (b) denote the set of source functions mapped to b. If |M (b)| > 1, we treat b as an inlining-affected binary function because its recovered binary body contains source semantics from multiple source functions. 3) Binary-to-Binary Function Mapping: Based on the source sets M (b) obtained above, we construct binary-tobinary function mappings for binaries compiled from the same project target. Given two binary functions bi and bj from two compilation variants, we count them as an exact function-level match under our source-set oracle when M (bi ) = M (bj ) ̸= ∅. When their source sets overlap but are not equal, the corresponding semantics are only partially aligned at the function level and may require region-level aggregation. For a binary S region R, we define M (R) = b∈R M (b) and use this source set to analyze the semantic coverage of binary regions. Unless otherwise stated, the function-level metrics in this section are computed over binary functions covered by the binary-to-source mapping. This restriction ensures that the reported results are supported by source-level semantic evidence. Binary FCG structural statistics, such as the numbers of recovered nodes and edges, are computed over the whole recovered FCGs.

Avg. #nodes

3000 2000 1000 0

g an Cl

3 cO

(b) FCG edges Fig. 2. FCG structural changes across compiler-optimization settings.

optimization setting, we aggregate the results across different versions of the same compiler family. As shown in Figure 2(a), the average number of FCG nodes decreases consistently from O0 to optimized settings. Clang decreases from 614.06 nodes at O0 to about 356 nodes at O2/O3, while GCC decreases from 697.43 nodes at O0 to 372.33 nodes at O3. This confirms that many source-level functions no longer remain as standalone binary functions after optimization. Figure 2(b) shows that FCG edges also change substantially, although their trend is less monotonic than that of FCG nodes. For example, GCC edges decrease from 3,130.91 at O0 to 2,152.17 at O2, but rise to 2,348.68 at O3. This suggests that inlining not only removes nodes but also reshapes call relationships among the remaining binary functions. We further compare all six unordered optimization-level pairs for every executable target and exact compiler version, yielding 4,536 FCG comparisons. Isomorphic directed graphs must have equal numbers of nodes and edges. In 4,429 comparisons (97.64%), at least one of these counts differs, which is sufficient to prove structural non-equivalence. All 2,268 comparisons between O0 and an optimized variant differ in at least one count. The remaining 107 comparisons have equal node and edge counts, but count equality is necessary rather than sufficient for graph isomorphism; we therefore leave these cases undecided instead of treating them as equivalent.

B. SQ1: Impact on FCG Structures

C. SQ2: Impact on Binary Functions

We first examine whether recovered FCGs remain structurally equivalent across optimization variants. Function inlining is one mechanism that can remove standalone callees and rewire call relationships through their callers, thereby affecting both the number of visible FCG nodes and the number of call edges. Figure 2 reports these two structural statistics under eight compiler-optimization settings. For each compiler-

We next analyze how function inlining affects binary functions themselves. We first measure how many recovered binary functions are affected by inlining. Following the binary-tosource mapping definition, a binary function is treated as inlining-affected when it maps to multiple source functions. Figure 3 reports the ratio under eight compiler-optimization settings. The ratio is very low at O0, with 0.08% for Clang

36.8

g an Cl

27.0

20.5

0.4

0.1

g an Cl

a Cl

Exact equivalent

64.7

62.9

62.5

Fig. 3. Inlining-affected binary functions across compiler-optimization settings.

and 0.35% for GCC. It then increases sharply as optimization becomes stronger. For Clang, the ratio reaches 20.47% at O1 and more than 62% at O2/O3. For GCC, it increases from 26.96% at O1 to 64.71% at O3. These results show that optimized binaries contain many binary functions whose semantics are produced by merging multiple source functions. The above results show that many optimized binary functions are produced by merging multiple source functions. Since function inlining changes the semantic content of individual binary functions, methods whose module matching relies on function-level similarities, such as ModX, can also be affected in program-level BCSA. Therefore, we construct binary pairs under three common cross-compilation scenarios, ordered from easier to harder: cross-compiler sameoptimization, same-compiler cross-optimization, and crosscompiler cross-optimization. Under these scenarios, we verify whether function-level semantic equivalence is still preserved. For each pair of binaries from the same project target, if a query binary function has the same source set as a function in the other binary, we count it as an exact function-level equivalent. If no exact equivalent exists but the source set overlaps with at least one function in the other binary, we count it as partial function-level overlap. Such partial overlap indicates that the corresponding source semantics are still present in the other binary, but they are split, merged, or absorbed differently at the binary-function level. These cases indicate where region-level aggregation may recover semantic alignment beyond individual binary functions. Figure 4 reports the results from 1,000 sampled binary pairs for each cross-compilation setting in the LTO dataset, with every pair evaluated in both directions. A large fraction of query functions no longer have exact one-to-one counterparts but still partially overlap with functions in the other binary: 33.5% in cross-compiler same-optimization pairs, 46.3% in same-compiler cross-optimization pairs, and 53.3% in crosscompiler cross-optimization pairs. Meanwhile, the ratio of exact function-level equivalents drops from 56.8% under crosscompiler same-optimization to 39.9% under same-compiler cross-optimization and 30.2% under cross-compiler crossoptimization. These cases indicate that equivalent source semantics are still present, but they are increasingly split, merged, or absorbed across binary functions rather than preserved as one-to-one binary functions. The remaining category, No verified overlap, does not

Query binary functions (%)

Ratio (%)

100 80

9.7%

Partial overlap

No verified overlap

13.8%

16.5%

33.5% 46.3%

53.3%

40 56.8% 39.9%

20 0

Cross compiler + same opt.

Same compiler + cross opt.

30.2%

Cross compiler + cross opt.

Fig. 4. Function-level alignment across compilation variants.

imply that the source semantics are absent from the target binary. It means that, under our debug-line-based oracle, none of the source functions mapped to the query binary function can be verified in any target-side binary function. For example, in plotutils-2.6/ode.elf, the GCC 8.2.0 O0 binary contains a recovered function intpr mapped to ode/stperr.c:intpr at lines 100–116. In the Clang 5.0 O2 binary of the same target, no recovered binary function maps to intpr, although the same source file still has verified mappings for other functions such as maxerr, lowerror, and hierror. This case is therefore counted as No verified overlap. Such cases can arise when optimization eliminates, absorbs, or rewrites small functions without preserving debugline information that can be attributed back to the original source function. D. SQ3: Region-Level Semantic Equivalence In SQ3, we investigate whether semantic equivalence can be preserved at a coarser binary granularity. For a binary region R, we define its source region as the union of source S functions mapped from its binary functions, i.e., S(R) = b∈R M (b). Two binary regions are source-equivalent if they map to the same source region. Under this view, binary decomposition should recover binary regions whose source regions remain stable across compilation variants. Such source-equivalent regions require stable boundary functions. In the motivating example, some source functions are absorbed by inlining, such as crc_word, inflateStateCheck, and updatewindow; these functions cannot mark stable region boundaries because they disappear as standalone binary functions in the optimized Curl binary. In contrast, caller-side functions such as crc32_z and inflate remain as the origin source functions of recovered binary functions and can delimit regions that contain their inlined callees. This suggests two observable properties of stable boundary functions: first, at least one observed compilation configuration recovers them as caller-side binary functions, possibly containing inlined callees; second, no observed configuration places them as inlined callees inside binary functions rooted in other source functions. We formalize these properties using binary-to-source mappings. For a binary function b, let M (b) be its mapped source-

Bcroot (s) = {b ∈ Bc | o(b) = s},

(1)

Bcinl (s) = {b ∈ Bc | s ∈ M (b) ∧ o(b) ̸= s}.

(2)

Definition 1 (Source-verified stable boundary node).A source function s defines source-verified stable binary boundary nodes in a group g if it satisfies the following condition: ∃c ∈ Cg : |Bcroot (s)| ≥ 1 ∧ ∀c ∈ Cg : Bcinl (s) = ∅ . (3) The first term requires s to appear as the OSF of at least one recovered binary function in the compilation group. The second term requires that, across all observed configurations, s is never inlined into a binary function whose OSF is another source function. Stability therefore refers to the boundary role of s whenever it is recovered rather than requiring a binary instance in every configuration. For each source function s satisfying Definition 1 and each configuration c ∈ Cg , every binary function in Bcroot (s) is labeled as a stable boundary node in the binary FCG. Thus, the label requires s to occur as the OSF of the node and never as an inlined callee under another OSF in any observed configuration. The labeled binary function may nevertheless contain other source functions as inlined callees. Although function inlining creates many inlining-affected binary functions, source-verified stable boundary nodes are still widely present. Among 855,226 FCG nodes with debugline source labels, 364,896 nodes are source-verified stable boundary nodes, accounting for 42.67% of labeled nodes and 26.00% of all FCG nodes. Figure 5 further shows that stable boundary nodes persist across compiler-optimization settings, while other functions shrink more sharply under optimization. Its eight compiler-optimization bars report average binaryfunction counts per binary. We split stable boundary nodes into single-source and multi-source cases: a single-source stable node maps to only its OSF, while a multi-source stable node maps to its OSF plus one or more inlined callees; the remaining source-labeled binary functions are grouped as other functions. Among all stable boundary nodes, 267,365 are single-source and 97,531 are multi-source, meaning that 26.73% of stable boundaries contain inlined semantics while still preserving a stable origin.

Single-source anchor Multi-source anchor Other functions

500 Avg. #binary funcs.

function set and let o(b) be its origin source function (OSF), i.e., the source function that contributes the main semantics of the standalone binary function. If b maps to one source function, the source function is treated as the OSF. If b maps to multiple source functions, we treat the case as an inlining case: the source function whose name matches the binary function name is treated as the caller-side OSF, while the other mapped source functions are treated as inlined callee-side semantics. For a group g of compilation variants generated from the same project target, let Cg denote its compilation configurations. For each configuration c ∈ Cg , let Bc denote its recovered binary functions. For a source function s, we define Bcroot (s) as the binary functions in Bc whose OSF is s, and Bcinl (s) as the binary functions in Bc where s is not the OSF but is inlined into the function whose OSF is o(b):

400 300 200 100

206.0 132.5 105.6 103.3 103.3

104.5 100.8 101.7

O0 O1 O2 O3 O0 O1 O2 O3 ng lang lang lang Gcc Gcc Gcc Gcc a l C C C C

Fig. 5. Composition of stable boundary nodes in the LTO dataset.

We further verify whether these stable boundaries actually delimit equivalent regions. Using the same 3,000 sampled binary pairs as SQ2, evaluated in both directions and yielding 6,000 directional evaluations, we construct regions delimited by source-verified stable boundary nodes and compare each query region with the most similar region in the other binary. Because optimization may eliminate source functions, the comparison uses only source functions observed in both binaries. For a pair (Bq , Bt ), let Uq,t be their common mapped source-function set, and let Sq,t (r) = S(r) ∩ Uq,t . Regions with Sq,t (r) = ∅ are excluded. Given a query region rq and a target region rt , we define the similarity as: Overlapsf (rq , rt ) =

2|Sq,t (rq ) ∩ Sq,t (rt )| . |Sq,t (rq )| + |Sq,t (rt )|

(4)

This source-level overlap score ranges from 0 to 1, where 1 means that the two regions cover the same verified sourcefunction set and 0 means that they share no verified source functions. For each query region, we retain the highest score over all target regions. Across 503,786 source-relevant query regions, the mean of these per-query scores is 0.938; 71.76% of regions have an exact counterpart, and 89.99% reach a score of at least 0.8. Even in the hardest cross-compiler cross-optimization setting, the mean score remains 0.923, with 87.51% of regions reaching 0.8. These results indicate that semantic equivalence can largely be preserved at the coarser granularity of binary regions obtained through stableboundary-guided decomposition, even when individual binary functions no longer align one-to-one across compilation variants. E. Answer to SQ1–SQ3 Overall, function inlining disrupts function-level semantic alignment, but it does not eliminate semantic equivalence entirely. First, recovered FCGs are generally structurally nonequivalent across optimization variants, so binary decomposition should not assume stable FCG topology. Second, function inlining changes binary function granularity, making many cross-compilation function pairs only partially overlap at the source level. Third, semantic equivalence can still be preserved

at a source-consistent region granularity, with 42.67% of labeled FCG nodes serving as stable boundaries under our definition. These findings motivate learning stable boundary nodes and using them to guide binary decomposition, as described in the next section. The resulting source-consistent modules provide a more reliable basis for downstream module matching. IV. N2NM ATCHER This section presents N2NMatcher, an inlining-resilient framework for binary decomposition and module matching. The key idea is to predict binary FCG nodes that can serve as stable boundaries. We refer to these predicted nodes as anchors and use them to guide decomposition. Instead of clustering the whole FCG according to global topology, N2NMatcher predicts anchors from binary graph representations and then constructs anchor-bounded modules. Figure 6 presents the overall workflow of N2NMatcher. Given a stripped binary, N2NMatcher first constructs an ACFG–FCG representation by combining function-level attributed control-flow graphs with interprocedural call relationships. It then embeds this representation with a hierarchical ACFG–FCG encoder, which produces contextual representations for FCG nodes. Based on these embeddings, N2NMatcher predicts anchors, decomposes the FCG into anchor-bounded modules, and compares the generated modules by integrating Syntactic Similarity, Semantic Similarity, and Graph Similarity. Source code and debug information are used only for constructing training labels and evaluation oracles. During deployment, N2NMatcher requires only a stripped binary as input. A. Binary ACFG–FCG Construction Instruction Normalization. Given a stripped binary, N2NMatcher first converts disassembly into a compact instruction representation. For each instruction, we keep only its opcode mnemonic in lowercase as the normalized token and discard operand-level details such as registers, concrete addresses, and immediate values. This normalization reduces sensitivity to register allocation, address layout, and compilerspecific instruction changes, while retaining a compact record of the operations observed in each basic block. Basic Block Representation. For each basic block, the normalized opcode mnemonics are mapped into a deterministic hash-based token space and then converted into learnable embeddings. Mean pooling produces an order-invariant summary of the opcode content, which is projected to initialize the basicblock node representation. The resulting representations are then updated through ACFG-level message passing. ACFG Construction. For each recovered binary function v, N2NMatcher builds an attributed control-flow graph (ACFG) Gv = (Vv , Ev ). Each node in Vv corresponds to a basic block and is attributed with the normalized opcode sequence extracted from that block. Each directed edge (bi , bj ) ∈ Ev denotes an intraprocedural control-flow transfer from basic block bi to bj . The hierarchical encoder uses the normalized opcode sequences as ACFG node attributes. Thus, the ACFG

captures both local instruction behavior and intraprocedural control-flow structure. FCG Construction. At the interprocedural level, N2NMatcher constructs a function call graph (FCG) Gf = (Vf , Ef ) for the whole binary. Each node v ∈ Vf corresponds to a recovered binary function. The directed edges in Ef come from two sources: direct call instructions and direct cross-function jumps. For a direct call inside function u, N2NMatcher adds an edge (u, v) when the call target resolves to an address belonging to function v. For a direct cross-function jump inside function u, N2NMatcher adds a tail-call edge (u, v) when the statically resolved jump target belongs to a different recovered function v. This tail-call-aware FCG captures both ordinary calls and tail-call-style interprocedural transfers introduced by compiler optimizations. ACFG–FCG Construction. N2NMatcher then attaches each function-level ACFG Gv to its corresponding FCG node v. The resulting ACFG–FCG is a nested binary representation: the FCG captures interprocedural caller–callee relationships, while each attached ACFG captures the opcode content and intraprocedural control-flow structure of a recovered function. This nested representation provides the hierarchical encoder with both function-body structure and calling-context information, which are important for identifying stable module boundaries. B. Hierarchical ACFG–FCG Embedding The binary ACFG–FCG is a nested graph: each FCG node corresponds to a recovered function and is associated with an ACFG describing its intraprocedural structure. N2NMatcher therefore uses a hierarchical encoder with two messagepassing levels. The lower level propagates information within each ACFG to derive a function embedding for each recovered function. The upper level uses these function embeddings as initial FCG node representations and propagates them over FCG edges to incorporate calling-context information. At the ACFG level, normalized opcodes are mapped into a deterministic hash-based token space, and their embeddings are learned during model training. For a nonempty basic block b with opcode sequence (o1 , o2 , . . . , om ), N2NMatcher looks up opcode embeddings, applies mean pooling over the tokens, and projects the pooled vector into the initial block (0) representation hb : ! m 1 X (0) Emb(oi ) . (5) hb = ReLU Wo · m i=1 The function-body encoder then applies message passing over the ACFG. For each basic block, it aggregates representations from adjacent basic blocks and combines them with the block’s own state: (ℓ+1) (ℓ) hb = ReLU Ws hb + Wn · Meanu∈NA (b) h(ℓ) , (6) u where NA (b) denotes the basic blocks adjacent to b in the symmetrized message-passing graph. After two ACFG message-

Binary ACFG-FCG Construction

Stripped Binary

Opcode Sequence

Hierarchical ACFG-FCG Embedding

ACFG

CFG

ACFG-FCG

FCG Message Passing

Function Call

Module-Level Matching

Matched Modules

Module Similarity

ACFG Message Passing

ACFG

Decomposition

Syntactic

Semantic

C D

ACFG-FCG Node Embedding

Anchor Prediction

D E

Graph

Function Embedding

Anchor Function Other Function

Fig. 6. Overview of N2NMatcher for binary decomposition and module matching.

passing layers, the function representation is obtained by mean pooling over all basic blocks in the function: (L )

zv = Meanb∈Vv hb A .

(7)

The vector zv is the ACFG embedding of function v. It captures both local opcode patterns and intraprocedural controlflow context. At the ACFG–FCG level, N2NMatcher treats zv as the function embedding of FCG node v. It concatenates zv with binary-derived structural features describing the function, its neighborhood, local FCG topology, and the whole FCG. The resulting vector is projected into the initial FCG node state (0) xv , after which interprocedural context is propagated over the symmetrized FCG neighborhood: (k) x(k+1) = ReLU Us x(k) , (8) v v + Un · Meanu∈NF (v) xu where NF (v) denotes the callers and callees adjacent to function v in the symmetrized message-passing graph. The original directed FCG is retained for module traversal. (L ) The resulting representation xv F is the context-aware embedding of function node v: it combines the intraprocedural function representation learned from Gv with interprocedural calling-context information propagated over the FCG. C. Anchor Prediction Given labeled training binaries, N2NMatcher trains the hierarchical encoder as a binary classifier. Let p(v) be the predicted probability that function node v is an anchor, and let yv ∈ {0, 1} be the source-verified label derived in Section III. A node is labeled positive when its OSF satisfies the stable boundary condition in Definition 1; it is labeled negative when it has verified source semantics but its OSF fails this condition. Nodes whose source semantics cannot be verified are not assigned labels. Let Ω denote the set of recovered functions with source-verified labels. During training, N2NMatcher still runs message passing on the full ACFG–FCG, so unlabeled nodes can provide structural context to their labeled neighbors. However, supervision is applied only to nodes in Ω. For each

labeled node v ∈ Ω, the anchor predictor outputs a probability pv , and the model is trained with positive-class weighted binary cross-entropy: 1 X L=− [αyv log p(v) + (1 − yv ) log(1 − p(v))] , (9) |Ω| v∈Ω

where α = Nneg /Npos compensates for the imbalance between anchor and non-anchor nodes in the training set. At inference time, N2NMatcher predicts v as an anchor when p(v) ≥ τ, (10) where τ is selected using validation projects and then fixed for held-out test binaries. The predicted anchors are then used as boundary nodes for the anchor-bounded decomposition described next. D. Decomposition After anchor prediction, N2NMatcher decomposes a binary by traversing the FCG from the predicted anchors and the recovered FCG roots, as summarized in Algorithm 1. Let P be the predicted anchors and let R = {v ∈ V | deg− (v) = 0} be the recovered FCG roots; traversal starts from every node in P ∪ R. Roots provide entry coverage when a toplevel component is not reachable from a predicted anchor. For each node in P ∪ R, N2NMatcher initializes a module at that node and expands along callee edges. Every other predicted anchor serves as a downstream boundary: once such a node is reached, traversal stops before the boundary is included in the current module. Traversals from nodes in P ∪ R are performed independently, so the resulting modules may overlap. This design preserves shared callees and accommodates compiler inlining, through which the same source function may contribute to multiple binary functions and thus to multiple recovered modules. Functions not reached from P ∪ R are retained as singleton modules to ensure full FCG coverage. Thus, N2NMatcher produces an overlapping, coverage-preserving module decomposition rather than a strict partition.

Algorithm 1 Anchor-bounded FCG decomposition. Input: function call graph G = (V, E), predicted anchor set P ⊆V Output: anchor-bounded module set M 1: M ← ∅ − 2: R ← {v ∈ V | deg (v) = 0} 3: C ← P ∪ R 4: Q ← C 5: while Q is not empty do 6: c ← dequeue(Q) 7: m ← {c} 8: S ← successors(c, G) 9: while S is not empty do 10: v ← dequeue(S) 11: if v ∈ / C and v ∈ / m then 12: m ← m ∪ {v} 13: S ← S ∪ successors(v, G) 14: end if 15: end while 16: M ← M ∪ {m} 17: end while S 18: Vcovered ← m∈M m 19: for each v ∈ V \ Vcovered do 20: M ← M ∪ {{v}} 21: end for 22: return M

E. Module-Level Matching Given a query binary and a candidate binary, N2NMatcher first applies the above decomposition procedure to obtain two module sets, denoted as Mq and Mc . The task of modulelevel matching is to rank candidate modules in Mc for each query module mq ∈ Mq . N2NMatcher follows the module matching framework of ModX, which compares two modules using the three components shown in Figure 6: Syntactic Similarity, Semantic Similarity, and Graph Similarity. Syntactic Similarity is derived from string literals and constant values extracted from the modules. Graph Similarity captures module call-graph topology using graph-kernel and edge-topology information. The main difference between N2NMatcher and ModX lies in how Semantic Similarity is computed. ModX compares function-level representations and aggregates selected function-pair similarities into a module-level score. This function-level aggregation becomes fragile under function inlining, where the granularity of recovered binary functions may differ across compilation variants. For example, a function in one binary may contain the inlined code of several source functions, while the corresponding code remains distributed across multiple functions in another binary. In such cases, oneto-one function comparisons can underestimate the similarity between two modules that still cover related source-level behavior. Let ev denote the semantic embedding of a recovered binary function v, obtained from a pretrained binary function encoder. For each module m, N2NMatcher constructs the directed FCG

subgraph induced by its member functions and uses their function embeddings as node features. Each graph-encoding layer aggregates caller and callee representations separately, combines them with the current node state, and applies a residual connection followed by normalization. Gated attention pooling, together with a mean-pooled residual, then produces a normalized module graph embedding g(m). Given two modules mq and mc , their Semantic Similarity is the cosine similarity between g(mq ) and g(mc ). Training uses source mappings only to construct contrastive supervision. Let S(m) denote the set of source functions mapped to module m. We define their source-function Dice as 2|S(mq ) ∩ S(mc )| . (11) D(mq , mc ) = |S(mq )| + |S(mc )| Candidates with D(mq , mc ) > 0 are treated as positives and weighted by their Dice scores, whereas candidates with zero source overlap are treated as negatives. Among candidates with zero source overlap, we prioritize those receiving high scores from the fixed combination of Syntactic Similarity, Graph Similarity, and the function-level semantic similarity used by ModX. These hard negatives resemble the query according to binary-only evidence and therefore provide more informative contrastive supervision. The resulting multi-positive contrastive objective brings sourceoverlapping modules closer while separating non-overlapping modules. Source mappings are not used to construct embeddings or rank candidates at inference time. Given a query module mq and a candidate module mc , N2NMatcher computes their matching score by combining Syntactic Similarity, Semantic Similarity, and Graph Similarity: S(mq , mc ) = αSimsyn (mq , mc ) + βSimsem (mq , mc ) + γSimgraph (mq , mc ).

(12)

Here, Simsyn , Simsem , and Simgraph denote Syntactic Similarity, Semantic Similarity, and Graph Similarity, respectively. Syntactic Similarity and Graph Similarity follow the ModX implementations, whereas Semantic Similarity is computed from the contrastively learned module graph embeddings. The three components are combined using a configuration selected on a disjoint validation set and fixed before testing. For each query module, N2NMatcher ranks candidate modules according to their matching scores. Because the semantic representation jointly models function embeddings and module-internal call structure, the comparison does not require one-to-one correspondence between recovered functions and is therefore less sensitive to function-granularity changes introduced by inlining. V. E VALUATION This section evaluates N2NMatcher on binary decomposition and module-level matching under cross-compilation settings. We first compare N2NMatcher with existing methods on BinKit and then assess its effectiveness in third-party component reuse scenarios derived from ISRD [8]. We further study how the main design choices affect the results and measure the

runtime overhead of the framework. The evaluation answers the following questions: • RQ1. How effective is N2NMatcher in binary decomposition and module matching compared with existing methods? • RQ2. How effective is N2NMatcher in identifying reused modules in third-party component reuse scenarios? • RQ3. How do the anchor prediction model and the implementation of Semantic Similarity affect N2NMatcher? • RQ4. What is the runtime overhead of N2NMatcher compared with existing decomposition and matching baselines? A. Experiment Setup 1) Datasets and Splitting: BinKit. We conduct the main decomposition and matching experiments on the 3,024 x8664 binaries from 84 executable targets and 28 open-source projects described in Section III. Source-grounded labels and evaluation oracles are derived from the corresponding binaries with debug information and transferred to their stripped counterparts. To avoid project leakage, we use project-level ten-fold cross-validation. For each held-out test fold, eight folds are used for training and one for validation. Anchor-prediction and module-matching configurations are selected only on the validation fold and fixed before testing. For fair comparison, N2NMatcher and all baselines are evaluated on the same stripped binaries. ISRD. To assess generalization beyond BinKit in RQ2, we use a regenerated LTO dataset aligned with the binaries retained by ISRD [8]. The corpus contains 608 x86-64 stripped binaries from 26 source projects, compiled with GCC 8.2.0 and Clang 7.0 at optimization levels O0–O3. Ground truth is constructed from source-function correspondences within the original ISRD reuse relations, as detailed in RQ2. We retain 864 debug-line-verified positive binary pairs. N2NMatcher is trained on BinKit and transferred to ISRD without tuning. 2) Baselines: We compare N2NMatcher with two binary decomposition baselines. ModX [6] is a clustering-based decomposition method that groups functions according to FCG structure and supports module matching with Syntactic Similarity, Semantic Similarity, and Graph Similarity. BMVul [14] decomposes binaries with graph community detection and is used as a decomposition baseline. Since BMVul does not define a downstream module matching stage comparable to ModX, it is included only in the binary decomposition comparison in RQ1. ModX is used in both the BinKit module matching comparison and the ISRD external validation. 3) Evaluation Metrics: We use separate metrics for anchor prediction, decomposition quality, and module matching. Anchor prediction metrics evaluate the identification of binary functions that serve as stable boundaries, decomposition metrics measure whether generated modules preserve source-level semantics across compilation variants, and module matching metrics evaluate whether these modules can retrieve semantically corresponding modules from another stripped binary. Anchor prediction metrics. Anchor prediction is evaluated over source-verified binary functions represented as

FCG nodes. Binary functions labeled as source-verified stable boundaries are positives, other source-verified binary functions are negatives, and unlabeled FCG nodes are excluded. Let T P , F P , and F N denote the numbers of true positives, false positives, and false negatives, respectively. We report precision, recall, and F1: TP . (13) TP + FP TP Recall = . (14) TP + FN 2 Precision Recall . (15) F1 = Precision + Recall Decomposition metrics. We use module decomposition quality (MDQ) to measure how well a generated module aligns with modules in another binary. For a module m, let V (m) be its binary-function set and let µ(f ) be the source functions mapped from binary function f . For a query S module mq and a reference module mr , we define Sq = f ∈V (mq ) µ(f ), with Sr defined analogously. Thus, Sq and Sr contain the distinct mapped source functions of the two modules. At the source-function level, module overlap is measured using the Sørensen–Dice similarity: Precision =

Simfunc (mq , mr ) =

2|Sq ∩ Sr | . |Sq | + |Sr |

(16)

To account for function size, we also define a functionlength-weighted similarity, where each source function is weighted by its source-line length ℓ(s): P 2 s∈Sq ∩Sr ℓ(s) P Simlen (mq , mr ) = P . (17) s∈Sq ℓ(s) + s∈Sr ℓ(s) Here, |Sq ∩ Sr | is the number of mapped source functions P shared by the two modules, while s∈Sq ∩Sr ℓ(s) is their total source-line length. The denominators normalize these shared quantities by the combined function count or sourceline length of the two modules. Both similarities range from 0 to 1: 0 indicates that the modules share no mapped source function, whereas 1 indicates identical mapped source-function content under the corresponding weighting. Let Mq and Mr denote the sets of modules recovered from the query and reference binaries, respectively. For either similarity measure, MDQ is defined as MDQτ (mq ) = max Simτ (mq , mr ), mr ∈Mr

τ ∈ {func, len}.

(18) Thus, MDQτ (mq ) is the highest source-level overlap between mq and any module in the reference binary. It measures the best achievable source-level alignment under a given decomposition, independent of any learned module matcher. Each binary pair is evaluated directionally, so both A → B and B → A are counted. Query modules with Sq = ∅ are excluded because their source-level overlap cannot be evaluated. We define that a query module is overlap-eligible if MDQfunc (q) > 0. The set of all overlap-eligible queries is therefore Q+ = {q ∈ Mq | MDQfunc (q) > 0}.

(19)

All decomposition statistics reported below (Avg MDQ, Perfect, and Avg Size) are computed over Q+ . Avg MDQ is the average MDQ, Perfect is the proportion of queries with MDQ equal to 1.0, and Avg Size is the average number of recovered binary functions per query module. Module matching metrics. For downstream module matching, candidate modules are ranked using binary-derived module similarities. Because Q+ is defined using MDQ over the complete reference set Mr , query eligibility is independent of the ranked candidate list produced by the matcher. For each q ∈ Q+ , let (cq,1 , cq,2 , . . .) be its ranked candidate list. Top-1 Similarity measures the source-function Dice between q and the top-ranked candidate: 1 X Simfunc (q, cq,1 ). (20) Top1Sim = + |Q | + q∈Q

Recall@k measures whether the top-k list contains a sourceoverlapping candidate: 1 X I [∃j ≤ k, Simfunc (q, cq,j ) > 0] . Recall@k = + |Q | q∈Q+ (21) We also report mean reciprocal rank (MRR), computed from the rank of the first candidate cq,j satisfying Simfunc (q, cq,j ) > 0 and averaged over the same query set. Thus, Top-1 Similarity, Recall@k, and MRR are all computed over overlap-eligible queries. All reported test point estimates are pooled at the query level. Avg MDQ, defined above, characterizes the decomposition-imposed upper bound independently of the learned ranking. 4) Implementation Details: During graph construction, we use IDA Pro [43] to recover FCGs and ACFGs, Capstone [44] to identify direct cross-function jumps, and Readelf [45] to obtain supervision and evaluation mappings. Compiler, optimization, and symbol-name metadata are not used as model inputs. For anchor prediction, the hierarchical ACFG–FCG encoder is trained with AdamW. Predicted anchors and FCG roots are then processed by the decomposition procedure described above. For module matching, we use the released Gemini checkpoint [46] in inference-only mode to obtain function embeddings from the IDA-derived ACFGs. The module graph encoder contains two directed message-passing layers followed by gated attention pooling with a mean residual. The encoder and matching weights (α, β, γ) are selected exclusively on the validation folds according to mean MRR. This yields α = 0.475, β = 0.350, and γ = 0.175 for Syntactic Similarity, Semantic Similarity, and Graph Similarity, respectively. All selected configurations are frozen before testing. All experiments are conducted on a Windows 11 workstation with an Intel Core Ultra 9 185H processor, 32 GB of memory, and an NVIDIA GeForce RTX 4070 GPU with 8 GB of memory. B. RQ1: Comparison with Existing Methods on BinKit RQ1 evaluates N2NMatcher on BinKit at both stages of the pipeline: binary decomposition and module matching.

TABLE I A NCHOR PREDICTION UNDER DIFFERENT THRESHOLDS . Threshold 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00

Precision 0.486 0.536 0.575 0.611 0.640 0.671 0.710 0.765 0.828 1.000

Recall 0.939 0.900 0.851 0.797 0.724 0.605 0.475 0.327 0.213 0.001

F1 0.640 0.672 0.687 0.692 0.679 0.636 0.570 0.458 0.339 0.002

1) Binary Decomposition: Before evaluating decomposition quality, we first examine how the validation-selected anchor threshold affects anchor prediction against sourceverified labels. Table I reports anchor prediction precision, recall, and F1 under different thresholds. Lower thresholds preserve higher recall, whereas higher thresholds improve precision. We select 0.4 because it achieves the highest validation F1. Table II compares N2NMatcher, ModX, and BMVul on binary decomposition across the three cross-compilation settings. N2NMatcher and BMVul produce overlap-allowed regions, whereas ModX produces an exclusive partition. N2NMatcher achieves the highest Avg MDQ in all three settings under both source-function and function-length-weighted evaluation. Its overall source-function Avg MDQ is 0.793, compared with 0.667 for ModX and 0.687 for BMVul. BMVul has the highest Perfect ratio, 53.43%, but its overall Avg MDQ remains below N2NMatcher, showing that more exact matches do not yield stronger average alignment across all evaluated queries. This consistent advantage indicates that anchor-bounded decomposition preserves source-level alignment across compilation variants more effectively than the baseline decompositions. 2) Module Matching: Table III compares N2NMatcher and ModX in an end-to-end module matching experiment over 3,000 sampled stripped-binary pairs, with each method using its own decomposition output. Overall, N2NMatcher outperforms ModX on all four metrics: Top-1 Similarity is 0.562 versus 0.364, Recall@1 is 0.782 versus 0.487, Recall@5 is 0.871 versus 0.616, and MRR is 0.823 versus 0.550. This consistent end-to-end advantage indicates that combining anchor-bounded decomposition with module graph embeddings improves module retrieval over the ModX pipeline. For N2NMatcher, the cross-compiler and cross-optimization settings yield similar results, with Top-1 Similarity values of 0.587 and 0.601 and MRR values of 0.839 and 0.835. When both compiler and optimization differ, these metrics decrease to 0.493 and 0.792, respectively. This indicates that N2NMatcher is robust when either the compiler or the optimization level changes, although simultaneous changes in both dimensions make module matching more challenging.

TABLE II B INARY DECOMPOSITION EVALUATION ON B IN K IT. Setting Cross-Compiler, Same-Optimization

Same-Compiler, Cross-Optimization

Cross-Compiler, Cross-Optimization

Overall

Method N2NMatcher ModX BMVul N2NMatcher ModX BMVul N2NMatcher ModX BMVul N2NMatcher ModX BMVul

Avg Size 6.34 1.50 8.30 6.42 1.50 8.89 6.72 1.52 9.60 6.49 1.50 8.88

Avg MDQ (Func.) 0.807 0.725 0.780 0.809 0.676 0.673 0.759 0.592 0.589 0.793 0.667 0.687

Avg MDQ (Len.-Wtd.) 0.800 0.733 0.783 0.801 0.706 0.686 0.748 0.620 0.602 0.784 0.689 0.697

Perfect 33.85% 43.82% 64.44% 40.80% 41.20% 52.11% 28.05% 27.83% 41.31% 34.34% 37.93% 53.43%

TABLE III M ODULE MATCHING EVALUATION ON B IN K IT. Setting Cross-Compiler, Same-Optimization Same-Compiler, Cross-Optimization Cross-Compiler, Cross-Optimization Overall

Method N2NMatcher ModX N2NMatcher ModX N2NMatcher ModX N2NMatcher ModX

C. RQ2: Third-Party Component Reuse RQ2 examines whether N2NMatcher generalizes from BinKit to cross-project component reuse on ISRD. Table IV compares N2NMatcher and ModX using 16,166 cross-project source-function correspondences as ground truth. Of the 864 positive binary pairs, 562 yield at least one query module with a source-corresponding candidate in each direction and therefore enter the ranking evaluation. Overall, N2NMatcher outperforms ModX on all four metrics: Top-1 Similarity is 0.231 versus 0.182, Recall@1 is 0.444 versus 0.288, Recall@5 is 0.650 versus 0.528, and MRR is 0.541 versus 0.405. Across the 562 evaluated pairs, all four paired improvements are statistically significant, indicating that N2NMatcher more accurately localizes reused modules than ModX in the cross-project setting. Nevertheless, the absolute Top-1 Similarity and MRR of N2NMatcher are lower than on BinKit, where they reach 0.562 and 0.823. BinKit compares compilation variants of the same target, whereas ISRD matches reused source regions embedded in different projects, whose surrounding functions and call structures may differ substantially. Moreover, the model and matching weights are selected on BinKit and transferred to ISRD without dataset-specific tuning. The lower absolute results therefore reflect both the greater difficulty of cross-project partial reuse and the resulting domain shift. D. RQ3: Ablation Study RQ3 uses controlled ablations to isolate the contributions of hierarchical anchor prediction and module graph embeddings. Table V compares the hierarchical anchor predictor with ACFG-only and FCG-only variants. Table VI compares module graph and function-level embeddings with the N2NMatcher decomposition fixed.

Top-1 Sim. 0.587 0.401 0.601 0.412 0.493 0.272 0.562 0.364

Recall@1 0.798 0.523 0.798 0.522 0.748 0.407 0.782 0.487

Recall@5 0.888 0.673 0.879 0.631 0.843 0.535 0.871 0.616

MRR 0.839 0.594 0.835 0.577 0.792 0.472 0.823 0.550

The hierarchical predictor achieves the highest anchor F1 (0.692) and Avg MDQ (0.793). Removing FCG propagation reduces these values to 0.549 and 0.665. Relative to FCGonly, adding ACFG evidence raises precision from 0.550 to 0.611 and F1 from 0.670 to 0.692, despite reducing recall from 0.858 to 0.797. Together, these results support combining intraprocedural ACFG evidence with interprocedural FCG context for anchor prediction. With decomposition fixed, the module graph embedding outperforms the function-level embedding on all four metrics, increasing Top-1 Similarity from 0.5515 to 0.5621 and MRR from 0.8137 to 0.8228. The module graph embedding improves MRR in all ten held-out test folds, and the improvement remains statistically significant after Holm correction (adjusted p = 0.0078). This controlled comparison supports using module-internal FCG structure rather than function embeddings alone. E. RQ4: Runtime Overhead RQ4 measures how the decomposition and modulematching runtimes scale with FCG size. Figure 7 compares decomposition runtime from prebuilt FCGs and ACFGs to generated modules across five FCG-size ranges. The measurement includes all processing within this boundary: anchor prediction and anchor-bounded decomposition for N2NMatcher, and the corresponding decomposition procedures for ModX and BMVul. Disassembly, FCG and ACFG construction, and training are excluded. All measurements are executed serially, and each binary is measured once. N2NMatcher is slower than ModX on small binaries, but the gap narrows with FCG size and reaches 1.02× at 3,000 nodes or more. It remains 9.1–16.7× faster than BMVul, indicating

TABLE IV M ODULE RETRIEVAL EVALUATION ON ISRD. Setting Cross-Compiler, Same-Optimization Same-Compiler, Cross-Optimization Cross-Compiler, Cross-Optimization Overall

Method N2NMatcher ModX N2NMatcher ModX N2NMatcher ModX N2NMatcher ModX

Top-1 Sim. 0.280 0.249 0.225 0.174 0.190 0.120 0.231 0.182

TABLE V A NCHOR - PREDICTOR ABLATION .

TABLE VI S EMANTIC REPRESENTATION ABLATION . Configuration Top-1 Sim. Recall@1 Recall@5 MRR Module graph embedding 0.5621 0.7821 0.8708 0.8228 Function-level embedding 0.5515 0.7715 0.8634 0.8137

that anchor prediction adds limited decomposition overhead at larger scales. Figure 8 compares end-to-end matching runtime across five ranges defined by the larger FCG in each binary pair. Timing starts from each method’s generated modules and the prebuilt FCGs and ACFGs, and ends with ranked candidate modules. For both methods, it includes Gemini inference for function embeddings, the computation of Syntactic, Semantic, and Graph Similarity, and module ranking; N2NMatcher additionally includes loading and applying the module graph encoder. Matching time is comparable below 500 nodes. Across the complete batch, N2NMatcher requires 4.01 hours versus 3.12 hours for ModX, an overhead of 28.3%. Applying the module graph encoder adds only 13.0 seconds; most of the additional cost occurs during module ranking.

Recall@5 0.679 0.615 0.631 0.502 0.641 0.465 0.650 0.528

N2NMatcher

Mean decomposition time (s)

Anchor Prediction Decomposition Precision Recall F1 Avg MDQ Hierarchical ACFG–FCG 0.611 0.797 0.692 0.793 ACFG only 0.460 0.680 0.549 0.665 FCG only 0.550 0.858 0.670 0.786 Configuration

Recall@1 0.482 0.368 0.442 0.272 0.409 0.223 0.444 0.288

−1

−2

<100

MRR 0.577 0.486 0.532 0.385 0.514 0.342 0.541 0.405

ModX

BMVul

100-500 500-1K 1K-3K Number of FCG nodes

>=3K

Fig. 7. Decomposition runtime by FCG size.

Fig. 8. Module matching runtime by FCG size.

VI. D ISCUSSION FCG changes caused by optimizations other than inlining. Several compiler transformations besides inlining can alter recovered FCGs. Dead-code and unreachable-function elimination remove nodes and incident edges; function cloning, specialization, and interprocedural constant propagation may duplicate functions or eliminate calls; function merging and code folding may collapse distinct functions; outlining and function splitting may introduce additional nodes; and tailcall conversion or indirect-call resolution may redirect edges. Inlining nevertheless remains a major measured contributor: 217,649 of 855,226 source-mapped binary functions (25.45%) contain mappings to multiple source functions, and this proportion rises from 0.25% at O0 to 23.87%, 46.46%, and 63.97% at O1, O2, and O3, respectively. Our source-grounded

anchor labeling remains applicable under these transformations because it relies on binary-to-source mappings across configurations rather than unchanged FCG topology. A source function need not be recovered in every configuration; where it is recovered as an OSF and it is never observed as inlined under another OSF, it is labeled as an anchor. Thus, node or edge removal, duplication, merging, splitting, and redirection do not by themselves invalidate the labeling procedure. Performance degradation on ISRD and potential improvements. N2NMatcher achieves lower absolute retrieval scores on ISRD than on BinKit because the two datasets represent different matching conditions. BinKit compares compilation variants of the same target, whereas ISRD contains partial reuse across different projects, so reused functions may

be surrounded by unrelated code and participate in different call structures. Moreover, the trained module graph encoder and matching weights are selected on BinKit and transferred to ISRD without cross-project adaptation. Future work could train the module encoder with project-disjoint cross-project reuse pairs, use hard negatives from unrelated projects, and select matching weights on a separate cross-project validation set. Partial-graph alignment or attention that suppresses project-specific context may further improve the localization of modified reused regions. VII. T HREATS TO VALIDITY Internal validity. Errors in recovered function boundaries, call edges, basic blocks, or instructions may affect the results [47]. We use the same IDA Pro [43] pipeline for all methods, but different methods may respond differently to these errors. External validity. The evaluation covers x86-64 LTO binaries from BinKit and ISRD compiled with GCC or Clang. Results may differ for other architectures, toolchains, non-LTO or obfuscated binaries, and open-world component detection. Construct validity. Training labels and relevance judgments rely on debug-line mappings, which may be incomplete under optimization and may not capture all forms of semantic reuse. The conservative ISRD oracle may miss modified functions, and Avg MDQ may favor coarse modules. We therefore report Perfect and Avg Size as complementary decomposition metrics. VIII. C ONCLUSION We presented N2NMatcher, an inlining-resilient framework for binary decomposition and module matching. Our sourcegrounded study shows that compilation variance disrupts FCG structure and function-level alignment while leaving stable boundary nodes. Based on this finding, we designed N2NMatcher to predict these boundaries, construct anchorbounded modules, and match them with module graph embeddings. Our experiments show that it outperforms ModX and BMVul in decomposition and ModX in module matching on BinKit, and raises Recall@1 over ModX from 0.288 to 0.444 on ISRD. In future work, we will improve N2NMatcher’s ability to identify reused modules under more challenging conditions, including unseen projects, diverse architectures and toolchains, and open-world reuse scenarios. We hope that our study could provide useful insights for future research on program-level binary analysis. R EFERENCES [1] R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,” Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018. [2] “2025 Open Source Security and Risk Analysis Report,” https://www. blackduck.com/content/dam/black-duck/en-us/reports/rep-ossra.pdf, 2025, [Online; accessed 9-August-2026]. [3] A. Gkortzis, D. Feitosa, and D. Spinellis, “Software reuse cuts both ways: An empirical analysis of its relationship with security vulnerabilities,” Journal of Systems and Software, vol. 172, p. 110653, 2021.

[4] “madler/zlib GitHub Repository,” https://github.com/madler/zlib, 2026, [Online; accessed 9-August-2026]. [5] “curl/curl GitHub Repository,” https://github.com/curl/curl, 2026, [Online; accessed 9-August-2026]. [6] C. Yang, Z. Xu, H. Chen, Y. Liu, X. Gong, and B. Liu, “Modx: binary level partially imported third-party library detection via program modularization and semantic matching,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 1393– 1405. [7] S. Li, Y. Wang, C. Dong, S. Yang, H. Li, H. Sun, Z. Lang, Z. Chen, W. Wang, H. Zhu et al., “Libam: An area matching framework for detecting third-party libraries in binaries,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 2, pp. 1–35, 2023. [8] X. Xu, Q. Zheng, Z. Yan, M. Fan, A. Jia, and T. Liu, “Interpretation-enabled software reuse detection based on a multi-level birthmark model,” in 43rd IEEE/ACM International Conference on Software Engineering, ICSE 2021, Madrid, Spain, 22-30 May 2021. IEEE, 2021, pp. 873–884. [Online]. Available: https://doi.org/10.1109/ ICSE43902.2021.00084 [9] C. Dong, S. Li, S. Yang, Y. Xiao, Y. Wang, H. Li, Z. Li, and L. Sun, “Libvdiff: Library version difference guided oss version identification in binaries,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 2024, pp. 1–12. [10] W. Tang, Y. Wang, H. Zhang, S. Han, P. Luo, and D. Zhang, “Libdb: An effective and efficient framework for detecting third-party libraries in binaries,” in Proceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 423–434. [11] X. Zhu, J. Wang, Z. Fang, X. Yin, and S. Liu, “Bbdetector: A precise and scalable third-party library detection in binary executables with finegrained function-level features,” Applied Sciences, vol. 13, no. 1, p. 413, 2022. [12] H. Sun, H. Shu, F. Kang, and Y. Guang, “Moddiff: modularity similaritybased malware homologation detection,” Electronics, vol. 12, no. 10, p. 2258, 2023. [13] V. Karande, S. Chandra, Z. Lin, J. Caballero, L. Khan, and K. Hamlen, “Bcd: Decomposing binary code into components using graph-based clustering,” in Proceedings of the 2018 on Asia Conference on Computer and Communications Security, 2018, pp. 393–398. [14] X. Guo, R. Cai, X. Yin, W. Shao, and S. Liu, “Searching opensource vulnerability function based on software modularization,” Applied Sciences, vol. 13, no. 2, p. 701, 2023. [15] W. Tang, P. Luo, J. Fu, and D. Zhang, “Libdx: A cross-platform and accurate system to detect third-party libraries in binary code,” in 2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2020, pp. 104–115. [16] M. Backes, S. Bugiel, and E. Derr, “Reliable third-party library detection in android and its security applications,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 356–367. [17] M. Li, W. Wang, P. Wang, S. Wang, D. Wu, J. Liu, R. Xue, and W. Huo, “Libd: Scalable and precise third-party library detection in android markets,” in 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 2017, pp. 335–346. [18] Z. Ma, H. Wang, Y. Guo, and X. Chen, “Libradar: Fast and accurate detection of third-party libraries in android apps,” in Proceedings of the 38th international conference on software engineering companion, 2016, pp. 653–656. [19] X. Zhan, L. Fan, S. Chen, F. We, T. Liu, X. Luo, and Y. Liu, “Atvhunter: Reliable version detection of third-party libraries for vulnerability identification in android applications,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, pp. 1695– 1707. [20] X. Zhan, L. Fan, T. Liu, S. Chen, L. Li, H. Wang, Y. Xu, X. Luo, and Y. Liu, “Automated third-party library detection for android applications: Are we there yet?” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 919–930. [21] J. Zhang, A. R. Beresford, and S. A. Kollmann, “Libid: reliable identification of obfuscated third-party android libraries,” in Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2019, pp. 55–65. [22] Y. Zhang, J. Dai, X. Zhang, S. Huang, Z. Yang, M. Yang, and H. Chen, “Detecting third-party libraries in android applications with high precision and recall,” in 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2018, pp. 141–152.

[23] M. E. Newman, “Fast algorithm for detecting community structure in networks,” Physical Review E—Statistical, Nonlinear, and Soft Matter Physics, vol. 69, no. 6, p. 066133, 2004. [24] M. Chandramohan, Y. Xue, Z. Xu, Y. Liu, C. Y. Cho, and H. B. K. Tan, “Bingo: Cross-architecture cross-os binary search,” in Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2016, pp. 678–689. [25] S. H. Ding, B. C. Fung, and P. Charland, “Asm2vec: Boosting static representation robustness for binary clone search against code obfuscation and compiler optimization,” in 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp. 472–489. [26] A. Jia, M. Fan, W. Jin, X. Xu, Z. Zhou, Q. Tang, S. Nie, S. Wu, and T. Liu, “1-to-1 or 1-to-n? investigating the effect of function inlining on binary similarity analysis,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 4, pp. 1–26, 2023. [27] A. Jia, M. Fan, X. Xu, W. Jin, H. Wang, Q. Tang, S. Nie, S. Wu, and T. Liu, “Comparing one with many–solving binary2source function matching under function inlining,” arXiv preprint arXiv:2210.15159, 2022. [28] A. Jia, M. Fan, X. Xu, W. Jin, H. Wang, and T. Liu, “Cross-inlining binary function similarity detection,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–13. [29] W. Lin, Q. Guo, D. Yu, J. Yin, Q. Gong, and X. Gong, “Reifunc: Identifying recurring inline functions in binary code,” in 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2024, pp. 670–680. [30] Z. Sha, Y. Lan, C. Zhang, H. Wang, Z. Gao, B. Zhang, and H. Shu, “Optrans: enhancing binary code similarity detection with function inlining re-optimization,” Empirical Software Engineering, vol. 30, no. 2, p. 49, 2025. [31] J. Qiu, X. Su, and P. Ma, “Library functions identification in binary code by using graph isomorphism testings,” in 2015 ieee 22nd international conference on software analysis, evolution, and reengineering (saner). IEEE, 2015, pp. 261–270. [32] ——, “Using reduced execution flow graph to identify library functions in binary code,” IEEE Transactions on Software Engineering, vol. 42, no. 2, pp. 187–202, 2016. [33] T. Ahmed, P. Devanbu, and A. A. Sawant, “Learning to find usages of library functions in optimized binaries,” IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 3862–3876, 2022. [34] L. Binosi, M. Polino, M. Carminati, and S. Zanero, “Bino: Automatic recognition of inline binary functions from template classes,” Computers & Security, vol. 132, p. 103312, 2023. [35] W. Lin, Q. Guo, J. Yin, X. Zuo, R. Wang, and X. Gong, “Fsmell: recognizing inline function in binary code,” in European Symposium on Research in Computer Security. Springer, 2023, pp. 487–506. [36] L. Dall’Aglio, L. Binosi, M. Carminati, S. Zanero, and M. Polino, “Highliner: Enhancing binary analysis through nlp-based instructionlevel detection of c++ inline functions,” ACM Trans. Priv. Secur., vol. 28, no. 4, Oct. 2025. [Online]. Available: https://doi.org/10.1145/3765521 [37] O. Abusabha, J. Uhm, T. Abuhmed, and H. Koo, “A deep dive into function inlining and its security implications for ml-based binary analysis,” in Proceedings of the 2026 Network and Distributed System Security Symposium (NDSS), 2026. [38] A. Jia, H. Jiang, Z. Ren, X. Li, Z. Yang, Y. Duan, M. Fan, and T. Liu, “Towards an oracle for binary decomposition under compilation variance,” ACM Transactions on Software Engineering and Methodology, 2026. [39] D. Kim, E. Kim, S. K. Cha, S. Son, and Y. Kim, “Revisiting binary code similarity analysis using interpretable feature engineering and lessons learned,” IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 1661–1682, 2023. [40] “SoftSec-KAIST/BinKit: Binary Code Similarity Analysis Benchmark,” https://github.com/SoftSec-KAIST/BinKit, 2026, [Online; accessed 9August-2026]. [41] H. Wang, W. Qu, G. Katz, W. Zhu, Z. Gao, H. Qiu, J. Zhuge, and C. Zhang, “jtrans: jump-aware transformer for binary code similarity detection,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2022. New York, NY, USA: Association for Computing Machinery, 2022, p. 1–13. [Online]. Available: https://doi.org/10.1145/3533767.3534367 [42] “Optimize Options (Using the GNU Compiler Collection (GCC)),” https: //gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, 2026, [Online; accessed 9-August-2026]. [43] “IDA Pro Disassembler and Debugger - Hex Rays,” https://hex-rays. com/ida-pro, 2026, [Online; accessed 9-August-2026].

[44] “capstone on PyPI,” https://pypi.org/project/capstone/, 2026, [Online; accessed 9-August-2026]. [45] “readelf(1) — Linux manual page,” https://man7.org/linux/man-pages/ man1/readelf.1.html, 2026, [Online; accessed 9-August-2026]. [46] X. Xu, C. Liu, Q. Feng, H. Yin, L. Song, and D. Song, “Neural networkbased graph embedding for cross-platform binary code similarity detection,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 363–376. [47] C. Pang, R. Yu, Y. Chen, E. Koskinen, G. Portokalidis, B. Mao, and J. Xu, “Sok: All you ever wanted to know about x86/x64 binary disassembly but were afraid to ask,” in 2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 833–851.

N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching

Analyze & explore related research in Conceptio

Related documents