Pith. sign in

REVIEW 4 major objections 5 minor 2 cited by

TraceRAG bridges natural-language behavior queries and Java code to detect Android malware and trace it to exact code paths.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-04 20:46 UTC pith:7C5VKZ4O

load-bearing objection A useful RAG+LLM integration for explainable Android malware analysis, but the headline accuracy is not supported by the evaluation protocol. the 4 major comments →

arxiv 2509.08865 v1 pith:7C5VKZ4O submitted 2025-09-10 cs.SE

TraceRAG: A LLM-Based Framework for Explainable Android Malware Detection and Behavior Analysis

Guangyu Zhang , Xixuan Wang , Shiyu Sun , Peiyan Xiao , Kun Sun , Yanhai Xiong This is my paper
classification cs.SE
keywords Android malware detectionmalicious behavior analysisretrieval-augmented generationlarge language modelscode summarizationexplainable security analysisstatic analysiscall chain tracing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

TraceRAG is an LLM-and-retrieval system for Android malware analysis that aims to make detection explainable. Its central claim is that a decompiled app's Java methods can be indexed by LLM-generated semantic summaries and retrieved by natural-language behavior questions, so a multi-turn analyzer can trace suspicious behavior to specific code snippets and call chains. On a 100-app sample the paper reports 96% malware detection accuracy and 83.81% behavior-identification accuracy, with the ground truth updated through recent VirusTotal scans and manual verification, and expert reviewers rated the generated reports useful. If the approach holds, security analysts gain a code-grounded alternative to black-box detectors, and the same retrieval-plus-tracing design offers a general way to ask source code where a behavior happens.

Core claim

The paper's central claim is that explainable malware detection can be built by treating each method of an Android app as a retrievable document. A cleaning module strips dead and heavily obfuscated code, a describer module writes a plain-language summary of what each method does and what suspicious intent it may carry, and those summaries—with method and class names as metadata—are embedded and stored in a per-app vector database. At query time, eleven behavior-focused questions retrieve the most semantically similar snippets for each behavior category; a relevance reviewer discards irrelevant hits, and an analyzer inspects the survivors and issues follow-up queries for called methods so th

What carries the argument

The central mechanism is a method-level semantic index: each cleaned Java method is paired with an LLM-written natural-language description plus metadata (method name and class name), and embeddings of those descriptions let natural-language behavior queries retrieve the right code. The second load-bearing mechanism is the analyzer's follow-up query loop: when a snippet calls another method, the analyzer asks for that method by name and class, the metadata filters the vector search to the target, and the system reconstructs call chains incrementally instead of relying on one static pass. The per-app vector database keeps the retrieval scope limited to the app under inspection.

Load-bearing premise

The 96% figure rests on the assumption that re-labelling the 100-app sample with updated VirusTotal scans plus manual inspection was unbiased; seven of the ten initial false positives were reclassified as malicious during that step, so if TraceRAG's reports shaped the re-labelling the accuracy is overstated.

What would settle it

Run TraceRAG on a held-out set whose true malicious status is known before TraceRAG sees it—for instance, benign apps with behaviors injected by a red team. Have independent analysts, blind to TraceRAG's reports, mark which methods and call chains are malicious. If the analysts' labels match TraceRAG's cited code on most samples, the localization claim stands; if the reports frequently cite benign SDK code or miss the injected behavior, the detection and traceability claims fail.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Analysts receive not just a verdict but a chain of evidence: each flagged behavior is tied to the method, class, and call path that implements it.
  • Because each app has its own vector database, the index can be rebuilt or extended incrementally as new behavior queries and app versions arrive, without cross-app contamination.
  • The 11-query behavior taxonomy can be updated as malware evolves, so the detector's coverage is set by the query set rather than by a fixed feature extractor.
  • The same summary-index-plus-follow-up-loop design is language-agnostic; the paper notes it can be carried from Java to Python or C++ and to other code-understanding tasks.
  • If the accuracy numbers reproduce, this type of system could handle the triage stage of malware investigation, leaving human experts to focus on ambiguous cases.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the largest swing in the reported accuracy comes from reclassifying seven of ten initial false positives as malicious during ground-truth updating; an independent blind relabelling study would be the cleanest way to confirm that swing is real and not shaped by TraceRAG's own output.
  • Editorial inference: because the analyzer can only see indexed Java code, behaviors implemented in native libraries, dynamically loaded classes, or SDK internals are structural blind spots; extending the same retrieval pipeline to native binaries or execution traces is the natural next test.
  • Editorial inference: a direct way to benchmark localization quality is to inject known malicious behavior into benign apps and measure how often TraceRAG's cited methods are the ones that actually perform the behavior, sidestepping label noise entirely.
  • Editorial inference: the query set's simplicity is both a strength and a coverage limit; automatically expanding the 11 queries as new malware patterns are reported could broaden detection without giving up interpretability.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes TraceRAG, an LLM+RAG framework for explainable Android malware detection and behavior analysis. The pipeline decompiles APKs, splits Java code into method-level snippets, uses an LLM-Cleanser to remove dead/obfuscated code, generates semantic summaries via LLM-Describer, indexes them in per-app vector databases with metadata, and then runs 11 behavior-focused queries through LLM-Analyzer with multi-turn follow-up retrieval. Reports are assembled by LLM-Organizer into code-level, query-level, and final human-readable reports. The evaluation on 100 AndroZoo apps (70 malicious, 30 benign) reports 90% detection accuracy under original AndroZoo labels and 96% after updating the ground truth of the 30 originally benign samples using newer VirusTotal scans and manual verification; behavior identification accuracy is reported as 83.81%. The paper also contains ablations on description generation, preprocessing, and multi-turn conversation, a comparison with VirusTotal sandbox reports, and structured feedback from Google Android Security Team specialists.

Significance. If the reported accuracy were based on an independent and unbiased ground truth, the contribution would be significant: TraceRAG offers a concrete architecture for code-grounded, explainable malware analysis, and the authors release code and generated reports, which supports reproducibility. The design choices—method-level splitting, semantic descriptions as retrieval indices, metadata filtering, and multi-turn follow-up queries—are reasonable and well motivated, and the ablations provide useful evidence that these components matter. However, the central 96% detection claim is not currently identifiable from the reported evaluation because the ground truth was updated after and in response to TraceRAG's outputs, and the behavior-identification accuracy is measured against a non-independent label source. The core idea is promising and the limitations are stated more openly than usual, but the evaluation needs substantial strengthening before the headline claims can be accepted.

major comments (4)
  1. [IV-B1 (Table III)] The headline 96% detection accuracy rests on a label-update procedure that is not independent of the system. The text says that after TraceRAG flagged 10 false positives, 'seven are found to be valid detections upon closer inspection,' and that the 30 originally benign samples were re-examined. There is no statement that the manual verification was blinded to TraceRAG's reports. If the verifiers saw TraceRAG's output, the reclassification is partly self-confirming. Moreover, only the 30 benign-labeled samples are rechecked; the 70 malicious-labeled samples are not re-examined, so label errors in that half could shift accuracy in either direction. The authors should relabel all 100 APKs using updated VT scans and independent source-code inspection by at least two annotators blinded to TraceRAG's outputs, report inter-annotator agreement, and provide a confusion matrix under both the origi
  2. [IV-B2 (Table I)] The behavior-identification accuracy of 83.81% is computed against VT's behavior analysis results, but the abstract attributes this figure to 'updated VirusTotal scans and manual verification'; no manual behavior verification is described in IV-B2. More fundamentally, the three behavior categories used for evaluation are exactly the categories used to design the 11 queries in Table I. The queries are hand-crafted around those categories, and the LLM is instructed to answer them. Behavior accuracy therefore partly measures how well the system reproduces the query designers' own taxonomy, not whether the underlying behaviors are objectively present. An independent behavior ground truth (e.g., manual labeling of all 70 malicious APKs by analysts who are blinded to TraceRAG's outputs, using a predefined coding protocol, or a standard benchmark with externally validated labels) is needed befo
  3. [IV-B3 and IV-D] The evaluation lacks a direct detection comparison with existing malware detectors. Table V compares report coverage with VT sandbox outputs, but coverage of sandbox behavior logs is not the same as detection accuracy. The authors state in IV-D that 'direct quantitative comparisons with conventional detection systems are not entirely meaningful,' yet this does not justify omitting them. At minimum, one or two standard static detectors or recent LLM-based baselines should be run on the same 100 APKs using the same updated ground truth, with accuracy, precision, recall, and F1 reported. Without such a comparison, the practical significance of the 96% accuracy is not contextualized, and RQ1 is not fully answered.
  4. [IV-A and Table III] The evaluation uses only 100 apps and a single run of the pipeline. No confidence intervals, bootstrap estimates, or statistical tests are reported. This is especially consequential because the accuracy estimate is highly sensitive to label corrections: moving 7 of 30 benign samples from false positive to true positive changes the reported accuracy by 7 percentage points. The sampling procedure is also described only as random selection of apps with fewer than 3,000 code snippets; representativeness with respect to real-world Android malware is not demonstrated. The authors should report confidence intervals, consider repeated runs to account for LLM stochasticity (o3-mini is not deterministic), and discuss the sensitivity of the reported figures to the label-update procedure.
minor comments (5)
  1. [III-D1, Table I] The mapping between the 11 queries and the three behavior categories should be explicit. The table lists 4, 3, and 4 queries per category, but the evaluation section says each app is assigned to 'one or more of the three predefined behavior categories.' Clarify how categories are scored from query-level results and how multi-label precision/recall are computed.
  2. [IV-B2] The sentence 'TraceRAG correctly identifies 176 of the 210 labeled behaviors' suggests each malicious app has exactly 3 labels. Given the query structure, it should be clarified whether every app has all 3 behavior labels, or whether labels are sparse and the denominator 210 is a design choice.
  3. [III-B2 and V] The description of LLM-Cleanser is brief. The paper should specify how the LLM determines reachability and how the risk of removing live code—acknowledged in Section V—was audited. A quantitative example of cleaning-induced information loss would strengthen the discussion.
  4. [IV-C2] There is a typo: 'explaination' should be 'explanation.' Also, the abbreviation VT is sometimes introduced as VirusTotal and sometimes used directly; please standardize.
  5. [Table V] In Table V, the columns use check/cross symbols. Adding a legend or replacing the symbols with Yes/No would improve readability, especially because 'Behavior source code' and 'Link between them' may be unclear to readers unfamiliar with sandbox report formats.

Circularity Check

1 steps flagged

Minor evaluation ground-truth contamination in the 96% accuracy; no circular derivation in the RAG pipeline itself.

specific steps
  1. other [Section IV-B1 (RQ1, Malware Detection Performance)]
    "To obtain more accurate performance estimates, we re-examine the 30 samples originally labeled benign by AndroZoo, using updated VT scans and manual verification. Among the 10 false positives reported by TraceRAG, seven are found to be valid detections upon closer inspection. In addition, we identify one actual malicious sample that TraceRAG failed to detect—a false negative. Correcting these discrepancies raises our effective malware detection accuracy from 90% to 96%."

    The refined ground truth used to compute the 96% accuracy is not established independently of TraceRAG: the re-examination is performed specifically on the 30 benign-labeled samples, and the seven reclassifications come from the set of TraceRAG's false positives. Because the revised label for each of these samples is the output of a manual/VT re-check triggered by the model's own flag, the accuracy gain partially measures the model's agreement with labels it helped select for correction. The paper does not report a blinded protocol, so the evaluation is not fully external; the headline detection result is therefore partly self-confirming. This is a validity limitation of the measurement, not a fitted-parameter derivation, so circularity is partial and minor.

full rationale

TraceRAG is an empirical system: it takes decompiled Java code, generates LLM-based summaries, retrieves snippets via predefined behavior queries, and produces reports. No parameter is fitted to the evaluation labels, and no detection output is algebraically derived from the ground truth. The 90% / 96% detection accuracies and 83.81% behavior accuracy are comparisons against external labels (AndroZoo, VirusTotal) plus manual inspection. The main concern is the label-update step in Evaluation 2, where the ground truth for false positives is revised after TraceRAG produced its outputs, without a stated blinded protocol. This makes the accuracy gain partly self-confirming, but it is not a full circularity because the reclassification relies on updated VT scans and source-code inspection rather than on TraceRAG's outputs by construction. The behavior queries are aligned with the three evaluation categories, but the behavior ground truth is VT's independent sandbox results, so this is a scope limitation, not a circular reduction. No self-citation chain or imported uniqueness theorem is load-bearing. Overall, the central pipeline is self-contained and the circularity is minor and confined to the evaluation protocol.

Axiom & Free-Parameter Ledger

2 free parameters · 5 axioms · 0 invented entities

The central claims rest on several domain assumptions about the fidelity of decompiled code, the reliability of LLM-generated summaries, and the completeness of the hand-designed query set. The two free parameters (retrieval top-k and the malicious-sample counting rule) affect the reported numbers. No new entities are postulated.

free parameters (2)
  • top-k retrieval threshold = 5
    The system retrieves the top 5 code snippets per query; this threshold is chosen in Section III-D2 to balance stability and relevance, but is not tuned on a held-out validation set.
  • malicious sample criterion = report must explicitly identify a malicious behavior with implementation explanation
    Introduced in Section IV-B to separate true malware from generic security warnings; this rule directly affects the accuracy metric and is applied after observing the system's outputs.
axioms (5)
  • domain assumption Decompiled Java source code is a faithful representation of app behavior
    TraceRAG analyzes only JADX-decompiled Java methods, ignoring native libraries and dynamic loading; this is acknowledged as a limitation in Section V-2.
  • domain assumption LLM-generated descriptions are faithful semantic indices for code retrieval
    The whole RAG pipeline rests on LLM-Describer producing accurate summaries; Section III-B2 shows a single positive example, and the ablation shows raw-code indexing fails on one sample.
  • ad hoc to paper The 11 queries cover the common malicious behavior categories
    The queries are manually designed based on empirical experiments and expert input (Section III-D1); their completeness determines the behavior detection ceiling.
  • domain assumption Updated VirusTotal scans and manual verification provide unbiased ground truth
    Used in Evaluation 2 to re-label samples (Section IV-B1); if VT is incomplete or manual verification is biased, the 96% accuracy is not meaningful.
  • domain assumption The 100-app sample is representative of real-world Android malware
    Apps are randomly selected from AndroZoo but restricted to those with fewer than 3,000 code snippets (Section IV-A), which may exclude complex apps.

pith-pipeline@v1.3.0-alltime-deepseek · 16693 in / 8947 out tokens · 92168 ms · 2026-08-04T20:46:39.166942+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of TraceRAG: A LLM-Based Framework for Explainable Android Malware Detection and Behavior Analysis." pith.science (2026). https://pith.science/paper/7C5VKZ4O

@misc{pith2026250908865,
  author       = {Pith},
  title        = {Pith review of: TraceRAG: A LLM-Based Framework for Explainable Android Malware Detection and Behavior Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7C5VKZ4O}},
  note         = {Machine review of arXiv:2509.08865}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Sophisticated evasion tactics in malicious Android applications, combined with their intricate behavioral semantics, enable attackers to conceal malicious logic within legitimate functions, underscoring the critical need for robust and in-depth analysis frameworks. However, traditional analysis techniques often fail to recover deeply hidden behaviors or provide human-readable justifications for their decisions. Inspired by advances in large language models (LLMs), we introduce TraceRAG, a retrieval-augmented generation (RAG) framework that bridges natural language queries and Java code to deliver explainable malware detection and analysis. First, TraceRAG generates summaries of method-level code snippets, which are indexed in a vector database. At query time, behavior-focused questions retrieve the most semantically relevant snippets for deeper inspection. Finally, based on the multi-turn analysis results, TraceRAG produces human-readable reports that present the identified malicious behaviors and their corresponding code implementations. Experimental results demonstrate that our method achieves 96\% malware detection accuracy and 83.81\% behavior identification accuracy based on updated VirusTotal (VT) scans and manual verification. Furthermore, expert evaluation confirms the practical utility of the reports generated by TraceRAG.

Figures

Figures reproduced from arXiv: 2509.08865 by Guangyu Zhang, Kun Sun, Peiyan Xiao, Shiyu Sun, Xixuan Wang, Yanhai Xiong.

Figure 1
Figure 1. Figure 1: System Architecture of TraceRAG vector database for each app, to ensure that no Java code from other apps is mixed in and to avoid collisions. We adopt the RAG paradigm for three primary reasons. First, an Android application inherently serves as a database, thus establishing a well-defined scope for building a vector database. In addition, the Java code within the app naturally consists of distinct code s… view at source ↗
Figure 2
Figure 2. Figure 2: Prompt and Cleaning Case for LLM-Cleanser [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Prompt and Description Case for LLM-Describer [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Prompt and Analysis Process of LLM-Analyzer [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Usefulness of Report Components also received positive ratings, with average scores of 3.69 and 3.53, respectively. Several participants mention that these sections highlight suspicious behaviors and reduce the amount of manual inspection needed. The Summary section shows more variation in ratings, with an average score of 3.23, suggesting that further refinement may improve focus and clarity [PITH_FULL_I… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Trident: Improving Malware Detection with LLMs and Behavioral Features

    cs.CR 2026-04 unverdicted novelty 6.0

    Trident combines static decision trees, LLM-generated behavioral rules from sandbox reports, and direct LLM analysis via majority voting to outperform static methods while resisting concept drift without retraining.

  2. LCC-LLM: Leveraging Code-Centric Large Language Models for Malware Attribution

    cs.CR 2026-05 unverdicted novelty 5.0

    LCC-LLM creates a code-centric dataset and RAG-based LLM framework that reaches 0.634 average semantic similarity on 43 malware tasks and 10/10 pass rate in real-world case studies.

Reference graph

Works this paper leans on

59 extracted references · 46 canonical work pages · cited by 2 Pith papers · 3 internal anchors

  1. [1]

    Annual number of mobile app downloads worldwide from 2016 to 2023,

    Statista, “Annual number of mobile app downloads worldwide from 2016 to 2023,” Tech. Rep., Jan 2025. [Online]. Available: https://www.statista.com/statistics/271644/worldwide-free-and-paid-m obile-app-store-downloads/

    work page 2016

  2. [2]

    It threat evolution in q3 2024. mobile statistics,

    A. Kivva, “It threat evolution in q3 2024. mobile statistics,” Securelist by Kaspersky, Tech. Rep., Nov 2024. [Online]. Available: https: //securelist.com/malware-report-q3-2024-mobile-statistics/114692/

    work page 2024

  3. [3]

    2024 global mobile threat report,

    Zimperium, “2024 global mobile threat report,” Tech. Rep., 2025. [Online]. Available: https://www.zimperium.com/resources/2024-globa l-mobile-threat-report/

    work page 2024

  4. [4]

    An efficient android malware detection system based on method-level behavioral semantic analysis,

    H. Zhang, S. Luo, Y . Zhang, and L. Pan, “An efficient android malware detection system based on method-level behavioral semantic analysis,” IEEE Access, vol. 7, pp. 69 246–69 256, 2019

    work page 2019

  5. [5]

    Evedroid: Event-aware android malware detection against model degrading for iot devices,

    T. Lei, Z. Qin, Z. Wang, Q. Li, and D. Ye, “Evedroid: Event-aware android malware detection against model degrading for iot devices,” IEEE Internet of Things Journal, vol. 6, no. 4, pp. 6668–6680, 2019

    work page 2019

  6. [6]

    Intelligent mobile malware detection using permission requests and api calls,

    M. Alazab, M. Alazab, A. Shalaginov, A. Mesleh, and A. Awajan, “Intelligent mobile malware detection using permission requests and api calls,”Future Generation Computer Systems, vol. 107, pp. 509–521, 2020

    work page 2020

  7. [7]

    Android malware detection method based on graph attention networks and deep fusion of multimodal features,

    S. Chen, B. Lang, H. Liu, Y . Chen, and Y . Song, “Android malware detection method based on graph attention networks and deep fusion of multimodal features,”Expert Systems with Applications, vol. 237, p. 121617, 2024

    work page 2024

  8. [8]

    A novel dynamic android malware detection system with ensemble learning,

    P. Feng, J. Ma, C. Sun, X. Xu, and Y . Ma, “A novel dynamic android malware detection system with ensemble learning,”IEEE Access, vol. 6, pp. 30 996–31 011, 2018

    work page 2018

  9. [9]

    Detecting malicious android applications based on the network packets generated,

    J. G. de la Puerta, I. Pastor-L ´opez, I. Porto, B. Sanz, and P. G. Bringas, “Detecting malicious android applications based on the network packets generated,”Neurocomputing, vol. 456, pp. 629–636, 2021

    work page 2021

  10. [10]

    Gsdroid: Graph signal based compact feature representation for android malware detection,

    R. Surendran, T. Thomas, and S. Emmanuel, “Gsdroid: Graph signal based compact feature representation for android malware detection,” Expert Systems with Applications, vol. 159, p. 113581, 2020

    work page 2020

  11. [11]

    Maldae: Detecting and explaining malware based on correlation and fusion of static and dynamic characteristics,

    W. Han, J. Xue, Y . Wang, L. Huang, Z. Kong, and L. Mao, “Maldae: Detecting and explaining malware based on correlation and fusion of static and dynamic characteristics,”computers & security, vol. 83, pp. 208–233, 2019

    work page 2019

  12. [12]

    You are what the permissions told me! android malware detection based on hybrid tactics,

    H. Wang, W. Zhang, and H. He, “You are what the permissions told me! android malware detection based on hybrid tactics,”Journal of Information Security and Applications, vol. 66, p. 103159, 2022

    work page 2022

  13. [13]

    Droiddetectmw: a hybrid intelligent model for android malware detec- tion,

    F. Taher, O. AlFandi, M. Al-kfairy, H. Al Hamadi, and S. Alrabaee, “Droiddetectmw: a hybrid intelligent model for android malware detec- tion,”Applied Sciences, vol. 13, no. 13, p. 7720, 2023

    work page 2023

  14. [14]

    Deepcatra: Learning flow-and graph-based behaviours for android malware detection,

    Y . Wu, J. Shi, P. Wang, D. Zeng, and C. Sun, “Deepcatra: Learning flow-and graph-based behaviours for android malware detection,”IET Information Security, vol. 17, no. 1, pp. 118–130, 2023

    work page 2023

  15. [15]

    Hgdetector: A hybrid android malware detection method using network traffic and function call graph,

    J. Feng, L. Shen, Z. Chen, Y . Lei, and H. Li, “Hgdetector: A hybrid android malware detection method using network traffic and function call graph,”Alexandria Engineering Journal, vol. 114, pp. 30–45, 2025

    work page 2025

  16. [16]

    Call graph soundness in android static analysis,

    J. Samhi, R. Just, T. F. Bissyand ´e, M. D. Ernst, and J. Klein, “Call graph soundness in android static analysis,” inProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 945–957

    work page 2024

  17. [17]

    Colluding apps: Tomorrow’s mobile malware threat,

    A. M. Memon and A. Anwar, “Colluding apps: Tomorrow’s mobile malware threat,”IEEE Security & Privacy, vol. 13, no. 6, pp. 77–81, 2015

    work page 2015

  18. [18]

    A systematic literature review of android malware detection using static analysis,

    Y . Pan, X. Ge, C. Fang, and Y . Fan, “A systematic literature review of android malware detection using static analysis,”Ieee Access, vol. 8, pp. 116 363–116 379, 2020

    work page 2020

  19. [19]

    Static malware detection and attribution in android byte- code through an end-to-end deep system,

    M. Amin, T. A. Tanveer, M. Tehseen, M. Khan, F. A. Khan, and S. Anwar, “Static malware detection and attribution in android byte- code through an end-to-end deep system,”Future generation computer systems, vol. 102, pp. 112–126, 2020

    work page 2020

  20. [20]

    Dynamic malware analysis in the modern era—a state of the art survey,

    O. Or-Meir, N. Nissim, Y . Elovici, and L. Rokach, “Dynamic malware analysis in the modern era—a state of the art survey,”ACM Computing Surveys (CSUR), vol. 52, no. 5, pp. 1–48, 2019

    work page 2019

  21. [21]

    A novel deep framework for dynamic malware detection based on api sequence intrinsic features,

    C. Li, Q. Lv, N. Li, Y . Wang, D. Sun, and Y . Qiao, “A novel deep framework for dynamic malware detection based on api sequence intrinsic features,”Computers & Security, vol. 116, p. 102686, 2022

    work page 2022

  22. [22]

    A survey on malware detection using data mining techniques,

    Y . Ye, T. Li, D. Adjeroh, and S. S. Iyengar, “A survey on malware detection using data mining techniques,”ACM Computing Surveys (CSUR), vol. 50, no. 3, pp. 1–40, 2017

    work page 2017

  23. [23]

    Detecting cryptomining malware: a deep learning approach for static and dynamic analysis,

    H. Darabian, S. Homayounoot, A. Dehghantanha, S. Hashemi, H. Karim- ipour, R. M. Parizi, and K.-K. R. Choo, “Detecting cryptomining malware: a deep learning approach for static and dynamic analysis,” Journal of Grid Computing, vol. 18, pp. 293–303, 2020

    work page 2020

  24. [24]

    Two-stage hybrid malware detection using deep learning,

    S. Baek, J. Jeon, B. Jeong, and Y .-S. Jeong, “Two-stage hybrid malware detection using deep learning,”Human-centric Computing and Informa- tion Sciences, vol. 11, no. 27, pp. 10–22 967, 2021

    work page 2021

  25. [25]

    Introducing chatgpt,

    OpenAI, “Introducing chatgpt,” Tech. Rep., 2022. [Online]. Available: https://openai.com/index/chatgpt/

    work page 2022

  26. [26]

    Llama: Open and efficient foundation language models,

    H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozi `ere, N. Goyal, E. Hambro, F. Azharet al., “Llama: Open and efficient foundation language models,”arXiv preprint arXiv:2302.13971, 2023

    Pith/arXiv arXiv 2023

  27. [27]

    Emergent abilities of large language models,

    J. Wei, Y . Tay, R. Bommasani, C. Raffel, B. Zoph, S. Borgeaud, D. Yogatama, M. Bosma, D. Zhou, D. Metzleret al., “Emergent abilities of large language models,”arXiv preprint arXiv:2206.07682, 2022

    Pith/arXiv arXiv 2022

  28. [28]

    From text to transformation: A comprehensive review of large language models’ versatility,

    P. Kaur, G. S. Kashyap, A. Kumar, M. T. Nafis, S. Kumar, and V . Shokeen, “From text to transformation: A comprehensive review of large language models’ versatility,”arXiv preprint arXiv:2402.16142, 2024

    Pith/arXiv arXiv 2024

  29. [29]

    Apppoet: Large language model based android malware detection via multi-view prompt engineering,

    W. Zhao, J. Wu, and Z. Meng, “Apppoet: Large language model based android malware detection via multi-view prompt engineering,”Expert Systems with Applications, vol. 262, p. 125546, 2025

    work page 2025

  30. [30]

    Lamd: Context- driven android malware detection and classification with llms,

    X. Qian, X. Zheng, Y . He, S. Yang, and L. Cavallaro, “Lamd: Context- driven android malware detection and classification with llms,”arXiv preprint arXiv:2502.13055, 2025

    Pith/arXiv arXiv 2025

  31. [31]

    Enhancing Android Malware Detection: The Influence of ChatGPT on Decision-centric Task

    Y . Li, S. Fang, T. Zhang, and H. Cai, “Enhancing android malware detection: The influence of chatgpt on decision-centric task,”arXiv preprint arXiv:2410.04352, 2024

    work page internal anchor Pith review Pith/arXiv arXiv 2024

  32. [32]

    Enhancing Android Malware Detection with Retrieval-Augmented Generation

    D. R. Arikkat, S. Nicolazzo, A. Noceraet al., “Enhancing android malware detection with retrieval-augmented generation,”arXiv preprint arXiv:2506.22750, 2025

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  33. [33]

    Ex- ploring large language models for semantic analysis and categorization of android malware,

    B. J. Walton, M. E. Khatun, J. M. Ghawaly, and A. Ali-Gombe, “Ex- ploring large language models for semantic analysis and categorization of android malware,” in2024 Annual Computer Security Applications Conference Workshops (ACSAC Workshops). IEEE, 2024, pp. 248–254

    work page 2024

  34. [34]

    Assessing llms in malicious code deobfuscation of real-world malware campaigns,

    C. Patsakis, F. Casino, and N. Lykousas, “Assessing llms in malicious code deobfuscation of real-world malware campaigns,”Expert Systems with Applications, vol. 256, p. 124912, 2024

    2024

  35. [35]

    Siren’s song in the ai ocean: a survey on hal- lucination in large language models,

    Y . Zhang, Y . Li, L. Cui, D. Cai, L. Liu, T. Fu, X. Huang, E. Zhao, Y . Zhang, Y . Chenet al., “Siren’s song in the ai ocean: a survey on hal- lucination in large language models,”arXiv preprint arXiv:2309.01219, 2023

    Pith/arXiv arXiv 2023

  36. [36]

    Androzoo: Collecting millions of android apps for the research community,

    K. Allix, T. F. Bissyand ´e, J. Klein, and Y . Le Traon, “Androzoo: Collecting millions of android apps for the research community,” in Proceedings of the 13th international conference on mining software repositories, 2016, pp. 468–471

    work page 2016

  37. [37]

    Large language models for code analysis: Do{llms}really do their job?

    C. Fang, N. Miao, S. Srivastav, J. Liu, R. Zhang, R. Fang, R. Tsang, N. Nazari, H. Wang, H. Homayounet al., “Large language models for code analysis: Do{llms}really do their job?” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 829–846

    work page 2024

  38. [38]

    Using an llm to help with code understanding,

    D. Nam, A. Macvean, V . Hellendoorn, B. Vasilescu, and B. Myers, “Using an llm to help with code understanding,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–13

    2024

  39. [39]

    Llm4decompile: Decom- piling binary code with large language models,

    H. Tan, Q. Luo, J. Li, and Y . Zhang, “Llm4decompile: Decom- piling binary code with large language models,”arXiv preprint arXiv:2403.05286, 2024

    Pith/arXiv arXiv 2024

  40. [40]

    Disassembling obfuscated executables with llm,

    H. Rong, Y . Duan, H. Zhang, X. Wang, H. Chen, S. Duan, and S. Wang, “Disassembling obfuscated executables with llm,”arXiv preprint arXiv:2407.08924, 2024

    Pith/arXiv arXiv 2024

  41. [41]

    Automatic semantic augmentation of language model prompts (for code summarization),

    T. Ahmed, K. S. Pai, P. Devanbu, and E. Barr, “Automatic semantic augmentation of language model prompts (for code summarization),” in Proceedings of the IEEE/ACM 46th international conference on software engineering, 2024, pp. 1–13

    work page 2024

  42. [42]

    Few-shot training llms for project-specific code-summarization,

    T. Ahmed and P. Devanbu, “Few-shot training llms for project-specific code-summarization,” inProceedings of the 37th IEEE/ACM interna- tional conference on automated software engineering, 2022, pp. 1–5

    work page 2022

  43. [43]

    Malsight: Exploring malicious source code and benign pseudocode for iterative binary malware summarization,

    H. Lu, H. Peng, G. Nan, J. Cui, C. Wang, W. Jin, S. Wang, S. Pan, and X. Tao, “Malsight: Exploring malicious source code and benign pseudocode for iterative binary malware summarization,”arXiv preprint arXiv:2406.18379, 2024

    Pith/arXiv arXiv 2024

  44. [44]

    Exploring llms for malware detection: Review, framework design, and countermeasure approaches,

    J. Al-Karaki, M. A.-Z. Khan, and M. Omar, “Exploring llms for malware detection: Review, framework design, and countermeasure approaches,” arXiv preprint arXiv:2409.07587, 2024

    Pith/arXiv arXiv 2024

  45. [45]

    Large language model (llm) for software security: Code analysis, malware analysis, reverse engineering,

    H. Jelodar, S. Bai, P. Hamedi, H. Mohammadian, R. Razavi-Far, and A. Ghorbani, “Large language model (llm) for software security: Code analysis, malware analysis, reverse engineering,”arXiv preprint arXiv:2504.07137, 2025

    Pith/arXiv arXiv 2025

  46. [46]

    Malbert: Malware detection using bidirectional encoder representations from transformers,

    A. Rahali and M. A. Akhloufi, “Malbert: Malware detection using bidirectional encoder representations from transformers,” in2021 IEEE international conference on systems, man, and cybernetics (SMC). IEEE, 2021, pp. 3226–3231

    work page 2021

  47. [47]

    Liredroid: Llm-enhanced test case generation for static sensitive be- havior replication,

    Y . Wang, M. Fan, X. Zhang, J. Shi, Z. Qiu, H. Wang, and T. Liu, “Liredroid: Llm-enhanced test case generation for static sensitive be- havior replication,” inProceedings of the 15th Asia-Pacific Symposium on Internetware, 2024, pp. 81–84

    work page 2024

  48. [48]

    Chatphishdetector: Detecting phishing sites using large language models,

    T. Koide, H. Nakano, and D. Chiba, “Chatphishdetector: Detecting phishing sites using large language models,”IEEE Access, 2024

    work page 2024

  49. [49]

    Gleam: Gan and llm for evasive adver- sarial malware,

    D. Devadiga, G. Jin, B. Potdar, H. Koo, A. Han, A. Shringi, A. Singh, K. Chaudhari, and S. Kumar, “Gleam: Gan and llm for evasive adver- sarial malware,” in2023 14th International Conference on Information and Communication Technology Convergence (ICTC). IEEE, 2023, pp. 53–58

    work page 2023

  50. [50]

    Efficient ransomware detection via portable executable file image analysis by llama-7b,

    X. Li, T. Zhu, and W. Zhang, “Efficient ransomware detection via portable executable file image analysis by llama-7b,” 2023

    work page 2023

  51. [51]

    Unmasking the Shadows: Pinpoint the Implementations of Anti-Dynamic Analysis Techniques in Malware Using LLM

    H. Wang, N. Luo, and P. LIu, “Unmasking the shadows: Pinpoint the implementations of anti-dynamic analysis techniques in malware using llm,”arXiv preprint arXiv:2411.05982, 2024

    work page internal anchor Pith review Pith/arXiv arXiv 2024

  52. [52]

    Srdc: Semantics-based ransomware detection and classification with llm-assisted pre-training,

    C. Zhou, Y . Liu, W. Meng, S. Tao, W. Tian, F. Yao, X. Li, T. Han, B. Chen, and H. Yang, “Srdc: Semantics-based ransomware detection and classification with llm-assisted pre-training,” inProceedings of the AAAI Conference on Artificial Intelligence, vol. 39, no. 27, 2025, pp. 28 566–28 574

    work page 2025

  53. [53]

    Malicious code detection using llm,

    A. A. Hossain, M. K. PK, J. Zhang, and F. Amsaad, “Malicious code detection using llm,” inNAECON 2024-IEEE National Aerospace and Electronics Conference. IEEE, 2024, pp. 414–416

    work page 2024

  54. [54]

    Finetuning large language models for vulnerability detection,

    A. Shestov, R. Levichev, R. Mussabayev, E. Maslov, P. Zadorozhny, A. Cheshkov, R. Mussabayev, A. Toleu, G. Tolegen, and A. Krasso- vitskiy, “Finetuning large language models for vulnerability detection,” IEEE Access, 2025

    work page 2025

  55. [55]

    Maltracker: A fine-grained npm malware tracker copiloted by llm-enhanced dataset,

    Z. Yu, M. Wen, X. Guo, and H. Jin, “Maltracker: A fine-grained npm malware tracker copiloted by llm-enhanced dataset,” inProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 1759–1771

    work page 2024

  56. [56]

    Spiderscan: Practical detection of malicious npm packages based on graph-based behavior modeling and matching,

    Y . Huang, R. Wang, W. Zheng, Z. Zhou, S. Wu, S. Ke, B. Chen, S. Gao, and X. Peng, “Spiderscan: Practical detection of malicious npm packages based on graph-based behavior modeling and matching,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 1146–1158

    work page 2024

  57. [57]

    Retrieval- augmented generation for knowledge-intensive nlp tasks,

    P. Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. K ¨uttler, M. Lewis, W.-t. Yih, T. Rockt ¨aschelet al., “Retrieval- augmented generation for knowledge-intensive nlp tasks,”Advances in neural information processing systems, vol. 33, pp. 9459–9474, 2020

    2020

  58. [58]

    Openai o3-mini,

    OpenAI, “Openai o3-mini,” Tech. Rep., 2025. [Online]. Available: https://openai.com/index/openai-o3-mini/

    work page 2025

  59. [59]

    New and improved embedding model,

    ——, “New and improved embedding model,” Tech. Rep., 2022. [Online]. Available: https://openai.com/index/new-and-improved-emb edding-model/

    work page 2022