Pith. sign in

REVIEW 3 major objections 5 minor 46 references

Agentic Discovery and Validation of Android App Vulnerabilities

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

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

Pith's one-line read A two-phase agentic pipeline both finds and validates Android vulnerabilities, covering 78.3% of a benchmark and finding 104 real-world zero-days.

desk verdict A useful engineering paper whose Ghera detection core is credible; the headline 104-zero-day claim is not supported as written because the validation loop is self-referential and the real-world labels lack external ground truth. read the letter →

arxiv 2508.21579 v1 pith:2734RPBD submitted 2025-08-29 cs.CR

Ziyue Wang , Liyi Zhou This is my paper · ORCID
classification cs.CR
keywords Androidvulnerabilitydetectionagenticsecurityanalysisproof-of-conceptgenerationLLMagentszero-dayvulnerabilitiesstaticapplicationtestingoracleemulator-basedvalidation
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

The paper argues that a single AI-agent pipeline can do what static analyzers and fuzzers have not: actually prove that Android vulnerabilities are exploitable by generating working proof-of-concept attacks. The proposed system, A2, first combines LLM code reading with standard static-analysis tools to produce a short list of speculative vulnerabilities, then runs a planner–executor–validator loop that designs, executes, and independently verifies an exploit for each candidate. On the 60-app benchmark the pipeline covers 78.3% of labeled vulnerabilities, far above the 30.0% of the leading static tool, while emitting a few dozen findings instead of thousands of warnings. On 160 production apps it reports 104 previously unknown true-positive vulnerabilities, 57 of them accompanied by automatically generated and self-validated PoCs. The significance, if the results hold, is that automated security analysis can move from flagging suspicious code to demonstrating real attacker impact.

What carries the argument

The load-bearing mechanism is the three-agent validation loop with LLM-generated oracles. For each speculative finding, a PoC Planner produces a task list with expected outcomes (using read-only tools only), a Task Executor carries out the plan through function calls, and a Task Validator—kept read-only and forbidden to trust the executor's self-report—constructs custom oracle checks per finding and re-runs the relevant steps to decide PASS or FAIL; failures return to the planner for replanning. The oracle step is the core novelty: instead of fixed heuristics, each expected effect becomes specific assertions (e.g., a file exists, a cryptographic key matches a value, the resumed activity equals the target), which the validator re-computes independently.

What would settle it

Re-run the validation pipeline on a random sample of the 57 claimed self-validated zero-day PoCs with a different LLM as task validator and a fresh emulator, and record how many still pass; if the pass rate falls far below 100%, the validation signal is partly model-specific rather than a property of the exploits. A complementary check runs the same loop on a set of known-benign APKs and counts how many speculative findings wrongly pass oracle checks.

Watch

Extended reading notes

Core claim

A2's central claim is that vulnerability discovery and validation can be unified in one agentic workflow, and that the validation half—turning a suspicion into an executable exploit with independent verification—is what separates its results from prior tooling. In the discovery phase, LLMs analyze decompiled code and the manifest, optionally enriched by warnings from three static analyzers; an LLM aggregator deduplicates and filters these into a small set of speculative findings. In the validation phase, a PoC planner writes a step-by-step exploitation plan, a task executor executes it through 29 function calls spanning UI, intents, file system, logs, code execution, and custom APK builds, and a task validator independently re-checks each claimed effect using dynamically generated oracles and feeds failures back for replanning. The paper reports that on the 60-app benchmark the full loop validates 68.0% of actionable findings with its strongest configuration and correctly rejects all seven false positives it was given; on 160 production APKs it reports 104 true positives with 54.8% validated end-to-end by automatically generated PoCs.

Load-bearing premise

The results stand or fall on whether a validation step designed and judged by an LLM, fed back through another LLM, is real evidence of exploitability; if those judgments are systematically unreliable, the validated-finding counts and the zero-day numbers are unverified model output.

Editorial extensions

If this is right

  • Static analysis tools retain a supporting role in A2: they provide code-line localization and call-graph evidence that guides and filters the agent, but they are no longer the primary detector since LLM analyzers already cover every vulnerability the static tools find on the benchmark.
  • The per-finding validation cost ($0.59 to $26.85 depending on model choice, median around $1.77 for the cheaper configuration) is low enough that automated PoC generation can sit inside a triage workflow instead of being a manual research task.
  • The reported residual hallucination rate of 4.7 to 12.6 percent for executor claims is a quantifiable floor for manual review: roughly one in twenty to one in eight steps an executor reports is wrong, so human review of validated findings remains necessary.
  • Seventeen vulnerability classes (notably network man-in-the-middle attacks) fall outside the validation scope because they are not observable as state changes on a stock emulator, which delimits the system's current attack surface.
  • Long-context function-calling degradation after about 14 execution steps motivates cycle detection that halts a stuck executor, reducing the observed cost blow-ups.

Reading between the lines

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

  • If the oracle-based validation pattern generalizes, the same planner–executor–validator architecture, with domain-specific oracles, could transfer to iOS, web, or firmware security instead of remaining Android-specific.
  • The 57 self-validated real-world PoCs suggest a new success metric for vulnerability scanners — PoC yield — where a finding counts only when an executable and independently checked exploit exists; this would raise the bar for both static analyzers and fuzzers.
  • A decisive test not run in the paper is cross-model validation: re-validating a sample of the 57 PoCs with a different LLM family as the validator to see whether the oracle judgments are model-dependent.
  • The 5 MB APK size cutoff means large enterprise apps are currently out of reach; a testable extension is retrieval-based, hierarchical code analysis that would tell whether the coverage and validation gains persist on bigger codebases.
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 introduces A2, a two-phase LLM-agent system for Android vulnerability discovery and validation. The discovery phase combines four LLM analyzers with optional SAST tool signals and aggregates them into speculative vulnerability findings; the validation phase uses a Planner-Executor-Validator loop to generate PoCs and judge them via LLM-generated oracles. On the Ghera benchmark (n=60), A2 reports 78.3% coverage (47/60) across four aggregation models, and validated-PoC rates of 61.3% (mixed config) and 68.0% (unified config). On 160 production APKs (from 169 AndroZoo samples), the paper reports 104 true-positive zero-day vulnerabilities, 57 with self-validated PoCs, and claims significant reduction in warning volume relative to SAST tools.

Significance. If the validation claims held, this would be a substantial step toward end-to-end automated Android vulnerability assessment. The Ghera coverage result is genuinely anchored: 47/60 is reproduced by four different aggregation engines and exceeds the best individual model and all SAST baselines, and the cost/efficiency analysis is unusually detailed. The paper also honestly reports residual hallucination rates (12.6% mixed, 4.7% unified) and one documented false-positive-as-true-positive case. However, the central validation claim rests on LLM-generated oracles produced and judged by the same model family that issued the original findings; the paper's own data show this oracle can certify false positives, and the real-world zero-day counts have no external ground truth. The measured false-positive certification rate, the inconsistent denominator in the validated-rate computation, and the withheld real-world artifacts mean the headline 'validated' numbers are not yet established.

major comments (3)
  1. [§5.5, Table 7] The validated finding rates 46/75 (61.3%) and 51/75 (68.0%) use a denominator of 75, which is 82 total findings minus 7 false positives. But the 7 FPs come from the 63 evaluated findings (82−2−17=63), while the 17 out-of-scope and 2 unable-to-install findings were explicitly excluded from evaluation. The denominator therefore includes 19 unevaluated findings, which overstates the number of actionable cases and understates the success rate. Please recompute the rates on the evaluated set of 63 findings (e.g., 46/63 and 51/63) and on the non-FP subset of those findings, and report both clearly.
  2. [§4.3, §5.5, Table 7] The validation oracle is designed and executed by the Task Validator, an LLM drawn from the same Gemini 2.5 family that produced the speculative findings in the discovery phase, and the PASS/FAIL decision is an LLM judgment rather than an independent check. The manuscript's own measurements show this oracle certifies false positives: Table 7 lists OpenSocket-InformationLeak-2 as ⊙ (false positive misclassified as true positive) in the unified configuration, and §5.5 reports residual hallucination rates of 12.6% (mixed) and 4.7% (unified) among execution claims. Consequently, a 'validated vulnerability finding' as defined in §3 does not yet demonstrate exploitability with the reliability claimed in the abstract. Please add an independent validation component (e.g., human expert re-review of a random sample of PoCs, or deterministic oracles for cryptographic/token-based findings) and report per-finding whether the deciding oracle is deterministic or LLM-based.
  3. [§6, §12] The 104 real-world zero-day vulnerabilities and 57 self-validated PoCs are labeled only by the authors' manual review; no vendor confirmations are reported, and §12 withholds application identifiers, sample names, and PoC artifacts. Because §5.5 establishes that the validation pipeline certifies false positives at a measurable rate (including a concrete ⊙ case on Ghera), the real-world counts are not independently verifiable as presented. Please provide access to PoC artifacts or detailed logs for reviewers, report vendor responses (even aggregated), or present an independent re-validation of a randomly selected subset of the 57 claimed self-validated findings.
minor comments (5)
  1. [§6, Table 4] The abstract and Table 4 say 169 production APKs, while §6 says 9 APKs were excluded as uninstallable and the analysis covers 160 APKs; please clarify which number refers to the scanned set.
  2. [Table 7] The table heading contains a typo: 'UnnecesaryPerms-PrivEscalation-1' should read 'UnnecessaryPerms-PrivEscalation-1'.
  3. [§5.5, Contribution list] The contribution bullet states that A2 'correctly rules out all false positives (7/7)', but Table 7 shows that the unified configuration misclassifies OpenSocket-InformationLeak-2 as a true positive (⊙); please specify that the 7/7 claim applies only to the mixed configuration.
  4. [§5.4, Eq. (1)] The detection efficiency metric E_i includes the unknown total vulnerability count V_total; since V_total is a constant across tools, the metric is only meaningful as the ratio R_i/A_i. Please state that V_total cancels in relative comparisons or remove it from the definition.
  5. [References] Several references appear to be generic placeholders rather than verifiable sources (e.g., [20] 'John Smith, Jane Lee, and Chen Wang' and [23] 'Richard Chen, Sofia Martinez, and David Kim'). Please verify these citations and replace them with the actual published works.

Circularity Check

1 steps flagged · score 5.0 of 10

The real-world zero-day and self-validated-PoC claims rest on LLM-generated oracles judged by the same model family, making the headline evidence self-confirming rather than independent.

  1. self definitional [Abstract; Section 3 Terminology; Section 4.3 Vulnerability Oracle]
    "A2 then generates working Proof-of-Concepts (PoCs) for 51 of these speculative findings, transforming them into validated vulnerability findings that provide direct, self-confirming evidence of exploitability. ... Validated Vulnerability Finding. A vulnerability for which at least one working PoC has been produced, and an LLM assessment indicates that the PoC demonstrates the vulnerability. ... A2 adopts a different strategy. Instead of relying on fixed heuristics, the Task Validator uses LLMs to generate customized oracles for each vulnerability, case by case."

    The paper's central evidence of exploitability is the category 'Validated Vulnerability Finding,' but that category is defined by an LLM assessment, not by an independent check. In the validation loop, the same model family that generated the speculative finding also designs the oracle and issues PASS/FAIL. The abstract explicitly calls the resulting evidence 'self-confirming.' For the 169 AndroZoo production APKs reported in Section 6, there is no external ground truth, vendor confirmation, or artifact disclosure behind the '104 true-positive zero-days' and '57 self-validated PoCs'; those counts therefore reduce to the LLM's own oracle accepting its own claims.

full rationale

The Ghera benchmark detection and validation results are anchored to external labels: detection recall is measured against 60 documented Ghera vulnerabilities, and the TP/FP statuses in Table 7 are manually cross-checked by multiple researchers. Those comparisons do not reduce to the system's own outputs. The circularity is confined to the production-APK claims. Section 3 defines a 'Validated Vulnerability Finding' as one for which 'an LLM assessment indicates that the PoC demonstrates the vulnerability,' and Section 4.3 says the Task Validator 'uses LLMs to generate customized oracles for each vulnerability.' Role separation between executor and validator is not independence of evidence: the judge and the proposer are drawn from the same model family, and the paper itself calls the result 'self-confirming evidence of exploitability.' Section 5.5 reports residual hallucination rates of 12.6% (mixed) and 4.7% (unified), and Table 7 shows the unified configuration marking the known false positive OpenSocket-InformationLeak-2 with ⊙ (FP misclassified as TP). That demonstrates the self-generated oracle can certify a false positive even where ground truth exists. For the 104 real-world zero-days, no external ground truth is available; Section 12 withholds APK identifiers and artifacts, and Section 6 relies on the authors' manual review. Thus the headline production-APK results are only as strong as the self-referential LLM judgment, which is a partial self-definitional circularity rather than an independent empirical confirmation. This is not a fitted-parameter or self-citation-chain circularity, so a moderate score of 5 is appropriate.

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

A2 is an empirical engineering paper, not a derivation, so the ledger records the human- and model-dependent assumptions that support the claims rather than fitted constants. No new physical or formal entities are introduced; the vulnerability oracle is an LLM-generated procedure, not an independently evidence-bearing entity.

free parameters (3)
  • Validation retry limit = 20 iterations
    Hand-chosen budget in Section 5.2 and Section 5.5; validation success rates (61.3% and 68.0%) are conditional on this cap, and several cases stop at the maximum iteration limit in Table 7.
  • APK size inclusion threshold = 5 MB
    Selection threshold in Section 5.1 to fit model context windows; it limits the real-world dataset to small APKs and is acknowledged in Section 8 as a scope constraint.
  • LLM thinking budget = 24576 tokens
    Set in Section 5.2 to keep reasoning capacity consistent across Gemini models; it affects detection quality and cost, but is not fitted to the outcome.
assumptions (5)
  • domain assumption Ghera's documented vulnerability labels are correct and complete for the 60 APKs.
    Used as ground truth for coverage (B_TP) and for manual TP/FP classification in Section 5.3; the paper itself notes Ghera labels do not exclude other flaws, so it restricts benchmarking to documented labels.
  • domain assumption The Android emulator setup preserves real-world exploitability.
    PoC validation runs in an emulator (Section 5.2); network-dependent vulnerabilities are excluded (Section 8), and real-world exploitability is assumed to transfer from the emulator to production devices.
  • domain assumption Authors' manual review correctly classifies TP and FP for the real-world APK results.
    No third-party or vendor confirmation is reported; all 104 zero-day and 3 false-positive classifications in Section 6 rest on the authors' inspection.
  • domain assumption LLM outputs are not memorized from public benchmarks despite de-identification.
    The paper removes textual vulnerability descriptions and replaces identifiers (Section 5.1) to reduce leakage, but cannot rule out pretraining exposure to Ghera or AndroZoo code.
  • domain assumption LLM-generated oracles accurately detect the claimed exploit effect.
    The Validator designs and applies oracles that are themselves LLM outputs (Section 4.3); residual hallucination rates of 4.7 to 12.6 percent are acknowledged in Section 5.5.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Agentic Discovery and Validation of Android App Vulnerabilities." pith.science (2026). https://pith.science/paper/2734RPBD

@misc{pith2026250821579,
  author       = {Pith},
  title        = {Pith review of: Agentic Discovery and Validation of Android App Vulnerabilities},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2734RPBD}},
  note         = {Machine review of arXiv:2508.21579}
}
read the original abstract

Existing Android vulnerability detection tools overwhelm teams with thousands of low-signal warnings yet uncover few true positives. Analysts spend days triaging these results, creating a bottleneck in the security pipeline. Meanwhile, genuinely exploitable vulnerabilities often slip through, leaving opportunities open to malicious counterparts. We introduce A2, a system that mirrors how security experts analyze and validate Android vulnerabilities through two complementary phases: (i) Agentic Vulnerability Discovery, which reasons about application security by combining semantic understanding with traditional security tools; and (ii) Agentic Vulnerability Validation, which systematically validates vulnerabilities across Android's multi-modal attack surface-UI interactions, inter-component communication, file system operations, and cryptographic computations. On the Ghera benchmark (n=60), A2 achieves 78.3% coverage, surpassing state-of-the-art analyzers (e.g., APKHunt 30.0%). Rather than overwhelming analysts with thousands of warnings, A2 distills results into 82 speculative vulnerability findings, including 47 Ghera cases and 28 additional true positives. Crucially, A2 then generates working Proof-of-Concepts (PoCs) for 51 of these speculative findings, transforming them into validated vulnerability findings that provide direct, self-confirming evidence of exploitability. In real-world evaluation on 169 production APKs, A2 uncovers 104 true-positive zero-day vulnerabilities. Among these, 57 (54.8%) are self-validated with automatically generated PoCs, including a medium-severity vulnerability in a widely used application with over 10 million installs.

Figures

Figures reproduced from arXiv: 2508.21579 by the authors.

Figure 1
Figure 1. Android vulnerability assessment faces three key [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The end-to-end workflow of A2, from APK input to validated vulnerability findings with proof-of-concept output. A2 operates in two phases: Agentic Vulnerability Discovery (➀-➄, blue blocks ) and Agentic Vulnerability Validation (➅–➇, brown blocks ). In the vulnerability discovery phase, the target APK is decompiled and its resources extracted (➀). LLM agents then analyze the application (➁), producing speculative vu… view at source ↗
Figure 3
Figure 3. Hardcoded key extraction validation workflow. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (7 more)
Figure 6
Figure 6. Figure 6: Progressive authentication bypass demonstration [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Detection performance across vulnerability cate [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Detection efficiency analysis across tool categories. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Kernel density estimation of function calls per task [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Token consumption analysis across different phases and configurations. Green areas represent prompt tokens, pink [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 11
Figure 11. Figure 11: Kernel density of execution time distribution dur [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: A path traversal vulnerability reported in discovery [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 37 canonical work pages

  1. [1]

    Android app statistics 2024

    Google Play Console Developer Dashboard. Android app statistics 2024. https://developer.android. com/distribute/console, 2024. Accessed: 2024-01- 01

    work page 2024

  2. [2]

    2024 mobile security index report

    Verizon. 2024 mobile security index report. https://www.verizon.com/business/resources/ reports/mobile-security-index/, 2024. Ac- cessed: 2024-08-05

    work page 2024

  3. [3]

    Source code analysis tools, 2024

    OW ASP Foundation. Source code analysis tools, 2024. OW ASP Community Pages

    work page 2024

  4. [4]

    Flow- droid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps

    Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. Flow- droid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps. In Pro- ceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implemen...

    work page 2014

  5. [5]

    MobSF: Mobile security framework,

    Ajin Abraham. MobSF: Mobile security framework,

    work page

  6. [6]

    APKHunt: A comprehensive static code analysis tool for android apps, 2024

    Cyber Security Labs. APKHunt: A comprehensive static code analysis tool for android apps, 2024. Version 2.1.3

    work page 2024

  7. [7]

    Under- standing security mistakes developers make: Qualitative analysis from build it, break it, fix it

    Daniel V otipka, Kelsey R Fulton, James Parker, Matthew Hou, Michelle L Mazurek, and Michael Hicks. Under- standing security mistakes developers make: Qualitative analysis from build it, break it, fix it. In 29th USENIX Security Symposium (USENIX Security 20), pages 247– 264, 2020

    work page 2020

  8. [8]

    Brittany Johnson, Yoonkyong Song, Emerson Murphy- Hill, and Robert Bowdidge. Why don’t software devel- opers use static analysis tools to find bugs? In Proceed- ings of the 2013 International Conference on Software Engineering, ICSE ’13, pages 672–681, Piscataway, NJ, USA, 2013. IEEE Press

    work page 2013

Show all 46 references
  1. [9]

    Dynamic application security test- ing, 2024

    OW ASP Foundation. Dynamic application security test- ing, 2024. OW ASP Community Pages

    2024

  2. [10]

    Dynamic security anal- ysis on android: A systematic literature review

    Thomas Sutter, Timo Kehrer, Marc Rennhard, Bernhard Tellenbach, and Jacques Klein. Dynamic security anal- ysis on android: A systematic literature review. IEEE Access, 12:57261–57287, 2024

    2024

  3. [11]

    Bissyandé, Jacques Klein, and Yves Le Traon

    Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. Androzoo: Collecting millions of android apps for the research community. In Proceed- ings of the 13th International Conference on Mining Software Repositories, MSR ’16, pages 468–471, New York, NY , USA, 2...

    2016

  4. [12]

    Android components, 2024

    Google. Android components, 2024. Android Developer Documentation

    2024

  5. [13]

    Dva: Extracting victims and abuse vectors from android accessibility malware

    Haichuan Xu, Mingxuan Li, Qiben Chen, and Atul Prakash. Dva: Extracting victims and abuse vectors from android accessibility malware. In Proceedings of the 33rd USENIX Security Symposium, USENIX Se- curity ’24, pages 1–18, Philadelphia, PA, USA, 2024. USENIX Association

    2024

  6. [14]

    A comprehensive study on static application security testing (sast) tools for android

    Jingyun Zhu, Kaixuan Li, Sen Chen, Lingling Fan, Jun- jie Wang, and Xiaofei Xie. A comprehensive study on static application security testing (sast) tools for android. IEEE Trans. Softw. Eng., page 3385–3402, December 2024

    2024

  7. [15]

    Static code analysis, 2024

    OWASP Foundation. Static code analysis, 2024. OW ASP Community Controls

    2024

  8. [16]

    QARK: Quick android review kit, 2019

    LinkedIn Corporation. QARK: Quick android review kit, 2019. Tool to look for several security related An- droid application vulnerabilities

    2019

  9. [17]

    AndroBugs: An efficient android vulner- ability scanner, 2016

    Yu-Cheng Lin. AndroBugs: An efficient android vulner- ability scanner, 2016. Version 1.0.0

    2016

  10. [18]

    Amandroid: A precise and general inter-component data flow analysis framework for security vetting of android apps

    Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. Amandroid: A precise and general inter-component data flow analysis framework for security vetting of android apps. In Proceedings of the 2014 ACM SIGSAC Confer- ence on Computer and Communications Security, CCS ’14, pages 132...

    2014

  11. [19]

    Gordon, Deokhwan Kim, Jeff H

    Michael I. Gordon, Deokhwan Kim, Jeff H. Perkins, Limei Gilham, Nguyen Nguyen, and Martin C. Rinard. Information flow analysis of android applications in droidsafe. In Proceedings of the Network and Dis- tributed System Security Symposium, NDSS ’15. Inter- net Society, 2015

    2015

  12. [20]

    Llms in software security: A survey of vulnerability detection techniques and insights

    John Smith, Jane Lee, and Chen Wang. Llms in software security: A survey of vulnerability detection techniques and insights. arXiv preprint arXiv:2502.07049, 2024

    2024 arXiv

  13. [21]

    Gptscan: Detecting logic vulnerabilities in smart contracts by combining gpt with program analy- sis

    Yuqiang Liu, Yizhuo Lu, Xiaohang Chen, Yuxing Wang, Zhengzi Xu, Wenbo Liu, Jiahao Chen, Zhenguang Liu, Peiyu Chen, Zhaofeng Zhao, Shengwei Wei, and Yongjun Peng. Gptscan: Detecting logic vulnerabilities in smart contracts by combining gpt with program analy- sis. In Proceeding...

    2023

  14. [22]

    Autodroid: Llm-powered task automation in android

    Hao Wen, Yuanchun Li, Guohong Liu, Shanhui Zhao, Tao Yu, Toby Jia-Jun Li, Shiqi Jiang, Yunhao Liu, Yaqin Zhang, and Yunxin Liu. Autodroid: Llm-powered task automation in android. ACM MobiCom ’24, page 543–557, New York, NY , USA. Association for Com- puting Machinery

  15. [23]

    Au- tonomous llm agents for vulnerability exploitation: Ca- pabilities and limitations

    Richard Chen, Sofia Martinez, and David Kim. Au- tonomous llm agents for vulnerability exploitation: Ca- pabilities and limitations. In Proceedings of the 31st ACM Conference on Computer and Communications Se- curity, CCS ’24, pages 445–460, New York, NY , USA,

  16. [24]

    Langgraph

    LangChain. Langgraph. https://langchain-ai. github.io/langgraph/, 2024. Multi-agent workflow orchestration framework

    2024

  17. [25]

    Jadx: Dex to java decompiler, 2020

    2020

  18. [26]

    Androidguard: Android manifest analy- sis tool, 2024

    AndroidGuard. Androidguard: Android manifest analy- sis tool, 2024. Android security analysis framework

    2024

  19. [27]

    Android emulator, 2020

    2020

  20. [28]

    VLM-Fuzz: Vision lan- guage model assisted recursive depth-first search explo- ration for effective ui testing of android apps

    Biniam Fisseha Demissie, Yan Naing Tun, Lwin Khin Shar, and Mariano Ceccato. VLM-Fuzz: Vision lan- guage model assisted recursive depth-first search explo- ration for effective ui testing of android apps. arXiv preprint arXiv:2504.11675, 2025

    2025 arXiv

  21. [29]

    Vision- driven automated mobile gui testing via multimodal large language model

    Zhe Liu, Cheng Li, Chunyang Chen, Junjie Wang, Boyu Wu, Yawen Wang, Jun Hu, and Qing Wang. Vision- driven automated mobile gui testing via multimodal large language model. arXiv preprint arXiv:2407.03037, 2024

    2024 arXiv

  22. [30]

    An empirical study of functional bugs in android apps

    Yiheng Xiong, Mengqian Xu, Ting Su, Jingling Sun, Jue Wang, He Wen, Geguang Pu, Jifeng He, and Zhendong Su. An empirical study of functional bugs in android apps. In Proceedings of the 32nd ACM SIGSOFT Inter- national Symposium on Software Testing and Analysis, ISSTA 2023, pag...

    2023

  23. [31]

    A1: Autonomous multi- agent system for blockchain security enhancement through real-time exploit generation and validation

    Sihao Gervais and Lei Zhou. A1: Autonomous multi- agent system for blockchain security enhancement through real-time exploit generation and validation. arXiv preprint arXiv:2507.05558, 2024

    2024

  24. [32]

    https://secure-it-i.bitbucket

    Ghera: Repository of android application vulnerabil- ity benchmarks. https://secure-it-i.bitbucket. io/ghera/index.html, 2017

    2017

  25. [33]

    Introduction to fuzzing android native components

    Thiago Peixoto. Introduction to fuzzing android native components. Conviso AppSec Blog, 11 2024. Category: Code Fighters

    2024

  26. [34]

    Fuzzing android: A recipe for uncover- ing vulnerabilities inside system components in android

    Martin Blanda. Fuzzing android: A recipe for uncover- ing vulnerabilities inside system components in android. White paper, Black Hat Europe, 2015

    2015

  27. [35]

    Trueseeing: Non-decompiling android application vulnerability scanner, 2024

    Takeshi Terada. Trueseeing: Non-decompiling android application vulnerability scanner, 2024. Version 2.2.4

    2024

  28. [36]

    Long-context function calling degradation in language models, 2024

    Ziming Wang, Li Chen, and Wei Zhang. Long-context function calling degradation in language models, 2024

    2024

  29. [37]

    Gui-squatting attack: Automated genera- tion of android phishing apps

    Qinggang Chen, Lingling Han, Peng Liu, Zhemin Zhang, and Yang Liu. Gui-squatting attack: Automated genera- tion of android phishing apps. In IEEE Transactions on Dependable and Secure Computing, pages 1–14, 2019

    2019

  30. [38]

    Llmdroid: Enhancing automated mobile app gui test- ing coverage with large language model guidance

    Yanqi Wang, Juntao Chen, Ting Su, Sen Chen, et al. Llmdroid: Enhancing automated mobile app gui test- ing coverage with large language model guidance. In Proceedings of the ACM on Software Engineering, vol- ume 1, pages 1–23, 2024

    2024

  31. [39]

    Guardian: A runtime framework for llm- based ui exploration

    Haoran Yoon, Tianyu Liu, Hanlin Wang, Mingxuan Li, and Yu Feng. Guardian: A runtime framework for llm- based ui exploration. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, pages 1234–1245, 2024

    2024

  32. [40]

    Frontier ai’s im- pact on the cybersecurity landscape

    Wenbo Guo, Yujin Potter, Tianneng Shi, Zhun Wang, Andy Zhang, and Dawn Song. Frontier ai’s im- pact on the cybersecurity landscape. arXiv preprint arXiv:2504.05408, 2025

    2025

  33. [41]

    Cybergym: Evaluating ai agents’ cybersecurity capabilities with real-world vul- nerabilities at scale

    Zhun Wang, Tianneng Shi, Jingxuan He, Matthew Cai, Jialin Zhang, and Dawn Song. Cybergym: Evaluating ai agents’ cybersecurity capabilities with real-world vul- nerabilities at scale. arXiv preprint arXiv:2506.02548, 2025

    2025

  34. [42]

    Zhang, Joey Ji, Celeste Menders, et al

    Andy K. Zhang, Joey Ji, Celeste Menders, et al. Bounty- bench: Dollar impact of ai agent attackers and defenders on real-world cybersecurity systems. arXiv preprint arXiv:2505.15216, 2025

    2025

  35. [43]

    Prompting is all your need: Automated android bug replay with large language models

    Si Xuan Feng, Mingyue Li, Chongwen Ma, Jingling Wang, Yang Liu, and Sen Chen. Prompting is all your need: Automated android bug replay with large language models. In Proceedings of the 46th IEEE/ACM Interna- tional Conference on Software Engineering, ICSE 2024, pages 1–12, 2024

    2024

  36. [44]

    Llm agents can autonomously hack websites

    Richard Fang, Rohan Bindu, Akul Gupta, Qiusi Zhan, and Daniel Kang. Llm agents can autonomously hack websites. arXiv preprint arXiv:2402.06664, 2024

    2024 arXiv

  37. [45]

    Teams of llm agents can exploit zero-day vulner- abilities

    Richard Fang, Rohan Bindu, Akul Gupta, and Daniel Kang. Teams of llm agents can exploit zero-day vulner- abilities. arXiv preprint arXiv:2406.01637, 2024. 15 11 Ethical Considerations This research is conducted with careful attention to ethical responsibilities, which are deta...

    2024 arXiv

  38. [2023]

    Association for Computing Machinery

Pith tools

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