PaperlayerView exact revision on arXiv

Source-linked AI summary

Context-Aware Functional Modeling for Android Third-Party Library Detection

Dihao Fan, Jian Zhang, Yasai Shi, Chuan Luo, Xudong Liu, Yang Liu, Chunming Hu, Xu Wang

arXiv:2609.31409v1cs.CRcs.SE

TL;DR

Android TPL detection must handle transformations that alter code and partial library reuse that can undermine whole-library matching. LibFan combines context-aware contrastive method learning with functional partitioning. On R8 full mode, it reports higher library- and version-level F1 than the state of the art.

  • Problem

    Existing TPL detectors rely on hand-crafted features that are fragile under code transformations, while whole-library matching is ill-suited to apps retaining only part of a TPL.

    Source: §I · p. 1, §II · p. 3

  • Method

    LibFan jointly encodes methods with call and class context using contrastive learning, then scores library presence through functional partitioning.

    Source: §I · p. 2

  • Results

    On R8 full mode, LibFan achieves 81.3% library-level F1 and 47.6% version-level F1, relative improvements of 64.9% and 35.6% over the state of the art, respectively.

    Source: §I · p. 2

  • Takeaways & Limitations

    Across evaluated benchmarks, LibFan outperforms baselines at both the library and version levels.

    Source: §VII · p. 11

    Version-level accuracy remains suboptimal because adjacent TPL versions can differ subtly, and compiler optimizations may obscure or eliminate version-specific changes.

    Source: §V · p. 10

Abstract

from arXiv · show

Third-party libraries (TPLs) are widely used in Android apps, but their reuse can introduce security risks and interfere with downstream program analyses. Existing Android TPL detection approaches face two key limitations: their hand-crafted features are fragile under aggressive code transformations, and their whole-library matching strategies are ineffective when apps retain only part of a TPL. In this paper, we propose LibFan, a learning-based Android TPL detection approach based on context-aware functional modeling. It realizes this modeling through two complementary components: context-aware contrastive learning at the method level and functional partitioning at the library level. At the method level, it learns semantic representations through contrastive training while incorporating outgoing call relationships and class-level context, improving robustness to obfuscation, shrinking, and optimization. At the library level, it partitions each TPL into functionally coherent units and determines library presence using the best-matching partition, thereby accommodating partial library reuse. To evaluate LibFan, we construct a new benchmark comprising 200 apps and 46 vulnerable TPLs, with each app compiled under four transformation configurations. Under the most challenging R8 full mode, LibFan achieves F1 scores of 81.3% at the library level and 47.6% at the version level, representing relative improvements of 64.9% and 35.6% over the state of the art, respectively.

I. INTRODUCTION

Android TPL detection must contend with code transformations that alter library code and with apps retaining only part of a library. LibFan combines context-aware method representations with functional partitioning, and its evaluation reports gains over the state of the art under R8 full mode.

I. INTRODUCTION

  • Existing hand-crafted instruction features remain fragile when aggressive compiler optimizations rewrite instructions while preserving functionality.The paper identifies this as a limitation of prior approaches that rely on low-level patterns rather than learned functional representations.Source: §I · p. 1
  • Apps often retain only a subset of TPL functionality, while whole-library matching can let evidence from removed components overwhelm matches to retained code.LibFanBench identifies ground-truth TPLs from compilation artifacts to account for transitive dependencies that build-script declarations can miss.Source: §I · pp. 1–2
  • LibFan learns method representations from source code, outgoing call relationships, and class context using contrastive training on transformed and non-transformed method pairs.This is intended to improve matching robustness to code transformations.Source: §I · p. 2
  • At the library level, LibFan groups methods into functionally coherent partitions and uses the best-matching partition to score TPL presence despite partial reuse.Small partitions are iteratively merged to avoid excessive fragmentation.Source: §I · p. 2
  • 81.3% library-level F1 and 47.6% version-level F1 under R8 full mode represent relative improvements of 64.9% and 35.6% over the state of the art, respectively.The benchmark includes 200 apps, 46 vulnerable TPLs, and four transformation configurations.Source: §I · p. 2

II. MOTIVATION

The motivation identifies two failure modes: isolated opcode matching can misjudge method equivalence, and whole-library scoring can underestimate TPL presence when apps retain only part of a library. These issues motivate context-aware method matching and scoring focused on retained functionality.

II. MOTIVATION

  • 52.6% opcode similarity for an inlined but semantically equivalent method can cause a false negative, while 87.5% similarity for mismatched methods can cause a false positive.The examples show that opcode similarity can fail in both directions under R8 transformations.Source: §II · p. 2
  • LibFan assigns 90.2% to the true match and 35.2% to the semantic mismatch in the two motivating examples.The examples motivate incorporating call relationships and the enclosing class into method representations.Source: Figure 1 · p. 3
  • After shrinking and optimization, an average TPL retains only 34.6% of its classes and 16.7% of its methods, making full-method-set scoring vulnerable to false negatives.Whole-library scoring can dilute correctly matched retained methods because removed methods dominate the denominator.Source: §II · p. 3
  • The two failures motivate modeling contextual method semantics and focusing library scoring on functional portions retained in the app.These are the paper’s two proposed directions for context-aware functional modeling.Source: §II · p. 3

III. APPROACH

LibFan filters candidate app–TPL class pairs, learns context-aware method embeddings, and aggregates matches through functional partitions. Its method model combines call-graph context with a focused representation of the enclosing class.

III. APPROACH

  • LibFan’s workflow filters candidate classes, computes context-aware method similarities, then scores TPL reuse through functional partitions.The pipeline takes an app and candidate TPL as input and determines whether the TPL is reused.Source: §III · p. 3

A. Class-level Candidate Filtering

  • Class-level candidate filtering reuses LibHunter’s signature matching to prune irrelevant app–TPL class pairs before method matching.The obfuscation-resilient signature uses field type descriptors and method prototypes.Source: A. Class-level Candidate Filtering · p. 3

B. Method-level Context-Aware Contrastive Learning

  • The method model jointly encodes a target method and all downstream methods reachable from it in the program call graph.A breadth-first traversal orders these methods so those nearer the target appear earlier in the encoder input.Source: B. Method-level Context-Aware… · p. 4
  • A separate class-context encoder focuses on the target method’s accessed fields rather than encoding the entire enclosing class.The context includes declarations and bodies of methods that access those fields, while unrelated methods are retained only as signatures.Source: B. Method-level Context-Aware… · pp. 4–5

Method Call Encoder.

LibFan combines method and class context through attention, then trains method embeddings to preserve similarity across code transformations. Its training pairs transformed methods with corresponding originals and contrasts them against non-corresponding methods.

Method Call Encoder.

  • The Class Context Encoder produces a feature sequence and valid-token mask for class-level context.The Context Fusion Module uses that context as auxiliary memory while retaining method semantics through a residual connection.Source: Method Call Encoder · p. 5, 3) Context Fusion Module · p. 5

3) Context Fusion Module

  • Cross-attention retrieves relevant class-level cues into the method representation, with a residual connection preserving the method features.The context mask excludes invalid tokens.Source: 3) Context Fusion Module · p. 5

4) Model Training

  • Transformation-aware contrastive training pairs R8 methods with their D8 counterparts to teach embeddings to preserve functional similarity across rewriting.In-batch and queued non-corresponding D8 methods serve as negatives; the InfoNCE objective increases similarity to the positive and reduces similarity to negatives.Source: 4) Model Training · p. 5

C. Functional Partition-based Scoring

LibFan scores TPL presence using the best-matching functional partition rather than whole-library similarity, addressing partial reuse after shrinking and optimization. It forms partitions from reachable call-graph regions and merges small or fragmented units.

C. Functional Partition-based Scoring

  • Best-partition scoring focuses on the most relevant functional unit, addressing missed detections when apps retain only part of a TPL.Whole-library matching can be ill-suited when shrinking and optimization remove large portions of unused library code.Source: C. Functional Partition-based Scoring · p. 5

1) Functional Partitioning for TPL

  • Public entry methods and their reachable call subgraphs approximate reusable functional units, but very small partitions can make scores sensitive to false-positive matches.The method merges small partitions to avoid excessive fragmentation.Source: 1) Functional Partitioning for TPL · pp. 5–6, C. Functional Partition-based Scoring · p. 5
  • The partitioning process groups overloaded methods, collapses call-graph strongly connected components into a DAG, then uses reachable method sets from zero-in-degree nodes as initial partitions.The SCC collapse handles cycles that otherwise leave no zero-in-degree method.Source: 1) Functional Partitioning for TPL · p. 6
  • Small partitions are iteratively merged with the most similar alternative, using Jaccard similarity and class- and package-set similarity to break ties.If those comparisons do not establish a preference, the second-smallest partition is selected; merging continues until the size threshold is met or one partition remains.Source: 1) Functional Partitioning for TPL · p. 6

2) TPL and version scoring

LibFan filters candidate method pairs by embedding similarity, selects class matches by confidence, and scores library presence using the strongest functional partition. Version selection instead uses global similarity across all TPL methods.

2) TPL and version scoring

  • Method pairs below the cosine-similarity threshold are discarded before class-pair confidence is computed.The confidence calculation uses the number of opcode instructions in each compiled TPL method.Source: 2) TPL and version scoring · p. 6
  • For each candidate class pair, confidence is computed from surviving matched methods, and LibFan retains each TPL class’s highest-confidence app-class match.The preserved matches are unioned across the TPL’s classes.Source: 2) TPL and version scoring · p. 6
  • Library-level similarity is the maximum matched-method ratio across the TPL’s functional partitions.This lets one well-matched partition determine library-level presence.Source: 2) TPL and version scoring · p. 6
  • Version scoring reverts to global similarity over all TPL methods, and the highest-scoring version is selected once library presence exceeds its threshold.The paper notes that version differences may not correlate with the most similar partition.Source: 2) TPL and version scoring · p. 6

IV. EVALUATION

The evaluation is organized around effectiveness and runtime, component ablations, partition-size sensitivity, and generalizability. Its research questions ask how LibFan performs against existing tools and under different evaluation conditions.

IV. EVALUATION

  • RQ1 evaluates LibFan’s effectiveness against state-of-the-art Android TPL detection tools and its runtime practicality.Source: §IV · p. 6
  • RQ2 examines how LibFan’s components and pretrained representation model affect final performance.Source: §IV · p. 6
  • RQ3 tests whether functional partitioning performance is sensitive to the minimum partition size Np.Source: §IV · p. 6
  • RQ4 investigates performance on unseen TPLs and in-the-wild apps.Source: §IV · p. 6

1) Baselines

LibFan is evaluated against three Android TPL detection baselines using LibFanBench, with results reported at library and version levels across increasingly strong transformations. It performs best across app variants, especially under R8 full mode, while maintaining practical online runtime.

1) Baselines

  • The evaluated baselines are LibHunter, LibScan, and LibPecker; other tools are excluded because they were not designed for complex R8 transformations.Prior work cited by the authors reported limited effectiveness for those excluded tools under such conditions.Source: 1) Baselines · pp. 6–7

2) Dataset

  • LibFanBench contains 200 Android apps and 46 vulnerable TPL artifacts, compiled under four configurations from D8 without transformation to R8 full mode.Its ground truth accounts for transitive dependencies and removes dependencies eliminated by R8 shrinking or optimization.Source: 2) Dataset · p. 7

3) Metrics

  • Library-level false positives and false negatives are based on unused and missed TPLs, while version-level evaluation inherits library errors and also penalizes incorrect versions.The study reports precision, recall, and F1 at both levels.Source: 3) Metrics · p. 7

B. Implementation

  • The implementation decompiles bytecode with JADX, extracts features and builds call graphs and partitions with Androguard, and reuses LibHunter’s class-matching module.The training, validation, and test split is by app at 10%, 10%, and 80%, respectively; hyperparameters are tuned on the validation set.Source: B. Implementation · p. 7

C. Effectiveness and Efficiency (RQ1)

  • Under Opt+Obf+Srk, LibFan achieves 81.3% library-level and 47.6% version-level F1, exceeding the best baseline by 32.0 and 12.5 percentage points, respectively.LibFan achieves the best detection effectiveness across all app variants, especially under aggressive R8 transformations.Source: Table I · p. 7, C. Effectiveness and Efficiency (RQ1) · p. 8
  • LibFan requires 2.193s per pair on D8 and 0.644s per pair on Opt+Obf+Srk, with runtime comparable to LibHunter.TPL-side embeddings and partitions are cached, and app-side embeddings are computed once and reused across parallel matching tasks.Source: C. Effectiveness and Efficiency (RQ1) · p. 8

D. Ablation Study (RQ2)

The ablation study finds that both context-aware contrastive learning and functional partitioning contribute to LibFan’s performance under R8 transformations. Improvements also hold across the tested pretrained backbones.

D. Ablation Study (RQ2)

  • Fine-tuning improves performance over off-the-shelf UniXcoder, while call relationships and class context further improve library- and version-level F1.Disabling functional partitioning causes clear performance drops across all R8 variants.Source: D. Ablation Study (RQ2) · pp. 8–9, Table II · p. 8
  • UniXcoder and Jina-v2 obtain comparable results, while CodeBERT is slightly weaker after contextual semantics and contrastive fine-tuning are incorporated.Pretrained encoders alone are insufficient under R8 transformations, especially for version-level detection under Opt+Obf+Srk.Source: D. Ablation Study (RQ2) · p. 9
  • Both context-aware contrastive learning and functional partitioning improve LibFan, with gains across pretrained backbones indicating the improvements are not specific to one base model.The study focuses on the three R8-transformed variants because all tools perform well on D8.Source: D. Ablation Study (RQ2) · pp. 8–9

E. Sensitivity (RQ3)

LibFan’s F1 remains stable across a broad range of functional partition thresholds, but very small and very large partitions reduce performance for different reasons.

E. Sensitivity (RQ3)

  • Across R8 variants, LibFan remains stable for Np values from 200 to 900; on Opt+Obf+Srk, best library-level and version-level F1 occur at Np = 400 and Np = 600, respectively.Figure 4 compares sensitivity across the three R8 variants; ∞ denotes disabling functional partitioning.Source: E. Sensitivity (RQ3) · p. 9, Figure 4 · p. 9
  • Np = 100 can amplify method-level false positives through a small partition denominator, while Np = 1000 reduces partitioning’s benefit and approaches the nonpartitioned setting.Moderate partition sizes avoid both effects.Source: E. Sensitivity (RQ3) · p. 9

F. Generalizability (RQ4)

LibFan generalizes to held-out TPL artifacts and outperforms LibHunter on the TPL-disjoint test set. On unseen Google Play apps, it also surfaces potential security-relevant dependency signals at scale.

F. Generalizability (RQ4)

  • The TPL-disjoint split retains TPLs appearing 5–50 times, yielding a test set of 61 apps and 83 app–TPL pairs across 10 held-out artifacts.The training and validation sets share nine seen TPL artifacts; RQ1 hyperparameters are unchanged.Source: F. Generalizability (RQ4) · p. 9
  • 78.3%/53.8% library-level/version-level F1 under Opt+Obf+Srk beats LibHunter by 22.8/11.1 percentage points; LibFan also leads across all three R8 settings.The test TPL artifacts were held out from fine-tuning and checkpoint selection.Source: Table III · p. 9, F. Generalizability (RQ4) · pp. 9–10
  • Across 1,081 Google Play apps, LibFan reports 9,102 app–TPL pairs, including 3,478 CVE-associated version reports, or 38.2% of its reports.LibHunter reports 4,460 pairs, of which 1,392, or 31.2%, are CVE-associated version reports.Source: F. Generalizability (RQ4) · p. 10
  • LibFan's CVE-associated reports include transitive TPLs such as protobuf-java, okio, gson, and guava, surfacing potential warnings for downstream dependency-risk analysis.The authors describe this in-the-wild evaluation as evidence of practical applicability beyond curated benchmarks.Source: F. Generalizability (RQ4) · p. 10

V. DISCUSSION

The discussion identifies version-level detection and evaluation scope as limitations, reviews related detection and code-similarity work, and concludes that LibFan outperforms baselines across evaluated benchmarks.

V. DISCUSSION

  • Version-level accuracy remains suboptimal because adjacent versions differ subtly and compiler optimizations may obscure or remove version-specific changes.The authors propose identifying TPL presence first, then locating transformation-stable code that distinguishes adjacent versions.Source: §V · p. 10
  • Androguard may yield incomplete call graphs, while JADX decompilation may be imperfect under aggressive transformations; shared tool limitations mitigate comparative bias.The call-graph limitations include handling of polymorphism, reflection, and multithreading.Source: §V · p. 10
  • The evaluation uses 200 primarily F-Droid apps, whose distribution may differ from commercial markets with proprietary development, closed-source libraries, and additional protections.Accurate ground truth for TPL usage in those settings remains an open challenge.Source: §V · p. 10

VI. RELATED WORK

  • Android TPL detectors still have limited support for high-level semantics and partial reuse, while C/C++-oriented binary-similarity approaches lack adaptation to Android-specific contexts.The related-work discussion covers Android detection tools and learning-based binary similarity methods.Source: §VI · p. 10

VII. CONCLUSION

  • LibFan combines context-aware contrastive learning with functional partitioning and outperforms baselines at library and version levels across evaluated benchmarks.The implementation, dataset, and trained models are reported as available online.Source: §VII · p. 11

Related papers

Loading 2609.31409v1…