Pith. sign in

REVIEW 3 major objections 5 minor 47 references

N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read N2NMatcher learns stable boundary functions in binaries and uses them to keep module matching accurate even when compilers inline code.

desk verdict A genuinely new empirical finding about stable boundaries under inlining, but the headline decomposition advantage is partly a granularity artifact; still worth refereeing. read the letter →

arxiv 2608.10043 v1 pith:3JM3R3GD submitted 2026-08-10 cs.SE

Ang Jia , He Jiang , Zhipeng Yang , Zhilei Ren , Xiaochen Li This is my paper · ORCID
classification cs.SE
keywords binarycodesimilarityanalysisfunctioninliningdecompositionmodulematchinganchorpredictiongraphneuralnetworkscallsoftwarereusedetection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Function inlining merges multiple source functions into one binary function and rewires the call graph, which breaks the one-to-one function alignment that binary similarity tools normally rely on. This paper argues that, despite that disruption, binaries still contain caller-side functions that survive as standalone binary functions and never appear purely as inlined callees under any observed compilation setting. On that basis it proposes N2NMatcher, which learns to predict these stable boundaries with a hierarchical graph neural network, cuts the call graph into anchor-bounded modules, and matches those modules with learned graph embeddings rather than function-by-function comparisons. If the argument holds, program-level binary similarity, vulnerability search, and third-party reuse detection become more robust to compiler differences.

What carries the argument

The load-bearing mechanism is the anchor-bounded module: a connected region of the function call graph cut at predicted anchor functions, where an anchor is a recovered function whose origin source function is stable across compilation variants. Anchors are predicted by a hierarchical ACFG-FCG encoder, which embeds opcode sequences and basic-block control flow inside each function and then propagates calling-context information over the whole function call graph; the predicted anchors plus recovered roots seed a traversal that expands along callee edges and stops at downstream anchors. Module matching then represents each module as a directed call graph whose node features come from a pretrained function embedder, pools it with gated attention, and scores cosine similarity between module embeddings, combined with syntactic and graph-similarity terms. The anchor-bounded traversal is the step that converts the empirical finding about stable boundaries into a decomposition that keeps source regions aligned across compilation variants.

What would settle it

Take a random sample of optimized binaries, manually reconstruct the true source composition of each binary function with a second independent disassembler or hand analysis, and check whether the debug-line-based stable-boundary labels agree; if the labels frequently disagree, or the reported 42.67% stable-boundary rate and the module-matching gaps do not reproduce under corrected labels, the central claim fails.

Watch

Extended reading notes

Core claim

The central claim is that semantic equivalence across compilation variants survives at the granularity of regions bounded by stable caller-side functions, even though it fails at the granularity of individual binary functions. The paper defines a source-verified stable boundary node as a source function that is recovered as the origin of at least one binary function in some configuration and is never observed inlined under another function's origin in any configuration; in the study's LTO dataset, 42.67% of debug-line-labeled FCG nodes satisfy this condition. N2NMatcher trains an anchor predictor on these labels, decomposes binaries by traversing from predicted anchors and call-graph roots until another anchor blocks the traversal, and compares the resulting modules with graph embeddings learned under source-overlap contrastive supervision. The paper reports that this raises module-level retrieval accuracy over a clustering-based baseline, with top-1 source-function Dice increasing from 0.364 to 0.562 and Recall@1 from 0.487 to 0.782 on its LTO evaluation, and also reports gains on a cross-project reuse corpus.

Load-bearing premise

The load-bearing premise is that debug information and binary-function naming can reliably tell which source function is the origin of a binary function even under O2/O3 optimization; if that oracle is incomplete, the stable-boundary labels and the measured advantage of anchor-bounded matching inherit its errors.

Editorial extensions

If this is right

  • Binary similarity tools can stop assuming that individual binary functions correspond one-to-one across compilations and instead compare the regions between stable boundary functions.
  • Module matching can be performed on stripped binaries using only opcode sequences, control flow, and call-graph context, because training labels come from debug information but inference does not.
  • Anchor-bounded decomposition produces overlapping modules rather than a strict partition, so the same inlined callee can contribute to more than one module without breaking full FCG coverage.
  • In the paper's LTO evaluation, the approach improves average source-level module overlap and top-1 module retrieval accuracy relative to clustering-based baselines across cross-compiler and cross-optimization pairs.
  • The same pipeline, trained on compilation variants, improves cross-project third-party reuse localization relative to a function-level matcher, though absolute accuracy drops when surrounding code differs between projects.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The study's logic suggests a corollary the authors leave implicit: if stable boundaries are as common as reported, anchor-bounded regions could also serve as the natural unit for binary-to-source attribution, giving a coarser alternative to the 1-to-N function matching problem created by inlining.
  • The ablation shows that FCG propagation alone nearly matches the full model on decomposition quality, which hints that calling-context structure, rather than opcode detail, may be the dominant signal for boundary stability; a cheap caller-side heuristic might reproduce much of the gain.
  • A direct stress test would be to compile the same projects with LTO disabled or with transformations that break debug-line attribution; the framework's premise predicts graceful degradation as the fraction of recoverable stable boundaries falls, and the rate of that degradation is measurable.
  • The cross-project drop in absolute accuracy suggests the next bottleneck is not boundary stability but project-specific context in module embeddings, so attention that downweights surrounding project code may matter more than better anchor prediction.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes N2NMatcher, a framework for binary decomposition and module matching intended to be resilient to function inlining. The authors first conduct an empirical study on BinKit LTO binaries with debug information, defining source-verified stable boundary functions and reporting that 42.67% of source-mapped FCG nodes are stable boundaries. They then train a hierarchical ACFG-FCG graph neural network to predict anchor nodes, decompose binaries by traversing from anchors and roots, and match the resulting modules using a combination of syntactic, semantic (learned module graph embedding), and graph similarity. Evaluation on BinKit and on an ISRD-derived corpus reports improvements over ModX in decomposition quality (Avg MDQ) and module matching (Top-1 Similarity, Recall@k, MRR), plus an ablation study and runtime measurements.

Significance. If the decomposition and matching claims hold, N2NMatcher would be a meaningful step toward program-level binary similarity under inlining, a problem that clearly matters for vulnerability search and library reuse detection. The paper has concrete strengths: the anchor concept is well motivated by a source-grounded study; the pipeline is described in detail; project-level cross-validation is used with configurations selected only on validation folds; the implementation is promised on GitHub; and the limitations of debug-line oracles and of the Avg MDQ metric are candidly acknowledged. The central issue is that the quantitative evidence for the decomposition-quality claim is confounded by module granularity, and the ground-truth oracle assumptions are load-bearing and not independently validated.

major comments (3)
  1. [V-B1, Eq. (18)-(19), Table II] The decomposition-quality claim in the Abstract and in Section V-B1 rests on Avg MDQ computed only over overlap-eligible queries Q+. This metric is not size-normalized, and Table II shows that N2NMatcher's modules average 6.49 recovered functions versus 1.50 for ModX. Because MDQ takes the maximum Dice overlap with any reference module, larger query modules tend to have larger S_q, making high overlap easier to achieve and eligibility easier to satisfy by construction. The paper itself concedes in Section VII that "Avg MDQ may favor coarse modules," and Table II's Perfect metric, which does not share this size bias, favors ModX or BMVul in two of the three settings. The claimed advantage in decomposition quality is therefore not established. I ask the authors to report a granularity-controlled evaluation, for example MDQ stratified by module size, a size-matched comparison, or a boundary-alignment metric that does not depend on module size, and to reconsider the decomposition claim in light of the Perfect results.
  2. [III-D, Definition 1, IV-C] A load-bearing assumption is the origin-source-function (OSF) convention: when a binary function maps to multiple source functions, the source function whose name matches the binary function name is treated as the caller-side OSF. This assumption is not validated, and the paper acknowledges in Section VII that debug-line mappings may be incomplete under optimization. Because the same oracle produces the anchor labels, the 42.67% stable-boundary statistic, the MDQ ground truth, and the module-matching relevance labels, a systematic error in the naming convention would propagate into every reported result. I request a validation of the OSF naming assumption on a manually inspected subset or against an independent oracle (e.g., DWARF call-site information or source-level inlining lists), with error rates reported per optimization level and compiler.
  3. [V-B2, Eqs. (20)-(21), Table III] The end-to-end module matching metrics are computed only over each method's own overlap-eligible queries Q+ (Eq. 19), and the query modules are the same coarse modules used in the MDQ evaluation. Since N2NMatcher's modules are about four times larger than ModX's, its Q+ is likely to contain modules that are easier to match by construction, and the Top-1 Similarity and Recall@k improvements in Table III may partially reflect granularity rather than better boundary placement or better semantic matching. I ask for a matching evaluation on a granularity-invariant evaluation unit, such as source-function-seeded regions of fixed size, or at least a report of the results stratified by module size, so that the module-matching claim can be separated from the decomposition granularity confound.
minor comments (5)
  1. [III-D, Eq. (3)] The definition of B_inl_c(s) uses "s is not the OSF but is inlined into the function whose OSF is o(b)"; this is clear for the single-OSF convention, but the case where a binary function maps to multiple source functions and none matches the binary name is not discussed. Please clarify how such functions are handled and whether they are excluded from labeling.
  2. [Eqs. (9), (12)] The symbol alpha is used both for the positive-class weight in the anchor-prediction loss (Eq. 9) and for the Syntactic Similarity weight in the matching score (Eq. 12). Please rename one of them to avoid confusion.
  3. [I, Figure 1] The motivating example would be easier to follow if the figure explicitly marked which source functions are inlined and which are stable boundaries, and if the arrows between the two binary columns were described in the caption.
  4. [V-A4] The description of validation says configurations are selected on validation folds, but Table I reports a single threshold of 0.4. Please state whether the threshold and the matching weights are selected per fold or globally, and whether the reported test results were obtained with fold-specific configurations.
  5. [II-A, References [7]-[15]] The related-work discussion would benefit from a more explicit comparison of N2NMatcher's anchor definition with the function-pair anchors used in ISRD, LibDB, and LibAM; as written, the reader must infer the distinction between source-verified stable boundaries and similarity-based anchor pairs.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation found: the shared debug-line oracle and coarse-module MDQ bias are validity concerns, not definitional reductions.

full rationale

The paper's central pipeline is supervised empirical machine learning, not a derivation that reduces to its inputs. Anchor labels are defined by Definition 1 (Section III-D) from debug-line source mappings; the hierarchical GNN (Section IV-C) is trained on those labels and evaluated under project-level ten-fold cross-validation, so the reported anchor F1 and downstream MDQ reflect held-out generalization rather than an algebraic identity. The module matcher is similarly trained with contrastive supervision from source-function Dice (Eq. 11) and evaluated with the same Dice-based overlap (Eq. 16); this is a standard supervised evaluation loop, not a fitted parameter renamed as a prediction. Self-citations [26] and [38] motivate the problem and dataset choice but are not load-bearing: the paper's own Section III study and Section V experiments carry the argument. The paper explicitly concedes in Section VII that 'Avg MDQ may favor coarse modules' and reports Perfect and Avg Size as complementary metrics; this is an acknowledged metric confound and a correctness risk, not a circularity. No equation is defined in terms of the target claim, and no uniqueness or ansatz is imported from the authors' prior work to force the result. Accordingly, no circular step meets the quoted-reduction bar; the minor self-citations are not load-bearing, so the score is low.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

No new physical or modeled entity is introduced; anchors are labels assigned to existing recovered binary functions, so the graviton-style weakness does not apply. The central free parameters are validation-selected thresholds and weights, and the main assumptions concern the debug-line oracle and the operational definition of stability.

free parameters (4)
  • anchor prediction threshold tau = 0.4
    Selected on validation folds by highest F1 (Table I) and then fixed for held-out test binaries; it determines which predicted anchors enter the decomposition.
  • module similarity weights alpha, beta, gamma = alpha=0.475, beta=0.350, gamma=0.175
    Selected on validation folds according to mean MRR and fixed before testing (Section V-A4); these weights directly control the final matching score.
  • number of GNN layers = two ACFG layers; module graph encoder two layers; FCG layer count unspecified
    The ACFG encoder uses two message-passing layers and the module encoder uses two directed layers; the FCG message-passing depth is not stated. These architectural choices affect the learned representations.
  • opcode hash space and embedding dimensions = not reported in manuscript
    The size of the deterministic hash token space and the hidden dimensions of the encoders are not listed, so a reproducing group must choose them independently.
assumptions (5)
  • domain assumption Binary-to-source mapping from debug-line tables is accurate enough to serve as a semantic oracle.
    Every SQ1-SQ3 result and every MDQ/retrieval label treats M(b), the set of source functions mapped to a binary function, as ground-truth semantics. Section III-A2 defines the mapping, and Section VII admits debug-line mappings may be incomplete under optimization.
  • ad hoc to paper The origin source function of a mixed binary function is the source function whose name matches the binary function name.
    Section III-D states: "If b maps to multiple source functions... the source function whose name matches the binary function name is treated as the caller-side OSF." This heuristic is load-bearing for defining stable boundaries.
  • ad hoc to paper A source function is a stable boundary if it is an OSF in some configuration and never appears as an inlined callee under another OSF.
    Definition 1 (Eq. 3) is the operational definition of a source-verified stable boundary node and generates all anchor labels used for training and evaluation.
  • domain assumption Module semantic equivalence is adequately measured by source-function Dice overlap.
    Equations 11, 16, and 20 use source-function sets as the relevance oracle. This assumes source-level overlap captures the notion of code reuse that BCSA targets, which may miss semantically equivalent code that does not map cleanly to the same source names.
  • domain assumption What is learned on same-project compilation variants transfers to cross-project partial reuse.
    The model and weights are trained and selected on BinKit and applied to ISRD without tuning (Section V-A1/2). The performance drop on ISRD indicates that this transfer assumption holds only partially.

how reviews work

0 comments
Cite this review

Pith. "Pith review of N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching." pith.science (2026). https://pith.science/paper/3JM3R3GD

@misc{pith2026260810043,
  author       = {Pith},
  title        = {Pith review of: N2NMatcher: Towards Inlining-Resilient Binary Decomposition and Module Matching},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3JM3R3GD}},
  note         = {Machine review of arXiv:2608.10043}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2608.10043 by the authors.

Figure 1
Figure 1. A motivating example for binary decomposition in program-level BCSA. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. FCG structural changes across compiler-optimization settings. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Inlining-affected binary functions across compiler-optimization set [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: Composition of stable boundary nodes in the LTO dataset. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Overview of N2NMatcher for binary decomposition and module matching. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Decomposition runtime by FCG size [PITH_FULL_IMAGE:figures/full_fig_p013_7.png]
Figure 8
Figure 8. 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 infer…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 43 canonical work pages

  1. [1]

    Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,

    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

    2018

  2. [2]

    2025 Open Source Security and Risk Analysis Report,

    “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]

    work page 2025

  3. [3]

    Software reuse cuts both ways: An empirical analysis of its relationship with security vulnerabil- ities,

    A. Gkortzis, D. Feitosa, and D. Spinellis, “Software reuse cuts both ways: An empirical analysis of its relationship with security vulnerabil- ities,”Journal of Systems and Software, vol. 172, p. 110653, 2021

    work page 2021

  4. [4]

    madler/zlib GitHub Repository,

    “madler/zlib GitHub Repository,” https://github.com/madler/zlib, 2026, [Online; accessed 9-August-2026]

    work page 2026

  5. [5]

    curl/curl GitHub Repository,

    “curl/curl GitHub Repository,” https://github.com/curl/curl, 2026, [On- line; accessed 9-August-2026]

    work page 2026

  6. [6]

    Modx: binary level partially imported third-party library detection via program modularization and semantic matching,

    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,” inProceedings of the 44th International Conference on Software Engineering, 2022, pp. 1393– 1405

    work page 2022

  7. [7]

    Libam: An area matching framework for de- tecting third-party libraries in binaries,

    S. Li, Y . Wang, C. Dong, S. Yang, H. Li, H. Sun, Z. Lang, Z. Chen, W. Wang, H. Zhuet al., “Libam: An area matching framework for de- tecting third-party libraries in binaries,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 2, pp. 1–35, 2023

    work page 2023

  8. [8]

    Interpretation-enabled software reuse detection based on a multi-level birthmark model,

    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,” in43rd 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

    arXiv 2021

Show all 47 references
  1. [9]

    Libvdiff: Library version difference guided oss version identification in binaries,

    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,” inProceedings of the 46th IEEE/ACM International Con- ference on Software Engineering, 2024, pp. 1–12

    2024

  2. [10]

    Libdb: An effective and efficient framework for detecting third-party libraries in binaries,

    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,” inProceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 423–434

    2022

  3. [11]

    Bbdetector: A precise and scalable third-party library detection in binary executables with fine- grained function-level features,

    X. Zhu, J. Wang, Z. Fang, X. Yin, and S. Liu, “Bbdetector: A precise and scalable third-party library detection in binary executables with fine- grained function-level features,”Applied Sciences, vol. 13, no. 1, p. 413, 2022

    2022

  4. [12]

    Moddiff: modularity similarity- based malware homologation detection,

    H. Sun, H. Shu, F. Kang, and Y . Guang, “Moddiff: modularity similarity- based malware homologation detection,”Electronics, vol. 12, no. 10, p. 2258, 2023

    2023

  5. [13]

    Bcd: Decomposing binary code into components using graph-based clustering,

    V . Karande, S. Chandra, Z. Lin, J. Caballero, L. Khan, and K. Hamlen, “Bcd: Decomposing binary code into components using graph-based clustering,” inProceedings of the 2018 on Asia Conference on Computer and Communications Security, 2018, pp. 393–398

    2018

  6. [14]

    Searching open- source vulnerability function based on software modularization,

    X. Guo, R. Cai, X. Yin, W. Shao, and S. Liu, “Searching open- source vulnerability function based on software modularization,”Applied Sciences, vol. 13, no. 2, p. 701, 2023

    2023

  7. [15]

    Libdx: A cross-platform and accurate system to detect third-party libraries in binary code,

    W. Tang, P. Luo, J. Fu, and D. Zhang, “Libdx: A cross-platform and accurate system to detect third-party libraries in binary code,” in2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2020, pp. 104–115

    2020

  8. [16]

    Reliable third-party library detection in android and its security applications,

    M. Backes, S. Bugiel, and E. Derr, “Reliable third-party library detection in android and its security applications,” inProceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 356–367

    2016

  9. [17]

    Libd: Scalable and precise third-party library detection in android markets,

    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,” in2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 2017, pp. 335–346

    2017

  10. [18]

    Libradar: Fast and accurate detection of third-party libraries in android apps,

    Z. Ma, H. Wang, Y . Guo, and X. Chen, “Libradar: Fast and accurate detection of third-party libraries in android apps,” inProceedings of the 38th international conference on software engineering companion, 2016, pp. 653–656

    2016

  11. [19]

    Atvhunter: Reliable version detection of third-party libraries for vulnerability identi- fication in android applications,

    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 identi- fication in android applications,” in2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, ...

    2021

  12. [20]

    Automated third-party library detection for android applications: Are we there yet?

    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?” inProceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 919–930

    2020

  13. [21]

    Libid: reliable identification of obfuscated third-party android libraries,

    J. Zhang, A. R. Beresford, and S. A. Kollmann, “Libid: reliable identification of obfuscated third-party android libraries,” inProceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2019, pp. 55–65

    2019

  14. [22]

    Detecting third-party libraries in android applications with high precision and recall,

    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,” in2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2018, pp. ...

    2018

  15. [23]

    Fast algorithm for detecting community structure in networks,

    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

    2004

  16. [24]

    Bingo: Cross-architecture cross-os binary search,

    M. Chandramohan, Y . Xue, Z. Xu, Y . Liu, C. Y . Cho, and H. B. K. Tan, “Bingo: Cross-architecture cross-os binary search,” inProceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2016, pp. 678–689

    2016

  17. [25]

    Asm2vec: Boosting static representation robustness for binary clone search against code obfusca- tion and compiler optimization,

    S. H. Ding, B. C. Fung, and P. Charland, “Asm2vec: Boosting static representation robustness for binary clone search against code obfusca- tion and compiler optimization,” in2019 IEEE Symposium on Security and Privacy (SP). IEEE, 2019, pp. 472–489

    2019

  18. [26]

    1-to-1 or 1-to-n? investigating the effect of function inlining on binary similarity analysis,

    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

    2023

  19. [27]

    Comparing one with many–solving binary2source function matching under function inlining,

    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

    2022 arXiv

  20. [28]

    Cross-inlining binary function similarity detection,

    A. Jia, M. Fan, X. Xu, W. Jin, H. Wang, and T. Liu, “Cross-inlining binary function similarity detection,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–13

    2024

  21. [29]

    Reifunc: Identifying recurring inline functions in binary code,

    W. Lin, Q. Guo, D. Yu, J. Yin, Q. Gong, and X. Gong, “Reifunc: Identifying recurring inline functions in binary code,” in2024 IEEE International Conference on Software Analysis, Evolution and Reengi- neering (SANER). IEEE, 2024, pp. 670–680

    2024

  22. [30]

    Optrans: enhancing binary code similarity detection with function in- lining re-optimization,

    Z. Sha, Y . Lan, C. Zhang, H. Wang, Z. Gao, B. Zhang, and H. Shu, “Optrans: enhancing binary code similarity detection with function in- lining re-optimization,”Empirical Software Engineering, vol. 30, no. 2, p. 49, 2025

    2025

  23. [31]

    Library functions identification in binary code by using graph isomorphism testings,

    J. Qiu, X. Su, and P. Ma, “Library functions identification in binary code by using graph isomorphism testings,” in2015 ieee 22nd international conference on software analysis, evolution, and reengineering (saner). IEEE, 2015, pp. 261–270

    2015

  24. [32]

    Using reduced execution flow graph to identify library functions in binary code,

    ——, “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

    2016

  25. [33]

    Learning to find usages of library functions in optimized binaries,

    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

    2022

  26. [34]

    Bino: Automatic recognition of inline binary functions from template classes,

    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

    2023

  27. [35]

    Fsmell: recognizing inline function in binary code,

    W. Lin, Q. Guo, J. Yin, X. Zuo, R. Wang, and X. Gong, “Fsmell: recognizing inline function in binary code,” inEuropean Symposium on Research in Computer Security. Springer, 2023, pp. 487–506

    2023

  28. [36]

    Highliner: Enhancing binary analysis through nlp-based instruction- level detection of c++ inline functions,

    L. Dall’Aglio, L. Binosi, M. Carminati, S. Zanero, and M. Polino, “Highliner: Enhancing binary analysis through nlp-based instruction- level detection of c++ inline functions,”ACM Trans. Priv. Secur., vol. 28, no. 4, Oct. 2025. [Online]. Available: https://doi.org/10.1145/3765521

    2025 doi

  29. [37]

    A deep dive into function inlining and its security implications for ml-based binary analysis,

    O. Abusabha, J. Uhm, T. Abuhmed, and H. Koo, “A deep dive into function inlining and its security implications for ml-based binary analysis,” inProceedings of the 2026 Network and Distributed System Security Symposium (NDSS), 2026

    2026

  30. [38]

    Towards an oracle for binary decomposition under compilation vari- ance,

    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 vari- ance,”ACM Transactions on Software Engineering and Methodology, 2026

    2026

  31. [39]

    Revisiting binary code similarity analysis using interpretable feature engineering and lessons learned,

    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

    2023

  32. [40]

    SoftSec-KAIST/BinKit: Binary Code Similarity Analysis Benchmark,

    “SoftSec-KAIST/BinKit: Binary Code Similarity Analysis Benchmark,” https://github.com/SoftSec-KAIST/BinKit, 2026, [Online; accessed 9- August-2026]

    2026

  33. [41]

    jtrans: jump-aware transformer for binary code similarity detection,

    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,” inProceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2022. New York, NY , USA: ...

    2022

  34. [42]

    Optimize Options (Using the GNU Compiler Collection (GCC)),

    “Optimize Options (Using the GNU Compiler Collection (GCC)),” https: //gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, 2026, [Online; ac- cessed 9-August-2026]

    2026

  35. [43]

    IDA Pro Disassembler and Debugger - Hex Rays,

    “IDA Pro Disassembler and Debugger - Hex Rays,” https://hex-rays. com/ida-pro, 2026, [Online; accessed 9-August-2026]

    2026

  36. [44]

    capstone on PyPI,

    “capstone on PyPI,” https://pypi.org/project/capstone/, 2026, [Online; accessed 9-August-2026]

    2026

  37. [45]

    readelf(1) — Linux manual page,

    “readelf(1) — Linux manual page,” https://man7.org/linux/man-pages/ man1/readelf.1.html, 2026, [Online; accessed 9-August-2026]

    2026

  38. [46]

    Neural network- based graph embedding for cross-platform binary code similarity detec- tion,

    X. Xu, C. Liu, Q. Feng, H. Yin, L. Song, and D. Song, “Neural network- based graph embedding for cross-platform binary code similarity detec- tion,” inProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 363–376

    2017

  39. [47]

    Sok: All you ever wanted to know about x86/x64 binary disassembly but were afraid to ask,

    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,” in2021 IEEE Symposium on Security and Privacy (SP). IEEE, 2021, pp. 833–851

    2021

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.