PaperlayerView exact revision on arXiv

Source-linked AI summary

When Ad Networks Misbehave: Understanding Risks of Semi-Drive-By Splash Ads

Song Wu, Bo Wang, Yifan Zhang, Yinfeng Cao, Xueqiang Wang

arXiv:2609.09574v1cs.CR

TL;DR

Ad-network SDKs control how ambiguous interactions are interpreted and reported, while existing monitoring struggles to distinguish genuine intent from coerced activation. AdHive analyzes evasive splash-ad behavior under realistic device conditions; measurements found it across four app markets, and an advertiser obtained a repayment after disclosure.

  • Problem

    Ad-network SDKs control interaction interpretation and reporting, but existing monitoring struggles to distinguish genuine user intent from coerced activation.

    Source: §1 · pp. 1–2

  • Method

    AdHive combines realistic device profiles and synthesized usage and sensor inputs with monitoring and analysis of DeepLink and ad-related event behavior.

    Source: §1 · p. 2, §4.1 · p. 5

  • Results

    4.96% of VIVO apps, 2.13% of XIAOMI apps, 1.70% of WDJ apps, and 2.15% of YYB apps showed the behavior; one network repaid 4 million Yuan.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings document incidental or indirect interactions billed as legitimate engagement and report repayment following disclosure.

    Source: §1 · p. 2

    The threat model covers Android apps with third-party advertising SDKs and focuses on direct launches and sensor-mediated launches with overly sensitive thresholds.

    Source: §4.1 · p. 5

Abstract

from arXiv · show

We investigate the mobile splash ads ecosystem, i.e., full-screen advertisements shown at app launch, where monetization relies on interaction signals that are difficult to verify end-to-end. This setting is especially sensitive because incidental touches and sensor-driven callbacks are common yet easy to misattribute as engagement. Prior work has largely framed mobile ad fraud as a publisher-side problem, while some studies attribute fraudulent operations to embedded ad libraries. Yet an important risk remains underexplored: ad SDKs control how interaction signals are interpreted, measured, and reported, creating an opportunity to reinterpret ambiguous user or device signals as valid advertising interactions. We uncover a previously less-known form of fraud at the ad-network layer in which splash ads are triggered not by intentional user actions but by incidental or indirect interactions, which we term semi-drive-by splash ads. By translating non-ad interactions into billable engagement events, ad networks can inflate performance metrics, overcharge advertisers, and erode user trust. To expose this behavior in the wild, we design AdHive, an automated honeypot-like analysis framework that induces evasive splash-ad delivery and landing behaviors under realistic device conditions. AdHive reproduces human-like activity through LLM-generated usage traces and sensor dynamics, enabling execution paths that remain hidden in conventional analysis environments. Our large-scale measurement across thousands of popular Android applications shows that semi-drive-by splash ads are widespread and are often triggered by subtle signals such as minor sensor variations. We further confirm real-world impact by working with one of China's largest advertisers, identifying multiple ad networks engaging in this fraud and leading to enforced repayments of about 4 million Yuan (approximately US$600,000).

1 Introduction

The introduction identifies ad-network SDKs as an underexamined source of fraud because they control how ambiguous interactions become billable engagement. It presents AdHive and reports widespread app-level findings alongside an advertiser repayment after disclosure.

1 Introduction

  • Prior work largely treats publishers as the adversary, leaving ad-network SDKs’ reinterpretation of incidental events as billable engagement underexamined.SDKs control engagement logic, upstream telemetry, and selective rollout conditions.Source: §1 · pp. 1–2
  • Detection is difficult because SDKs can evade virtualization or instrumentation, require realistic long-horizon triggers, and selectively activate behavior by region, campaign, time, or device.These conditions make static inspection and naive dynamic testing prone to missing triggers.Source: §1 · p. 2
  • Across VIVO, XIAOMI, WDJ, and YYB, prevalence was 4.96%, 2.13%, 1.70%, and 2.15%, respectively, among tested apps.The study tested 31,823 apps after filtering and runtime-compatibility checks.Source: §1 · p. 2
  • Two leading ad networks acknowledged the behavior after disclosure; one returned 4 million Yuan (USD 600,000), 18% of its fees during the period.The advertiser had observed large inconsistencies in conversion metrics.Source: §1 · p. 2
  • Semi-drive-by splash ads turn incidental or indirect interactions into billable engagement, inflating metrics and wasting advertiser budgets.The reported examples include ordinary motion or unrelated touches opening an ad landing page.Source: §1 · p. 2
  • AdHive combines hardened execution, realistic motion and usage synthesis, and LLM-assisted DeepLink and landing-behavior analysis to detect evasive splash ads.The framework is used to measure prevalence, activation conditions, and ecosystem structure in popular Android apps in China.Source: §1 · p. 2

2 Technical Warm-ups

This section describes how ad SDKs mediate mobile-ad interactions and explains why splash-ad signals can be difficult to interpret. Splash ads occupy the screen at app launch, while motion-based triggers rely on inferred intent.

Ad SDKs in mobile advertising

  • Figure 1 depicts an SDK-mediated flow: the SDK captures interactions, redirects through attribution-bearing DeepLinks, and reports events used for validation, metrics, and billing.Advertisers may receive feedback from the destination but generally do not directly observe the original user-side interaction.Source: Figure 1 · p. 3, §2 · p. 3

Splash-Ad interactions

  • Splash ads are full-screen advertisements shown at app launch before the main interface becomes available, and standard workflows redirect only after an explicit ad-related interaction.Source: §2 · p. 3
  • Tap and swipe use direct screen input, whereas shake triggers infer intent from sensor motion, making ordinary movements a source of ambiguity.The section names picking up a phone, walking, or riding in a vehicle as movements that should not be misclassified as engagement.Source: §2 · p. 3

3 Motivation and Challenges

The section uses a shake-trigger example to illustrate how incidental motion and evasive SDK behavior complicate detection. It then frames the requirements for scalable analysis that distinguishes ad-triggered activity from normal app behavior.

3.1 Motivating Example

  • WiFi Master Key’s Baidu SDK triggered splash ads on physical phones but not emulators, using motion thresholds below recommended levels to treat ordinary movement as shakes.Cloud-supplied or default thresholds govern sensor callbacks; dynamic loading and device profiling also affect delivery.Source: §3.1 · p. 4
  • The example exposes three detection challenges: runtime-loaded behavior, overly sensitive motion triggers, and delivery conditioned on runtime or user context.The SDK gathers emulator-identifying information, and observed factors may extend to geographic information and usage.Source: §3.1 · p. 4

3 Motivation and Challenges

  • Scalable analysis must avoid costly manual or device-heavy testing, reproduce realistic environments and usage, and distinguish ad-related redirects from normal app activity.Source: §3.2 · p. 4

3.2 Challenges to Detect At Scale

  • External redirection alone is insufficient evidence of fraud because ad SDKs also use DeepLinks and inter-app jumps in benign workflows.The analysis must distinguish ad-related triggering, redirection, and reporting from normal app and device activity.Source: §3.2 · p. 4

4 Our Detection Tool: AdHive

AdHive is an Android honeypot framework that induces semi-drive-by ads under realistic conditions and attributes observed transitions to ad-related behavior. Its pipeline combines a coherent device profile, realistic usage and sensor inputs, and event analysis.

4.1 Design Overview

  • AdHive combines real-device profile porting, behavior synthesis, and ad-related event attribution to expose hidden ad behavior and classify observed transitions.The three components respectively reduce environment-level detectability, enable behaviorally gated logic to surface, and distinguish ad-related transitions from ordinary app behavior.Source: §4.1 · p. 5, §4.5 · p. 7

4.2 Real-Device Profile Porting

  • AdHive replays a coherent cross-layer device profile into a Redroid-based Android container, preserving signal correlations that SDKs may validate during runtime checks.DeviceFP assembles signals extracted from physical handsets, including device properties, filesystem and shell outputs, kernel attributes, system-service returns, and SELinux posture.Source: §4.2 · p. 5

4.3 Behavior Synthesis

  • AdHive populates the runtime with plausible activity records and controllable motion traces to expose behaviorally gated and sensor-triggered ad flows.LLM-generated traces include installation records, contacts, and routine interactions; motion inputs remain within physically plausible ranges.Source: §4.3 · p. 6

4.4 Ad-Related Event Attribution

  • The attribution analyzer uses normalized runtime events and expert rules to classify transitions as benign app logic or ad-related delivery and parse destinations and routing paths.It examines DeepLinks, intent dispatches, extras, and transition metadata; GPT-4o suggests unseen parameter variants, while deterministic aggregation assigns final labels.Source: §4.4 · pp. 6–7

4.5 System Integration

  • AdHive’s components are sequentially dependent: realistic execution conditions expose hidden logic, behavioral stimulation triggers it, and attribution turns events into structured evidence.Without any one stage, suspicious behavior may remain suppressed, untriggered, or uninterpreted.Source: §4.5 · p. 7

5 AdHive: Implementation and Validation

AdHive combines a hardened Android runtime, realistic device profiles and usage traces, and conservative DeepLink analysis to expose splash-ad behavior that ordinary emulators may miss. Its validation shows stronger ad exposure than existing analysis environments, benefits from usage traces, and improved fraudulent-log detection with GPT-4o-assisted rule expansion.

5.1 Implementation

  • DeviceFP extracts replayable real-device profiles, which AdHive ports across system properties, kernel file access, Android services, and identifiers to reduce environment inconsistencies.The profile was derived from a manual study of 30 confirmed samples; the implementation also synthesizes plausible sensor streams and routine device activity.Source: §5.1 · pp. 7–8
  • A three-stage rule-based analyzer normalizes DeepLink events, extracts attribution features, and conservatively aggregates evidence, using GPT-4o only to suggest manually reviewed rule expansions.It builds caller-to-target package graphs for downstream advertisement attribution and fraud analysis.Source: §5.1 · p. 8

5.2.1 VM detection evaluation.

  • AdHive achieves the lowest abnormality rate and performs best across nine representative VM-detection heuristic families.The evaluation sampled 100 finance apps that displayed VM-detection warnings in LDPlayer; mainstream emulators and VPBOX remained detectable.Source: §5.2.1 · p. 8, Table 1 · p. 8, Table 3 · p. 9
  • AdHive consistently exposes more semi-drive-by ads than existing emulators and analysis frameworks, making realistic execution conditions central to reliable detection.The comparison used the same app versions, network settings, and other configurations; each app was cold-launched ten times for one minute per run.Source: §5.2.1 · p. 9, Table 4 · p. 9

5.2.3 Pipeline Analyzer Evaluation.

  • GPT-4o-assisted rule expansion raises detection from 79/100 to 91/100 fraudulent logs while maintaining a 0.0% false positive rate on 100 benign logs.GPT-4o suggests candidate expressions that are manually verified before entering the deterministic rule dictionary.Source: §5.2.3 · p. 9, Table 5 · p. 9

6 Large-Scale Measurement

AdHive measured semi-drive-by ads across four Chinese Android markets and found them in all four, with prevalence and trigger patterns varying by market. The measurement also identified target-app concentrations, regional and cross-market differences, and evidence locating fraudulent logic in advertising SDKs.

6.2 How prevalent are semi-drive-by ads across markets?

  • 4.96% of VIVO-market apps, 2.13% of XIAOMI apps, 1.70% of WDJ apps, and 2.15% of YYB apps showed semi-drive-by ads in 24-hour runs.The study’s final test set contained 31,823 apps from four Chinese Android markets.Source: §6.2 · p. 10, §6.1 · p. 10

T TP(%) S SP(%) D DP(%)

  • Tools, photography, and lifestyle categories are consistently overrepresented among targets, with the table distinguishing total, sensor-triggered, and tap/scroll/swipe app shares.The category comparison groups direct-launch behaviors into the tap/scroll/swipe interaction category.Source: §6.2 · p. 10, T TP(%) S SP(%) D DP(%) · p. 11

6.3 Sensor-triggered vs. tap/scroll/swipe

  • Sensor-triggered ads dominate in VIVO, WDJ, and YYB, while XIAOMI shows the opposite balance; the authors leave the cause outside the study’s scope.The comparison reran flagged apps with motion sensors disabled under otherwise identical conditions.Source: §6.3 · p. 10

6.4 Which targets are affected?

  • Targets concentrate among major e-commerce and short-video platforms, while QuickApps, mini-programs, and app-store download targets form additional prominent target types.Some reading-related QuickApps direct traffic to specific novels, and some promoted downloads can be forcibly installed through the app store.Source: §6.4 · p. 10, T TP(%) S SP(%) D DP(%) · pp. 11–12

6.5 Economic-region behavioral differences

  • Semi-drive-by ads were detected most often in sampled second-tier cities, followed by first-tier cities, and were much less common in third-tier cities.Target patterns also vary regionally: second-tier cities are associated mainly with Alibaba’s ecosystem, while Beijing is dominated by Kuaishou-related and download-type apps.Source: §6.5 · p. 12

6.6 Different behavior from the same app in different app markets

  • 57 apps showed cross-market behavior discrepancies, including 26 same-version cases, so version drift alone does not explain the differences.Two examined cases contained different SDKs or ad-push services, which may contribute to variation.Source: §6.6 · p. 12

6.7 Ad Networks or App Developers?

  • Manual reverse engineering found the suspicious fraud logic in advertising SDKs in all 100 examined apps, not developer-authored components.The reviewed documentation offered no evidence that app developers could control the relevant fraud parameters.Source: §6.7 · p. 12
  • Motion-triggered activations are difficult to audit because sensor data may remain on-device, leaving advertisers without evidence to assess whether reported engagement reflected user intent.Users may attribute accidental launches to ordinary device handling and rarely report them.Source: §6.7 · pp. 12–13

7 Discussion

The discussion calls for treating ad SDKs as part of the adversarial surface, while interpreting the measurement within the study’s stated scope and limitations. It also identifies implications for oversight and describes constraints on detection and validation.

7.1 Implications

  • Ad SDKs, rather than only app developers, should be treated as part of the adversarial surface for semi-drive-by ad fraud.The authors argue existing frameworks centered on developer behavior or app-side anomalies are insufficient, and call for ad-network auditing and SDK-level accountability.Source: §7.1 · p. 13, §7 · p. 13
  • Advertisers face financial losses and users covert manipulation, motivating stronger SDK transparency, standardized sensor-event reporting, and collaborative auditing.The authors describe their work as a technical foundation for these accountability mechanisms.Source: §7.1 · p. 13

7.2 Limitation

  • The measurement covers Android splash ads in four Chinese markets using hardened emulation and synthesized motion, limiting external validity and potentially leaving trigger-realism gaps.The 24-hour, five-minute launch schedule may miss time-gated, quota-based, or A/B-rolled activations; manual category harmonization may introduce label noise.Source: §7.2 · p. 13
  • Detection assumes sensor-triggered and tap/scroll/swipe variants are mutually exclusive and relies on DeepLink and event-log signatures, so adaptive SDKs or obfuscated telemetry may yield false negatives.The authors also note that aggressive but legitimate motion UX could less likely be flagged.Source: §7.2 · p. 13
  • TC260 thresholds trade false positives against false negatives, and adaptive trigger conditions may reduce the effectiveness of static thresholds.The authors say threshold selection remains underexplored and call for research on adaptive detection methods.Source: §7.2 · p. 13
  • Validation relies on threshold values and the authors’ empirical judgments, with no general user-perspective validation of perceived intrusiveness or harm.The authors call for future user studies.Source: §7.2 · p. 13

8 Related Work

Prior ad-fraud research largely targets publishers, app-layer behavior, or automated interactions; this work instead examines ad networks converting incidental interactions into billable engagement. AdHive also extends environment-resilient analysis to enable observation and attribution at scale.

Ad fraud detection

  • Prior ad-fraud detection covers bots and click farms, deceptive placements [8], and programmatic clicks or replayed interactions [11].A recent study attributed fraud to in-app modules, including third-party ad libraries.Source: §8 · p. 13
  • Unlike publisher-focused studies [8] [11] and work on in-app modules, AdHive examines how ad networks turn incidental or indirect interactions into billable splash-ad engagement.The authors say the prior in-app-module study did not systematically characterize this conversion or distinctly characterize the splash-ad ecosystem.Source: §8 · p. 13

Evasion behaviors

  • AdHive combines hardened virtualization with real-device profiles and synthesized usage traces, enhancing semi-drive-by ad appearance and enabling observation and attribution at scale.The authors place AdHive in the research line of hardened virtualization and sandboxing, and point to its comparative evaluation in Section 5.2.Source: §8 · pp. 13–14

9 Conclusion

The paper presents a systematic study of semi-drive-by splash-ad fraud originating from ad-network SDKs and reports that the behavior is widespread, evasive, and economically motivated. AdHive is designed to induce and identify these activations at scale, providing a practical basis for detection and accountability.

9 Conclusion

  • The study reports that semi-drive-by splash-ad fraud originating from ad-network SDKs is widespread, evasive, and economically motivated.The authors characterize it as the first systematic study of this fraud.Source: §9 · p. 14
  • AdHive is an automated honeypot framework designed to induce and identify fraudulent splash-ad activations at scale.The authors say the framework exposes the behavior.Source: §9 · p. 14
  • The findings describe a new platform-level threat in mobile advertising and provide a practical basis for future detection and accountability.Source: §9 · p. 14

Ethical Considerations

The authors report affected companies and their security teams before submission, and describe safeguards for synthesized contact data. To limit dual-use risk, they plan controlled access to AdHive rather than full public release.

Ethical Considerations

  • Before submission, the authors disclosed findings to affected companies; PDD, Kuaishou Technology, and Alipay responded with confirmation, impact acknowledgment, or a severity rating.Alipay also awarded a bug bounty; other companies were still processing the report.Source: Ethical Considerations · p. 15
  • To reduce privacy risk, the study used Alibaba Cloud’s status API to select only unassigned candidate phone numbers for synthesized contacts.The authors state that the study collected essentially no personally identifiable information from real end users.Source: Ethical Considerations · p. 15
  • The authors plan controlled AdHive access for verified applicants with legitimate purposes, institutional or company affiliations, and agreement to terms of use.They acknowledge this model cannot completely eliminate malicious use, but describe it as a best-effort risk reduction.Source: Ethical Considerations · p. 15

Open Science

The work releases research tools while withholding partner-specific production components under commercial confidentiality; the authors state that these exclusions do not affect reproduction of the core techniques.

Open Science

  • The released research components include FakeInfo, DeviceFP, Libchecker, and compare.py.They support usage-trace simulation, device-fingerprint collection, and app libc comparison.Source: Open Science · p. 15
  • The research tools are publicly available through the project’s source-code release.The release link is provided in the paper.Source: Open Science · pp. 15–16
  • Partner-specific production components are excluded because they contain proprietary business logic, production integration, and sensitive operational data.The authors state that these exclusions do not affect reproducibility of the core techniques.Source: Open Science · p. 16

Ethical Usage of LLMs

The appendix describes a log-analysis pipeline that normalizes DeepLinks, applies expert rules, and uses GPT-4o only to assist rule refinement. Its reported expansion reduces unclassified fraudulent logs while leaving benign-log predictions unchanged.

Ethical Usage of LLMs

  • LLMs support language editing, random test-data generation, and attribution-parameter review, with all judgments manually reviewed by the authors.The tools were not used for black-box automatic classification of log data.Source: Ethical Usage of LLMs · p. 16

A Supplementary Implementation Details

  • DeepLink examples use custom schemes, paths, query parameters, and sometimes nested redirection targets, distinguished by color in the examples.The described colors mark the base scheme or handler, path, query parameters, and nested target.Source: A Supplementary Implementation Details · p. 17

B.1 Tuple description

  • Each event is normalized into an eight-field record capturing app and caller packages, action, URI components, and timestamp.Normalization is intended to remove formatting differences across apps, ad platforms, super-apps, and marketplaces.Source: §B.1 · p. 19

B.2 Raw captured Log

  • A sample cross-app DeepLink invocation is labeled unknown because the caller invokes Kuaishou through its ksnebula scheme.The example has no explicit destination host, path, or app package, so those tuple fields are null.Source: §B.2 · p. 19

B.3 Tag details

  • Five features characterize suspicious DeepLinks, and GPT-4o checks for uncovered attribution parameters only after expert rules return false.Positive suggestions are manually reviewed before being added to the rulebook; GPT-4o is not a standalone detector.Source: §B.3 · pp. 19–20

B.4 Rule-based Evidence Aggregation

  • Aggregation rules classify cross-app logs using attribution parameters, search patterns, special target categories, and redirects, under a no-user-interaction honeypot threat model.The rule union R1, R2, R3, and R6 represents high-confidence fraudulent logs in that setting.Source: §B.4 · p. 20

B.5 Details of Pipeline Evaluation

  • Two annotators labeled 200 logs with 92% initial agreement, resolved disagreements, and compared pipeline labels against the resulting ground truth.The evaluation reports precision, recall, F1 score, and false positive rate.Source: §B.5 · p. 20, §B.4 · p. 20

B.6 Prediction Distribution

  • GPT-4o-assisted rule expansion reduces unclassified fraudulent logs from 21 to 9 while leaving benign-log predictions unchanged.Table 13 reports mutually exclusive predictions before and after expansion.Source: §B.6 · p. 21, Table 13 · p. 21

B.7 Ablation evaluation

The ablation identifies cross_app and has_attribution as the key features for high-confidence fraudulent-log detection; the remaining features mainly refine category interpretation.

B.7 Ablation evaluation

  • The ablation evaluates five variants, each removing one feature: cross_app, scheme_mismatch_appPkg, has_attribution, is_search, or is_jump.The experiment measures each feature’s contribution to final labeling performance.Source: §B.7 · p. 21
  • Removing cross_app reduces recall from 91.0% to 0.0%, while removing has_attribution reduces recall to 14.0%.The false-positive rate remains 0.0% across evaluated variants.Source: §B.7 · p. 21
  • Removing is_search, scheme_mismatch_appPkg, or is_jump causes only a small recall drop or collapses specific categories into the generic advertisement-related label.These features mainly improve category-level interpretation.Source: §B.7 · p. 21
Loading 2609.09574v1…