PaperlayerView exact revision on arXiv

Source-linked AI summary

Long-Range Indirect Control-Flow Prediction in Stripped Binaries via Dual Virtual Hubs and Multi-Task Graph Learning

Kun Liu, Zhengming Ding, Chenke Luo, Tianyi Xu, Zizhan Zheng, Haotian Zhang, Jiang Ming

arXiv:2609.03280v2cs.CR

TL;DR

Indirect control-flow recovery in stripped binaries is difficult because long-range evidence, fragmented ICF tasks, noisy labels, and data leakage complicate prediction and evaluation. ICFlowNet combines candidate-aware Dual Virtual Hubs with multi-task graph learning and a leakage-aware evaluation pipeline. It reports gains on long-range indirect calls and improvements from both structural and multi-task designs.

  • Problem

    Existing methods struggle with long-range dependencies and fragmented ICF tasks, while label noise and data leakage complicate credible evaluation of stripped-binary predictions.

    Source: §1 · p. 2

  • Method

    ICFlowNet uses candidate-aware Global Code and Data Hubs with multi-task graph learning to predict indirect calls, tail calls, jump tables, and returns.

    Source: §1 · p. 2

  • Results

    The final model outperforms prior baselines by more than 13 F1 on long-range indirect calls, with robust cross-dataset generalization reported across static and dynamic settings.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Simply scaling static supervision offers limited benefit, while structural repair and cross-type transfer are important to the reported gains.

    Source: §1 · p. 2

    ICFlowNet is not a drop-in substitute for methods requiring a hard 100% recall guarantee, where even a small number of missed legitimate targets may be unacceptable.

    Source: §6 · p. 13

Abstract

from arXiv · show

Recovering indirect control-flow (ICF) edges is fundamental to binary security analysis, yet existing methods struggle with long-range dependencies, isolate different ICF types, and are often evaluated under protocols vulnerable to label noise and data leakage. We present ICFlowNet, a unified framework for long-range ICF prediction in stripped binaries. ICFlowNet introduces candidate-aware Dual Virtual Hubs, a Global Code Hub and a Global Data Hub, to create short routing paths between distant code and data evidence, and combines them with multi-task graph learning to jointly model indirect calls, indirect tail calls, jump tables, and returns. To enable credible evaluation, we further develop a leakage-aware, noise-controlled pipeline with package-level splits, function-level mnemonic-hash deduplication, and a clean test protocol built from dynamic positives and absolute negatives. Using this pipeline, we construct a dataset of 15,901 unique stripped x86-64 binaries, including 1,351 with dynamic ground truth. Experiments show that simply scaling static supervision yields only marginal gains, whereas our structural and multi-task designs are essential: Dual Virtual Hubs improve long-range F1 by up to 9.13 points, multi-task learning adds up to 5.81 points, and the final model outperforms prior baselines by more than 13 F1 points on long-range indirect calls while adding only 11.44 percent topological overhead.

1 Introduction

The introduction frames indirect control-flow recovery in stripped binaries as difficult because runtime targets must be inferred without much source-level semantic information, while existing methods address only parts of the problem. ICFlowNet combines candidate-aware Dual Virtual Hubs, multi-task graph learning, and a leakage-aware, noise-controlled evaluation pipeline.

1 Introduction

  • In stripped binaries, missing source-level cues leave analysts inferring dynamic targets from low-level patterns, and unresolved ICF edges weaken downstream binary analysis and defenses.The introduction identifies binary rewriting, recompilation, software hardening, and binary diffing as affected applications.Source: §1 · p. 1
  • Existing learning-based methods focus on individual ICF tasks, while graph models can struggle with distant evidence and incomplete code-data cross-references.The introduction also notes that prior evaluation protocols do not enforce the package-level isolation and deduplication used here.Source: §1 · p. 2
  • Prior datasets rely on single-source labels and can suffer from label errors and data leakage; re-evaluating Callee with package separation and function deduplication lowers its F1 from 94.6% to 90.92%.The authors argue that verified positives and absolute negatives are needed for a clean test protocol.Source: §1 · p. 2
  • ICFlowNet routes candidate code through a Global Code Hub and nearby data evidence through a sparsified Global Data Hub, then jointly predicts calls, tail calls, jump tables, and returns.Its multi-task design shares structural knowledge while retaining task-specific decision boundaries.Source: §1 · p. 2
  • The final model outperforms prior baselines by more than 13 F1 on long-range indirect calls; Dual Virtual Hubs improve long-range F1 by up to 9.13 points and multi-task learning adds up to 5.81 points.Evaluation uses package-level splits, function-level mnemonic-hash deduplication, and verified dynamic positives with absolute negatives across 15,901 unique stripped x86-64 binaries, including 1,351 with dynamic ground truth.Source: §1 · p. 2
  • The paper presents a unified framework, a larger dataset and stricter evaluation protocol, and gains on long-range and structurally complex inter-procedural ICF edges.The authors report that scaling static supervision alone offers limited benefit, while structural repair and cross-type transfer are important.Source: §1 · p. 2

2 Background and Related Work

The background distinguishes ICF subtypes and reviews traditional, learning-based, and graph-learning approaches. It motivates graph representations while identifying limits in coverage, long-range reasoning, and the treatment of code-data relations.

2.1 Indirect Control Flow (ICF) Categorization

  • Indirect jumps are divided into jump tables, indirect tail calls, and returns, while indirect calls form one category because their instruction form and semantics are consistent.The paper uses this categorization to distinguish subtype-specific behaviors and avoid majority-class bias.Source: §2.1 · p. 3

2.2 Traditional ICF Resolution Techniques

  • Traditional jump-table tools face limits from binary-lifting fidelity, older compiler patterns, control-flow merge points, and incomplete heap or global-memory modeling.The review notes that no prior work had explicitly addressed binary-level indirect tail-call resolution.Source: §2.2 · p. 3
  • Indirect-call tools trade among inferred type compatibility, memory abstractions, boundary recovery, and runtime execution, while explicit code-data cross-references remain underused for target prediction.The reviewed systems include signature-based and pointer-analysis methods, boundary-recovery support, and scheduled runtime execution.Source: §2.2 · p. 3

2.3 The Rise of ML-based Single-Task Models

  • Sequence-based methods Callee and AttnCall focus on indirect calls, while graph-based CupidCall [30] uses heterogeneous graphs but remains constrained by local message passing and multi-hop decay.The review says these approaches do not provide unified modeling across multiple ICF types.Source: §2.3 · pp. 3–4

2.4 Graph Representation Learning for Binaries

  • Heterogeneous graph attention can distinguish code and data semantics, but standard message passing has limited reach and binary graphs are sparse, heterogeneous, and incompletely recovered.These properties motivate binary-specific long-range remedies rather than direct application of general graph transformers or virtual-node connections.Source: §2.4 · p. 4

3 Motivation and Overview

ICFlowNet formulates ICF prediction as task-aware edge classification on an augmented graph recovered from a stripped binary. Its workflow uses dual hubs for sparse long-range communication and multi-task learning to share structural patterns while retaining task-specific decisions.

3 Motivation and Overview

  • For each of four ICF types, the model scores task-specific candidate basic-block pairs to predict whether an edge of that type exists.The formulation reflects that ICF types share structural regularities but have different source and destination spaces and inductive biases.Source: §3 · p. 4

3.1 Key Insight 1: Dual Virtual Hubs

  • Candidate-aware Dual Virtual Hubs create short cross-domain routes between distant code and data evidence when relevant evidence is several hops away or xRef chains are incomplete.The Global Code Hub routes among task-relevant code candidates; the Global Data Hub aggregates associated data evidence rather than the entire program.Source: §3.1 · p. 4

3.2 Key Insight 2: Multi-Task Learning

  • Multi-task learning shares reusable structural patterns across ICF types while separate prediction heads preserve task-specific decision boundaries.The paper describes abundant return examples as helping regularize and guide learning for rarer indirect tail calls.Source: §3.2 · p. 4

3.3 ICFlowNet Workflow

  • Only Stage I of the workflow is offline supervision collection; inference constructs an augmented CFG, encodes it with HGAT, and scores candidate pairs with task-aware heads.Static and dynamic labels are supervision and evaluation signals, not runtime inputs.Source: §3.3 · pp. 4–5

4 System Design

System design proceeds through supervision collection, augmented CFG construction, heterogeneous graph encoding, and task-aware multi-task learning.

4 System Design

  • The system design comprises offline supervision collection, augmented CFG construction, heterogeneous graph encoding, and task-aware multi-task learning.Source: §4 · p. 5

4.1 Clean Evaluation and Source Separation

  • The clean protocol treats dynamic targets as positives and samples equal negatives outside static candidates; static- and dynamic-supervised models share this test set.Static labels are collected through compiler instrumentation and annotations, jump-table instruction-selection interception, and reconstructed return pairs; dynamic pairs come from Pin traces. The protocol samples negatives outside the static candidate set and uses static labels as ground truth for jump tables.Source: §4.1 · pp. 5–6

4.2 Augmented CFG Construction

  • Candidate-aware GCH and sparsified GDH create short code/data routes while restricting links to task candidates and a two-hop xref neighborhood.Because candidate sets must be available at inference, unresolved indirect-jump sources are routed generically to the GCH; hub nodes use learnable type embeddings.Source: §4.2 · p. 6

4.3 Heterogeneous Graph Attention Networks

  • HGAT preserves relation semantics, while gated fusion injects hub context and task-specific MLPs score candidate edges.The encoder distinguishes control-flow from code-data xRef relations; relation-specific attention and candidate-aware connectivity help constrain hub-side information flow.Source: §4.3 · pp. 6–7

4.4 Multi-Task Heterogeneous GATs

  • A shared heterogeneous encoder feeds four task-specific GATs and classifiers, with task-isolated labels and an optional positive-pair-only type-classification head.Ambiguous indirect jumps route to the GCH, while jump-table targets are excluded so the jump-table head relies on local ACFG topology.Source: §4.4 · pp. 7–8

5 Evaluation

The evaluation tests ICFlowNet’s ICF prediction across four edge types, supervision regimes, structural difficulty, prior baselines, and computational cost. It pairs dataset construction with controls for label noise and data leakage.

5 Evaluation

  • The evaluation measures ICFlowNet’s core capability—recovering high-fidelity edges across all major ICF types—and compares supervision source, structural difficulty, training paradigm, prior methods, and efficiency.The study focuses on this predictive layer rather than downstream applications, whose additional components could confound attribution of gains.Source: §5 · p. 8

5.1 Training Dataset Construction

  • The corpus contains 15,901 unique stripped binaries, including 1,351 with dynamic ground truth, and supplies supervision for all four ICF types.It addresses fragmented earlier datasets that covered only jump tables or indirect calls; indirect tail calls are much rarer than indirect calls and returns.Source: §5.1 · pp. 8–9, Table 3 · p. 8

5.2 Experimental Setup

  • Package-level splits, function-level mnemonic-hash deduplication, and a clean test protocol control leakage and label noise; long-range pairs are over four hops apart or disconnected in the base graph.Training tolerates some label noise, but inter-procedural evaluation uses verified dynamic positives and negatives outside the static candidate set; deduplication removes 1.18%–15.32% of overlapping test instances.Source: §5.2 · p. 9

5.3 RQ1: Single-task performance with Dual Hubs

  • A 10× increase in static training data yields only marginal gains, while dynamic supervision has higher precision but lower recall than static supervision on inter-procedural edges.Dynamic supervision also performs significantly worse on jump tables because traces often miss dispatch targets; static supervision’s broader labels raise recall and F1 despite more false positives.Source: §5.3 · pp. 9–10, Figure 4 · p. 10

5.4 RQ2: Long Range ICF Pairs Analysis

  • On long-range inter-procedural edges, adding the Global Code Hub improves F1 by 4.32 for indirect calls, 6.30 for indirect tail calls, and 4.60 for returns; adding the Global Data Hub raises total gains to 6.04, 9.13, and 5.04, respectively.Jump tables instead score 97.51% F1 without hubs; GCH and GCH + GDH reduce F1 by 1.23 and 2.14, so the selected architecture keeps jump-table prediction local.Source: Table 4 · p. 10, §5.4 · pp. 10–11

5.5 RQ3: Multi-Task Model (MTL) Performance

  • On the long-range subset, multi-task learning adds 4.16 F1 for indirect calls, 5.81 for indirect tail calls, and 5.43 for returns; it also improves overall F1 over single-task models for all four types.Jump-table gains are smaller; MTL_t adds 0.44 F1 on the long-range subset, while MTL is treated as the most stable overall predictive model. Without Dual Hubs, the average MTL gain falls to 1.33%.Source: Table 5 · p. 11, Table 6 · p. 11, §5.5 · p. 11

5.6 RQ4: Comparative Evaluation

  • On long-range indirect calls, ICFlowNet MTL reaches 95.51% F1 versus 82.26% for Callee and 82.48% for CupidCall; on jump tables, it reaches 97.53% versus SJA’s 93.86%.On the Overall set, MTL reaches 96.18% F1 for indirect calls versus 88.37% for Callee and 90.18% for CupidCall; jump-table F1 is 98.48% versus SJA’s 94.83%. Direct baseline comparisons focus on indirect calls and jump tables because prior studies do not cover returns and tail calls.Source: Table 7 · p. 11, §5.6 · pp. 11–12

5.7 RQ5: Efficiency and Scalability

  • Candidate-aware hubs add 4.98% edge overhead for indirect calls, 6.09% for returns, and 5.65% for indirect tail calls, with total overhead of 11.44% in the unified MTL graph.Against four independent single-task models, MTL reduces training time from 9.19 s to 4.08 s per graph and inference latency from 3.79 s to 1.57 s.Source: Table 8 · p. 12, §5.7 · p. 12

6 Discussion and Conclusion

ICFlowNet combines structural repair and cross-type learning for long-range ICF recovery, while its discussion emphasizes scalability trade-offs, deployment boundaries, and responsible use.

6 Discussion and Conclusion

  • ICFlowNet’s conclusion identifies structural repair and cross-type transfer as important for accurate long-range ICF recovery, while dual hubs balance shorter routes against structural sparsity.Memory remains a practical concern for very large binaries, and the framework is presented as complementary—not a replacement for analyses requiring guaranteed completeness.Source: §6 · pp. 12–13

A Open Science

  • The artifact provides code for graph construction, training, and evaluation, plus a separate package of binaries, metadata, and model resources.The code is available on GitHub.Source: A Open Science · p. 14

B Ethical Considerations

  • The authors identify dual-use potential, while noting that their work introduces no exploit or vulnerability trigger and uses public binaries in offline research.They state that dynamic tracing is used for ground-truth construction and evaluation, not to alter deployed software behavior.Source: B Ethical Considerations · pp. 14–15

C Indirect Control Flow Categorization

  • The paper treats jump tables, indirect tail calls, and returns as separate edge types, but groups indirect calls because their assembly patterns overlap and graph data context supports nuanced resolution.The jump subtypes differ in structural behavior and frequency; combining them could bias predictions toward more common returns.Source: C Indirect Control Flow Categorization · p. 15

D Static ICF Pairs Collection

  • Static ICF pairs are collected through compiler annotations and parsing, with jump-table targets recorded during instruction selection and call candidates restricted using propagated callee types.Return edges are reconstructed from call history, including for indirect tail calls whose callees do not return to the immediate caller.Source: D Static ICF Pairs Collection · p. 15

E Detailed Dataset Construction Pipeline

The dataset pipeline compiles a large Arch Linux corpus, filters and annotates binaries, and augments native tests for selected complex applications.

E Detailed Dataset Construction Pipeline

  • The corpus contains 12,972 unique C/C++ projects from Arch Linux core, extra, and a curated AUR subset, with approximately 77% successfully compiled.Projects were built from source using an LLVM-based toolchain and Arch’s makepkg and PKGBUILD infrastructure.Source: E Detailed Dataset Construction Pipeline · p. 15
  • After normalized-binary-hash deduplication, the pipeline retains binaries with at least one static ICF pair and obtains dynamic ground truth for 1,351 binaries with native check() functions.Static pairs are extracted using a custom instruction-labeling parser; dynamic tracing supplies execution-grounded annotations.Source: E Detailed Dataset Construction Pipeline · pp. 15–16
  • For 20 ubiquitous medium-sized projects, LLM-generated supplementary tests increased unique dynamically observed ICF pairs by approximately 25% over native tests alone.The augmentation addressed sparse ICF coverage in native tests for selected complex applications.Source: E Detailed Dataset Construction Pipeline · p. 16

F Package-Level Stratified Data Splitting

The split procedure assigns whole packages to partitions and balances ICF-type coverage through rarity-aware multi-label sampling.

F Package-Level Stratified Data Splitting

  • Packages, rather than individual binaries or graphs, are the split unit because binaries from one package may share templates, compiler options, and dependencies.This helps prevent cross-split information leakage.Source: F Package-Level Stratified Data… · p. 16
  • The rarity-aware procedure processes edge types from rarest to most common and targets approximately 80% training, 10% validation, and 10% testing per type.It prioritizes test, then validation, then training assignments to provide positive coverage for scarce labels.Source: F Package-Level Stratified Data… · p. 16
  • Greedy package assignment accounts for co-occurring labels, and the same package-level split is reused for single-task and multi-task experiments.This preserves package isolation while supporting balanced per-type coverage and consistent comparisons across experiment settings.Source: F Package-Level Stratified Data… · p. 16

G Function-Level Deduplication for Leakage-Free Evaluation

Function-level mnemonic-hash deduplication addresses structural overlap across splits; the appendix also describes shared test conditions and single-task tuning.

G Function-Level Deduplication for Leakage-Free Evaluation

  • Approximately 15.9% of ground-truth-labeled functions overlapped between Callee’s training and test sets, and CupidCall showed 13.6% overlap.The paper argues that duplicated labeled functions can let models memorize behaviors and artificially inflate evaluation metrics.Source: G Function-Level Deduplication for… · p. 16
  • The deduplication procedure hashes each labeled function’s control-flow-ordered instruction mnemonics and excludes an edge when its function fingerprint matches one in training.Hashing is performed independently for each edge type to prevent structurally equivalent test labels within the GAT message-passing radius.Source: G Function-Level Deduplication for… · p. 16

H Hyperparameter Tuning

  • Single-task models use a near-optimized configuration of 256 hidden units, four GAT layers, eight attention heads, dropout 0.4, weight decay 10^-5, and learning rate 0.001.Training uses validation F1 for Optuna search, early stopping, Adam, and a fixed prediction threshold of 0.5.Source: H Hyperparameter Tuning · p. 16
  • Table A2 compares dynamic, static, and large-scale-static supervision across ICF types, with each block evaluated on the same clean test set.The supplied caption and note identify the comparison scope but do not provide performance values.Source: Table A2 · p. 17, H Hyperparameter Tuning · p. 17

I MTL Optimization Robustness

ICFlowNet remains accurate across compiler optimization levels, while a 2-hop Global Data Hub neighborhood best balances useful data context against irrelevant structure.

I MTL Optimization Robustness

  • Across O0–O3, the MTL model maintains F1 scores above 93% on Long-range and Overall test datasets.The optimization-specific test sets are generated by recompiling the same source programs; no indirect tail-call rows appear for O0/O1 because those subsets contain no tail-call-eliminated instances.Source: I MTL Optimization Robustness · p. 17
  • At O3, jumptable F1 remains near 97%–98%, while icall shows slight sensitivity to higher optimization levels.The authors report that overall performance remains stable despite the increased difficulty introduced by O2 and O3 transformations.Source: I MTL Optimization Robustness · p. 17

J GDH Pruning

  • A 2-hop GDH radius yields the highest F1 scores, balancing insufficient 1-hop context against noise from irrelevant 3-hop data nodes.The study adopts the 2-hop threshold for all GDH configurations.Source: J GDH Pruning · p. 17, Table A3 · p. 17

K MTL Performance Without Dual Hubs

Without Dual Hubs, the reported average F1 improvement is marginal; the associated comparison evaluates Single-Task and MultiTask models without hub routing.

K MTL Performance Without Dual Hubs

  • Table A4 compares Single-Task and MultiTask paradigms in a foundational setting without GCH or GDH routing.The table caption identifies the comparison as a no-Dual-Hub evaluation.Source: Table A4 · p. 17, K MTL Performance Without Dual Hubs · p. 17
  • Without Dual Hubs, the model achieves only a 1.33% average F1 improvement.The passage attributes the plateau to multi-hop information decay and over-squashing in standard local message passing.Source: K MTL Performance Without Dual Hubs · p. 17, Table A4 · p. 17
  • The optimization-specific test sets cover O0–O3, with no indirect tail-call rows for O0/O1 because those subsets contain no tail-call-eliminated instances.Tables A5 and A6 describe Long-range and Overall test sets generated by recompiling the same source programs.Source: Table A5 · p. 18, Table A6 · p. 18

L Feature Level Fusion vs. MTL

Simple feature fusion provides inconsistent task-level gains, whereas jointly optimized MTL_t improves over the single-task baseline on every task type.

L Feature Level Fusion vs. MTL

  • MTL_t gains +4.48, +5.13, +0.44, and +4.91 F1 on ic, itc, jt, and ret, respectively, versus the single-task baseline.Table A7 reports the comparison on the Long-range test dataset with models trained on the large-scale static dataset.Source: L Feature Level Fusion vs. MTL · p. 18, Table A7 · p. 18
  • Feat-fusion changes F1 by +1.37 on ic, −1.57 on itc, −0.62 on jt, and +4.61 on ret, with gains limited and inconsistent.The passage notes the larger return-task gain may relate to its greater number of supervision pairs, but this advantage does not generalize to lower-resource tasks.Source: L Feature Level Fusion vs. MTL · p. 18
  • Feat-fusion averages only +0.95 F1 over Single-Task, compared with +3.74 for MTL_t.The authors describe shallow fusion as unreliable overall and report that MTL_t improves across all task types.Source: L Feature Level Fusion vs. MTL · p. 18

M External Comparison

External comparisons use each prior system’s published benchmark conventions rather than strict artifact-level reproductions. ICFlowNet reports stronger precision on complex BinDSA cases and smaller candidate sets with similar recall against BPADisa, alongside lower stated inference time on gcc.

M External Comparison

  • These external results are cross-framework reference points, not strict artifact-level reproductions, because the systems use different published benchmark conventions and metrics.BinDSA reports profiling-based precision/recall, whereas Disa’s BPADisa pipeline uses AICT and recall across optimization levels.Source: M External Comparison · pp. 18–19
  • On 403.gcc, ICFlowNet reports precision/recall of 0.90/0.97, versus BinDSA’s 0.46/0.67.On simpler 401.bzip2 and 433.milc, both systems are described as essentially perfect; the larger-binary comparison uses BinDSA’s profiling-based convention.Source: M External Comparison · p. 19, Table A8 · p. 19
  • On perlbench-03, ICFlowNet reduces AICT from 456.4 to 364.3 while maintaining nearly identical recall against BPADisa.The passage also reports reductions from 454.1 to 392.9 on gcc-03 and from 1416.2 to 1272.7 on gobmk-03.Source: M External Comparison · p. 19, Table A9 · p. 19
  • On gcc, ICFlowNet’s end-to-end inference takes about 25 seconds, compared with 1,865 seconds for BinDSA and 27,619 seconds for BPA.The passage describes ICFlowNet deployment as a single feed-forward pass after offline model fitting; the prior systems’ runtime grows from minutes to hours on large binaries.Source: M External Comparison · p. 19

Related papers

Loading 2609.03280v2…