TraceRAG: Explainable Android Malware Detection
- TraceRAG is a retrieval-augmented generation framework that links natural language queries to method-level Java code for explainable Android malware behavior analysis.
- Its multi-stage pipeline decompiles APKs, cleans code, summarizes functionality, and reconstructs call chains to generate interpretable analyst reports.
- Evaluations show up to 96% detection accuracy and effective behavior identification, highlighting its potential for in-depth malware analysis.
Searching arXiv for TraceRAG and adjacent work to ground the article. Search query: "TraceRAG" TraceRAG is a retrieval-augmented generation framework for explainable Android malware detection and behavior analysis that bridges natural language queries and Java code (Zhang et al., 10 Sep 2025). It is designed not only to classify an Android application as malicious or benign, but also to identify malicious behaviors, locate the exact Java code snippets responsible, trace inter-method call chains, and generate human-readable reports grounded in code evidence (Zhang et al., 10 Sep 2025). The framework is motivated by the observation that malicious Android logic is often concealed inside legitimate functionality and further obscured by obfuscation, sandbox evasion, encryption, dynamic loading, reflection, virtual dispatch, and event-driven execution, while traditional static, dynamic, and hybrid methods often fail either to recover deeply hidden behaviors or to provide interpretable justifications (Zhang et al., 10 Sep 2025).
1. Scope, motivation, and analytical target
TraceRAG addresses explainable Android malware detection in a setting where raw Java code is not naturally retrievable from natural-language analyst questions, creating a semantic gap between security queries and program text (Zhang et al., 10 Sep 2025). The framework therefore targets behavior-oriented analysis rather than only feature-based classification. Its intended questions include whether an app accesses sensitive data, captures screenshots or screen recordings, connects to suspicious external URLs, performs background downloads, hides endpoints with obfuscation or encryption, sends premium SMS or makes calls without consent, requests elevated privileges, supports remote command execution, or uses dynamic code loading and native-code exploitation (Zhang et al., 10 Sep 2025).
The framework operates over decompiled Android applications. In the reported evaluation, APKs were obtained from AndroZoo, decompiled into Java, and analyzed at method granularity (Zhang et al., 10 Sep 2025). The emphasis on method-level behavior reflects the paper’s claim that malware behavior is often not obvious from isolated snippets and may become suspicious only when linked across invocation chains (Zhang et al., 10 Sep 2025).
This focus distinguishes TraceRAG from black-box malware detection pipelines. The system is explicitly intended to answer not only whether an app is malicious, but what behavior is present, where it is implemented, and how the relevant code path realizes it (Zhang et al., 10 Sep 2025).
2. System architecture and end-to-end workflow
TraceRAG begins with APK reverse engineering and proceeds through code extraction, cleaning, summarization, indexing, retrieval, multi-turn analysis, and report generation (Zhang et al., 10 Sep 2025). The paper describes the following core pipeline.
| Stage | Function |
|---|---|
| Reverse engineering | Decompile APK with JADX |
| Snippet construction | Split Java into method-level snippets with preserved context |
| Cleaning | Remove dead code, unreachable branches, and irrelevant obfuscation artifacts |
| Description generation | Produce security-oriented natural-language summaries |
| Indexing | Store snippets, descriptions, method names, and class names in a per-app vector database |
| Retrieval and analysis | Answer behavior-focused queries, follow call chains, and synthesize evidence |
| Reporting | Generate code reports, query reports, and a final structured report |
At preprocessing time, TraceRAG decompiles an APK with JADX and parses Java source files using the JavaLang library in Python (Zhang et al., 10 Sep 2025). Each method is extracted into its own file, while imported packages and class-level variable declarations are preserved as context (Zhang et al., 10 Sep 2025). This design is motivated by the paper’s observation that some Java files are extremely long, even “millions of tokens,” making direct long-context analysis impractical and increasing hallucination risk (Zhang et al., 10 Sep 2025).
The extracted methods are then passed through LLM-Cleanser, which removes dead code, unreachable statements, and opaque obfuscation artifacts (Zhang et al., 10 Sep 2025). The cleaned methods are summarized by LLM-Describer, which produces a description of the code’s core functionality, inputs and outputs, and any potential malicious intent or suspicious behavior (Zhang et al., 10 Sep 2025). Each record stored in the vector database contains the processed code snippet, the generated description, the method name, and the class name (Zhang et al., 10 Sep 2025).
At query time, TraceRAG runs a fixed set of 11 malicious-behavior queries spanning three categories: Information Theft and Abuse; Monetary Fraud and Financial Abuse; and Privilege Abuse and System Exploitation (Zhang et al., 10 Sep 2025). For each query, it retrieves the top-5 most relevant snippets, filters them with Relevance-Reviewer, and analyzes the surviving candidates with LLM-Analyzer (Zhang et al., 10 Sep 2025). If a retrieved method invokes another method whose implementation is required, the analyzer emits a follow-up query containing the method name, class name, and input-parameter information; retrieval is then repeated with metadata filters, and Collision-Reviewer resolves naming ambiguity when multiple matches exist (Zhang et al., 10 Sep 2025). Query-Reviewer determines whether another retrieval step is needed or whether the current analysis can terminate (Zhang et al., 10 Sep 2025). The workflow is implemented with LangGraph (Zhang et al., 10 Sep 2025).
The reporting stack is hierarchical. LLM-Organizer produces a code report for an individual snippet or call-chain analysis, a query report for all code reports associated with one malicious-behavior query, and a final report across all 11 queries (Zhang et al., 10 Sep 2025). The final report contains four sections: App Info, Overall Summary, Detailed Analyses, and Conclusion (Zhang et al., 10 Sep 2025).
3. Retrieval design, code summarization, and multi-turn call-chain tracing
The retrieval unit in TraceRAG is a method-level code snippet augmented with an LLM-generated natural-language description and metadata (Zhang et al., 10 Sep 2025). The embedding model is OpenAI text-embedding-ada-002, and a separate vector database is created for each app to avoid cross-app collisions (Zhang et al., 10 Sep 2025). This per-app organization is a practical constraint: retrieval is not over a corpus of many applications, but over one app’s codebase at analysis time (Zhang et al., 10 Sep 2025).
The use of LLM-generated descriptions is central. The paper reports that indexing raw code alone fails to bridge the gap between behavior-focused queries and Java methods, whereas summaries that encode functionality, suspicious intent, and behavior semantics enable successful retrieval (Zhang et al., 10 Sep 2025). In one ablation, removing code descriptions caused retrieval to fail to return valid top-5 matches in the com.bp.statis.bloodsugar case, making downstream analysis impossible (Zhang et al., 10 Sep 2025). This directly supports the framework’s claim that semantic description generation is the mechanism by which natural-language analyst questions become searchable over source code (Zhang et al., 10 Sep 2025).
The multi-turn analyzer performs a limited form of call-chain-guided evidence aggregation. It first inspects a retrieved snippet, identifies its core behavior, and reports the fully qualified code path (Zhang et al., 10 Sep 2025). If the snippet is insufficient to determine whether the behavior is malicious, the analyzer issues a follow-up query for the implementation of the callee, such as a request for a named method in a named class with specified input parameters (Zhang et al., 10 Sep 2025). This iterative querying continues until sufficient evidence has been accumulated (Zhang et al., 10 Sep 2025). The result is not merely a retrieved snippet list, but a reconstructed path linking suspicious behavior to concrete implementations across methods and classes (Zhang et al., 10 Sep 2025).
The paper does not provide explicit equations, objective functions, or pseudocode for the retrieval score or the analyzer’s decision policy (Zhang et al., 10 Sep 2025). Instead, the system is described procedurally. This suggests that TraceRAG should be understood as an LLM-orchestrated analysis framework rather than a formally optimized retrieval model.
4. Evaluation protocol and empirical results
The evaluation used 100 Android apps sampled from AndroZoo: 30 benign and 70 malicious according to AndroZoo labels, after an initial download of 1,000 apps spanning 2010 to 2025 and scanned on VirusTotal by more than ten security scanners (Zhang et al., 10 Sep 2025). The authors chose the 70/30 ratio to expose TraceRAG to more malicious behaviors because the goal was behavior analysis rather than only binary classification (Zhang et al., 10 Sep 2025). They later refined the benign/malicious ground truth using updated VirusTotal scans, manual verification, source-code inspection of suspicious behaviors, and expert consultation (Zhang et al., 10 Sep 2025).
| Evaluation | Result |
|---|---|
| Malware detection with AndroZoo labels | 90.00% accuracy, 87.50% precision, 100.00% recall, 93.33% F1 |
| Malware detection with updated VT + manual verification | 96.00% accuracy, 95.89% precision, 98.59% recall, 97.22% F1 |
| Behavior identification | 83.81% accuracy, 84.89% precision, 86.35% recall, 85.46% F1 |
The paper’s headline result is 96% malware detection accuracy under updated VirusTotal scans and manual verification, together with 83.81% behavior identification accuracy (Zhang et al., 10 Sep 2025). Under the original AndroZoo labels, TraceRAG achieved 90.00% accuracy, 87.50% precision, 100.00% recall, and 93.33% F1, correctly identifying all 70 malicious APKs but mislabeling 10 benign samples as malware (Zhang et al., 10 Sep 2025). Under the refined ground truth, performance improved to 96.00% accuracy, 95.89% precision, 98.59% recall, and 97.22% F1 (Zhang et al., 10 Sep 2025).
Per-category behavior results show that Information Theft and Abuse was the strongest category, with 88.57% accuracy, 98.41% precision, 89.86% recall, and 93.94% F1, while Privilege Abuse and System Exploitation achieved 87.14% accuracy, 87.50% precision, 93.33% recall, and 90.32% F1 (Zhang et al., 10 Sep 2025). Monetary Fraud and Financial Abuse was the hardest category, with 75.71% accuracy, 68.75% precision, 75.86% recall, and 72.13% F1 (Zhang et al., 10 Sep 2025). The paper attributes this difficulty to the need for user-consent context, deceptive UI interpretation, and logic distributed across modules and hidden by dynamic mechanisms (Zhang et al., 10 Sep 2025).
TraceRAG was also compared with VirusTotal reporting tools at the level of report capability and coverage. Tencent HABO and Zenbox android were reported as providing behavior but not source code or explicit linkage; VirusTotal Droidy and VirusTotal R2DBox were reported as providing source code but not behavior or linkage; TraceRAG was reported as providing behavior, source code, and their linkage, with 100% report coverage over the evaluated 100 APKs (Zhang et al., 10 Sep 2025). This comparison should be read as a capability comparison rather than a controlled accuracy benchmark.
5. Explainability, case studies, and expert assessment
TraceRAG’s explainability derives from its ability to connect suspicious behavior to exact Java methods, classes, and call chains, then present the result in analyst-readable reports (Zhang et al., 10 Sep 2025). The framework’s outputs are organized behavior by behavior and implementation by implementation, rather than as a single malware label or an unstructured description (Zhang et al., 10 Sep 2025).
The paper includes several case studies. In the com.bp.statis.bloodsugar sample, LLM-Cleanser removes unreachable and opaque code while preserving core logic, and LLM-Describer identifies string permutation obfuscation in the method p(String) (Zhang et al., 10 Sep 2025). The analyzer then issues follow-up retrieval queries, traces related methods, and reconstructs a deeper suspicious behavior path (Zhang et al., 10 Sep 2025). In another case, com.smartsm5.smart_5_293, TraceRAG reported that run() accessed an external URL, silently downloaded an image, and stored it under DCIM/Camera without user notification; the paper presents this as an instance in which updated VirusTotal scans later reclassified the sample as malicious (Zhang et al., 10 Sep 2025). In com.dijlah.sh_khotaba, the system reported unauthorized financial operations involving silent SMS sending and phone calls without user confirmation, and the authors state that manual inspection confirmed silent SMS-sending functions and permissions to modify message content and recipient (Zhang et al., 10 Sep 2025).
The expert evaluation used 42 reports, received 31 pieces of feedback, and covered 24 APKs selected at random (Zhang et al., 10 Sep 2025). Average usefulness scores were reported as 4.83 for App Info, 3.69 for Detailed Analyses, 3.53 for Overall Summary, and 3.23 for the concluding summary section (Zhang et al., 10 Sep 2025). On behavioral alignment, 65.52% of 29 responses said the flagged behaviors align with the evaluator’s own analysis, 20.69% disagreed, and 13.79% were unsure (Zhang et al., 10 Sep 2025). On missed behaviors, 73.33% of 30 responses said no major behavior types were missed, 6.67% said yes, and 20% were unsure (Zhang et al., 10 Sep 2025). On whether flagged methods and classes were helpful, 34.48% said all were useful, 34.48% said most were useful but some were misleading, 6.9% said only a few were useful, and 6.9% said most were not useful (Zhang et al., 10 Sep 2025).
These results indicate practical utility, but the paper also documents limitations. Three cases were treated as genuine false positives after manual inspection because ambiguous URL-related behavior was conservatively interpreted as malicious without access to the content behind the external URL (Zhang et al., 10 Sep 2025). The refined evaluation found one actual malicious sample that TraceRAG failed to detect (Zhang et al., 10 Sep 2025).
6. Ablations, limitations, and relation to adjacent trace-oriented RAG work
The ablation study attributes TraceRAG’s effectiveness to three design choices: method-level splitting and cleaning, semantic code descriptions, and multi-turn interaction (Zhang et al., 10 Sep 2025). Without splitting and cleaning, only 2 out of 7 malicious-behavior queries were correctly returned in the com.bp.statis.bloodsugar case, whereas the full TraceRAG pipeline returned 7 out of 7 (Zhang et al., 10 Sep 2025). The no-preprocessing variant also produced shallower reports and weaker call-chain reconstruction (Zhang et al., 10 Sep 2025). Removing multi-turn follow-up similarly reduced the analysis to superficial summaries and prevented call-chain recovery (Zhang et al., 10 Sep 2025).
The framework’s limitations are explicit. Cleaning can remove legitimately executed logic together with dead or obfuscated code, Java-only analysis cannot fully inspect native libraries or dynamically loaded components, the approach remains subject to LLM hallucination risk, and the system is expensive: generating reports for 100 apps consumed over 100 million total tokens and cost approximately $600 (Zhang et al., 10 Sep 2025). Future work proposed in the paper includes adaptive cleaning strategies, evaluation with more advanced LLMs, and extension to native libraries, dynamically loaded components, and end-to-end coverage of all execution paths (Zhang et al., 10 Sep 2025).
Within the broader literature, TraceRAG can be situated among traceability-oriented or trace-like RAG systems, although its application domain is Android malware analysis rather than question answering. “TRACE the Evidence” constructs knowledge-grounded reasoning chains from retrieved documents for multi-hop QA, using triples and reasoning-chain construction to distill evidence before answer generation (Fang et al., 2024). “RAGTrace” is an interactive evaluation system for inspecting retrieval-generation dynamics, source attribution, and failure modes in RAG pipelines (Cheng et al., 8 Aug 2025). “DocTrace” extends long-document QA with query-triggered knowledge organization, document-structure-aware retrieval, hypergraph working memory, and experience memory (Zai et al., 9 Jun 2026). “ARENA” makes generator-side evidence use explicit by outputting selected reference indices, a reasoning trace, and a final answer, and trains that behavior with reinforcement learning (Ren et al., 19 May 2025). By contrast, TRACE for LLM-agent trajectories is adjacent monitoring work rather than a system explicitly called TraceRAG (Mittapalli et al., 5 Jun 2026).
This comparison suggests a broader pattern: trace-oriented RAG research increasingly treats retrieval not as one-shot document fetching, but as a mechanism for constructing inspectable evidence paths, whether across documents, agent trajectories, long-document structure, or source code (Fang et al., 2024). TraceRAG instantiates that pattern in malware analysis by tying natural-language behavioral questions to method-level Java retrieval, iterative call-chain inspection, and human-readable code-grounded reports (Zhang et al., 10 Sep 2025).
