---
title: 'TraceRAG: Explainable Android Malware Detection'
url: https://www.emergentmind.com/topics/tracerag
type: topic
---

# TraceRAG: Explainable Android Malware Detection

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 [2509.08865]. 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 [2509.08865]. 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 [2509.08865].

## 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 [2509.08865]. 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 [2509.08865].

The framework operates over decompiled Android applications. In the reported evaluation, APKs were obtained from AndroZoo, decompiled into Java, and analyzed at method granularity [2509.08865]. 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 [2509.08865].

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 [2509.08865].

## 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 [2509.08865]. 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 [2509.08865]. Each method is extracted into its own file, while imported packages and class-level variable declarations are preserved as context [2509.08865]. 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 [2509.08865].

The extracted methods are then passed through **LLM-Cleanser**, which removes dead code, unreachable statements, and opaque obfuscation artifacts [2509.08865]. 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 [2509.08865]. Each record stored in the vector database contains the processed code snippet, the generated description, the method name, and the class name [2509.08865].

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 [2509.08865]. For each query, it retrieves the top-5 most relevant snippets, filters them with **Relevance-Reviewer**, and analyzes the surviving candidates with **LLM-Analyzer** [2509.08865]. 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 [2509.08865]. **Query-Reviewer** determines whether another retrieval step is needed or whether the current analysis can terminate [2509.08865]. The workflow is implemented with LangGraph [2509.08865].

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 [2509.08865]. The final report contains four sections: **App Info**, **Overall Summary**, **Detailed Analyses**, and **Conclusion** [2509.08865].

## 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 [2509.08865]. The embedding model is OpenAI `text-embedding-ada-002`, and a separate vector database is created for each app to avoid cross-app collisions [2509.08865]. 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 [2509.08865].

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 [2509.08865]. 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 [2509.08865]. 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 [2509.08865].

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 [2509.08865]. 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 [2509.08865]. This iterative querying continues until sufficient evidence has been accumulated [2509.08865]. The result is not merely a retrieved snippet list, but a reconstructed path linking suspicious behavior to concrete implementations across methods and classes [2509.08865].

The paper does not provide explicit equations, objective functions, or pseudocode for the retrieval score or the analyzer’s decision policy [2509.08865]. 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 [2509.08865]. 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 [2509.08865]. They later refined the benign/malicious ground truth using updated VirusTotal scans, manual verification, source-code inspection of suspicious behaviors, and expert consultation [2509.08865].

| 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 [2509.08865]. 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 [2509.08865]. Under the refined ground truth, performance improved to 96.00% accuracy, 95.89% precision, 98.59% recall, and 97.22% F1 [2509.08865].

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 [2509.08865]. Monetary Fraud and Financial Abuse was the hardest category, with 75.71% accuracy, 68.75% precision, 75.86% recall, and 72.13% F1 [2509.08865]. 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 [2509.08865].

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 [2509.08865]. 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 [2509.08865]. The framework’s outputs are organized behavior by behavior and implementation by implementation, rather than as a single malware label or an unstructured description [2509.08865].

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)` [2509.08865]. The analyzer then issues follow-up retrieval queries, traces related methods, and reconstructs a deeper suspicious behavior path [2509.08865]. 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 [2509.08865]. 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 [2509.08865].

The expert evaluation used 42 reports, received 31 pieces of feedback, and covered 24 APKs selected at random [2509.08865]. 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 [2509.08865]. 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 [2509.08865]. On missed behaviors, 73.33% of 30 responses said no major behavior types were missed, 6.67% said yes, and 20% were unsure [2509.08865]. 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 [2509.08865].

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 [2509.08865]. The refined evaluation found one actual malicious sample that TraceRAG failed to detect [2509.08865].

## 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 [2509.08865]. 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 [2509.08865]. The no-preprocessing variant also produced shallower reports and weaker call-chain reconstruction [2509.08865]. Removing multi-turn follow-up similarly reduced the analysis to superficial summaries and prevented call-chain recovery [2509.08865].

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 [2509.08865]. 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 [2509.08865].

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 [2406.11460]. “RAGTrace” is an interactive evaluation system for inspecting retrieval-generation dynamics, source attribution, and failure modes in RAG pipelines [2508.06056]. “DocTrace” extends long-document QA with query-triggered knowledge organization, document-structure-aware retrieval, hypergraph working memory, and experience memory [2606.10921]. “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 [2505.13258]. By contrast, TRACE for LLM-agent trajectories is adjacent monitoring work rather than a system explicitly called TraceRAG [2606.07054].

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 [2406.11460]. 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 [2509.08865].

Source: https://www.emergentmind.com/topics/tracerag