ATVHunter: Reliable Version Detection of Third-Party Libraries for Vulnerability Identification in Android Applications

I. INTRODUCTION

• Existing tools can miss niche or new libraries, rely on mutable package structures, and often fail to identify precise TPL versions without false positives.The paper also notes that clustering results can be difficult to verify and published reference databases are much smaller than the TPL market.Source: §I · pp. 1–2
• ATVHunter separates in-app library candidates using class dependencies, then uses CFGs to locate potential TPLs and basic-block opcodes to identify precise versions.Fuzzy hashing is used to alleviate obfuscation effects, and the system does not depend on package structure.Source: §I · p. 2
• With an industry collaborator, ATVHunter was integrated into an online service to help users identify vulnerable Android TPLs.The service is described as a branch of an existing online service.Source: §I · p. 2
• 189,545 TPLs and 3,006,676 versions populate the feature database; the vulnerable-version database includes 1,180 CVEs and 224 security bugs.The CVEs cover 957 TPLs and 38,243 vulnerable versions; the security bugs cover 152 open-source TPLs and 4,533 affected versions.Source: §I · p. 2
• 90.55% precision and 88.79% recall are reported for version-level identification, alongside resilience to widely used obfuscation techniques.The comparison is against state-of-the-art TPL-version detection tools.Source: §I · p. 2
• 9,050 apps contain 10,616 vulnerable TPLs, with 53,337 known vulnerabilities and 7,480 security bugs; most vulnerable TPLs have severe vulnerabilities.The reported large-scale study covers 73,110 apps using TPLs.Source: §I · p. 2

II. RELATED WORK

• Clustering approaches can require many apps, miss niche or complete libraries, introduce impurities, and depend on package structures that obfuscation can alter.Similarity-based methods also face constraints: LibScout’s feature can be too coarse, LibPecker’s comparison is time-consuming, and LibID’s reverse-engineering capability is limited by dex2jar.Source: §II · pp. 2–3
• Prior vulnerable-TPL studies have used small datasets or resource-intensive version features, limiting their coverage or efficiency.Yasumatsu et al. studied vulnerable versions of seven TPLs; OSSPolice uses function centroids, which the paper describes as resource-intensive to generate.Source: §II · p. 3

III. ARCHITECTURE

• ATVHunter has two components: TPL-version detection and vulnerable-version identification based on vulnerabilities collected from NVD and GitHub.The system takes an Android app as input and identifies used vulnerable TPL versions, if any.Source: §III · p. 3
• The authors use the constructed database to study vulnerable-TPL usage across the Android-app ecosystem.The architecture passage introduces the large-scale study, with details to follow.Source: §III · p. 3

A. TPL Detection

• The TPL-detection pipeline has four phases: preprocessing, module decoupling, feature generation, and TPL identification.Preprocessing decompiles the app into intermediate representations and removes the host app’s primary module to reduce interference.Source: A. TPL Detection · p. 3, 1) Preprocessing · p. 3

1) Preprocessing:

• Preprocessing identifies host-app packages and removes their code, but package flattening, special names, or shared namespaces can leave host code or cause TPL false negatives.Undeleted host code does not affect accuracy when it has no dependencies; remaining interference can be addressed during comparison.Source: 1) Preprocessing · p. 3

2) Module Decoupling:

• Class Dependency Graphs split non-primary app code into library candidates without relying on package structure, helping with package flattening and shared roots.The graph uses class inheritance, method calls, and field references; the authors report that 47.3% of Maven Android TPLs depend on others.Source: 2) Module Decoupling · pp. 3–4
• For skinny Maven jars, ATVHunter uses pom.xml metadata to record dependencies and separates dependency TPLs by package namespace for matching.A jar marked “jar-with-dependencies” includes dependencies; otherwise, the jar contains only the host TPL code.Source: 2) Module Decoupling · p. 4

3) Feature Generation:

• CFG signatures provide a coarse feature for quickly locating potential TPLs, while opcode sequences within CFG basic blocks provide finer version-level features.The paper motivates fine-grained features because CFGs can yield identical signatures for versions with small basic-block changes.Source: 3) Feature Generation · p. 4
• ATVHunter applies fuzzy hashing to method-level opcode sequences, using rolling-hash pieces so localized obfuscation changes do not dramatically alter the fingerprint.Operands are excluded because identifiers and hardcoded URLs are vulnerable to renaming and string-encryption techniques; fingerprints for all methods represent a TPL version.Source: 3) Feature Generation · p. 5
• 189,545 unique TPLs and 3,006,676 versions from Maven populate the feature database, which stores coarse- and fine-grained features.The database is 300 GB; collection took over a month and feature generation another two months.Source: 3) Feature Generation · p. 5

4) Library Identification:

• Potential-TPL search uses package names as supplementary filtering, class-count differences, and coarse-feature similarity; over 70% matching coarse features qualifies a potential TPL.Package names do not determine TPL identity, and search continues through other features whether or not package-name matching succeeds.Source: 4) Library Identification · p. 5
• Version identification compares fine-grained features after potential matching, requiring method similarity above a threshold and then comparing the number of matched methods.The earlier stage records matches, so fewer than 30% of methods need comparison in this phase.Source: 4) Library Identification · pp. 5–6
• TPL similarity qualifies a database version at TSS ≥ 0.95, and ATVHunter selects the qualifying version with the largest similarity score.The TPL score is based on matched methods, each meeting the method-similarity threshold; the paper sets θ = 0.85.Source: 4) Library Identification · p. 6

• ATVHUNTER first builds a database of vulnerable TPL versions.Source: B. Vulnerable TPL-V Identification · p. 6
• It then uses that database to identify vulnerable TPL versions present in apps.Source: B. Vulnerable TPL-V Identification · p. 6
• The workflow pairs vulnerable-version reference data with app-level version detection.Source: B. Vulnerable TPL-V Identification · p. 6

1) Database Construction:

• The database contains 1,180 CVEs from 957 unique TPLs, covering 38,243 affected versions.TPL filenames were mapped to CPE format and queried against the public CVE database.Source: 1) Database Construction · p. 6
• It adds 224 security bugs from 152 open-source TPLs, covering 4,533 versions, cross-validated by industry security experts.Source: 1) Database Construction · p. 6

2) Vulnerable TPL-V Identification:

• ATVHUNTER checks identified in-app TPL versions against the vulnerable database and generates a detailed vulnerability report for matches.Source: 2) Vulnerable TPL-V Identification · p. 6

C. Implementation

• The implementation uses APKTOOL and Androguard for app processing, SOOT for CFGs and opcodes, and ssdeep plus edit distance for matching.It is implemented in more than 2,000 lines of Python.Source: C. Implementation · p. 6

IV. EVALUATION

• The team evaluates effectiveness, scalability, and obfuscation resilience on an Ubuntu 16.04 cloud system with an 8-core Xeon Gold 6151 CPU and 128 GB memory.Source: §IV · p. 6

A. Preparation

• The ground truth contains 356 apps and 189 unique TPLs represented by 6,819 complete version files.The apps were manually analyzed; 144 of 500 collected apps were excluded because Maven lacked complete TPL versions.Source: A. Preparation • · pp. 6–7
• Thresholds were selected using three groups of 200 apps each, assessed with method- and TPL-level false-positive and false-negative rates.Source: A. Preparation • · p. 7
• The selected thresholds are θ = 0.85 for method similarity and δ = 0.95 for TPL similarity.At θ = 0.85, method-level FPR is less than 1% and FNR is less than 0.5%; δ = 0.95 balances TPL-level false positives and false negatives.Source: A. Preparation • · p. 7, Figure 4 · p. 7

B. RQ1: Effectiveness Evaluation

• ATVHUNTER outperforms state-of-the-art tools across metrics, with 98.58% precision and 88.79% recall at library level and 90.55% precision and 87.16% recall at version level.Source: B. RQ1: Effectiveness Evaluation · pp. 7–8, Table I · p. 8
• Some releases with identical Java code differ in resources, configuration, or native code, but these differences do not affect vulnerable-TPL identification.Source: B. RQ1: Effectiveness Evaluation · p. 8
• False positives arise from reused components, changed coordinates, and near-identical versions; false negatives include stripped methods, host-namespace removal, or missing database entries.Source: B. RQ1: Effectiveness Evaluation · p. 8
• Compared with package-structure-dependent tools, ATVHUNTER's CFG adjacency list is less sensitive to CFG modifications, and fuzzy hashing makes fingerprints more robust to code changes.Source: B. RQ1: Effectiveness Evaluation · p. 8

C. RQ2: Efficiency Evaluation

• 66.24s per app on average makes ATVHUNTER faster than LibScout at about 83s, LibID at about 16.56h, and LibPecker at about 4.5h.Detection time excludes database construction and is measured on a shared dataset of 6,819 TPL versions.Source: C. RQ2: Efficiency Evaluation · p. 8, Table II · p. 9

D. RQ3: Obfuscation-resilient Capability

• The obfuscation evaluation used 100 apps and four Dasho transformations: renaming, control-flow randomization, package flattening, and dead-code removal.The study compared one original-app group with four obfuscated groups.Source: D. RQ3: Obfuscation-resilient Capability · p. 9
• 99.26% is ATVHUNTER’s detection rate on apps without obfuscation, the highest among the compared tools.LibPecker follows at 98.79%; LibID’s 12.93% rate is attributed mainly to decompilation failures.Source: D. RQ3: Obfuscation-resilient Capability · p. 9, Table III · p. 9
• Detection rate remains over 90% under obfuscation techniques other than code removal, which reduces ATVHUNTER’s rate by about 24%.Package-flattening recall matches the rate on unobfuscated apps; LibScout’s performance drops by more than 70%.Source: D. RQ3: Obfuscation-resilient Capability · pp. 9–10, Table III · p. 9
• ATVHUNTER uses CFGs and basic-block opcodes, retaining semantic information while removing operands to resist identifier renaming.It divides opcode sequences into small pieces and uses fuzzy hashes to reduce interference from dead-code removal and control-flow changes.Source: D. RQ3: Obfuscation-resilient Capability · p. 10
• Class-dependency relations split TPL candidates without relying on package structure, unlike tools whose signatures depend on package hierarchies.Package flattening can alter or remove those hierarchies, and different TPLs may share package names.Source: D. RQ3: Obfuscation-resilient Capability · p. 10
• Dead-code removal affects all tools, but LibPecker performs better because its class-dependency feature preserves method-call relationships and more semantic information.ATVHUNTER’s CFG feature may include methods and classes that the host app does not invoke.Source: D. RQ3: Obfuscation-resilient Capability · p. 10

• 104,446 Google Play apps across 33 categories were collected, covering apps with 10,000 to 5 billion installations and latest versions crawled from August 2019 to February 2020.The study focuses on the 73,110 apps found to use TPLs.Source: §V · p. 10
• 73,110 of the 104,446 apps, or 72%, use TPLs to facilitate development.These apps form the subject of the subsequent analysis.Source: §V · p. 10

A. Vulnerable TPL Landscape

• 21.35% of dataset vulnerabilities have high or critical CVSS v3.0 severity, and 74.95% of vulnerable TPLs are reused by other TPLs.Severe cases include risks such as remote code execution and sensitive-data leakage; 98.7% of vulnerable TPLs belong to utility libraries.Source: A. Vulnerable TPL Landscape · p. 10

B. Impact Analysis of Vulnerable TPLs

• 12.37% of the 73,110 apps include vulnerable TPL versions, involving 53,337 known vulnerabilities and 7,480 security bugs.The study also found that 329 vulnerable apps contained TPLs with both vulnerabilities and security bugs.Source: B. Impact Analysis of Vulnerable TPLs · p. 10

C. Lessons Learned

• Developer feedback suggests many app developers are unaware of TPL security risks or patches, while many app markets lack mechanisms to warn about them.The researchers sent 50 emails and received five replies in two months; some developers cited the cost of adapting their code as a reason to keep old versions.Source: C. Lessons Learned · p. 11

VI. DISCUSSION

• When Java code is identical across versions, ATVHunter returns several candidates rather than one specific version, causing some false positives.Source: §VI · p. 11
• Mistaking imported TPLs for part of the host app can cause false negatives; static analysis may also miss dynamically loaded libraries and dynamic features.Source: §VI · p. 11
• The system covers Java libraries, not native libraries, whose vulnerabilities the authors say can have more severe consequences.Detecting vulnerable native libraries is left for future work.Source: §VI · p. 11
• Its Maven-based database cannot identify newly emerging TPLs, so dynamically maintaining the database remains future work.The authors report crawling about 3 million TPLs to build the feature database.Source: §VI · p. 11
• The evaluation uses only free apps, and the similarity threshold may produce false positives and false negatives.Source: §VI · p. 11

VII. CONCLUSION

• ATVHunter pinpoints TPL versions and identifies vulnerable in-app TPLs; its database contains 1,180 CVEs and 224 security bugs.The authors say the system can help improve app quality and reveal threats to the Android ecosystem.Source: §VII · p. 11, §VI · p. 11