Multi-View Decompilation for LLM-Based Malware Classification Bercan Efe Independent Researcher [email protected]
Vyas Raina SPARK [email protected]
§ github.com/B3f3/Compiled-C-Malware
arXiv:2606.20436v1 [cs.CR] 18 Jun 2026
Abstract Malware analysts often inspect compiled binaries through decompiled pseudo-C, when source code is unavailable. Recent work suggests that large language models (LLMs) can assist this process by classifying decompiled code as benign or malicious, but existing pipelines typically rely on a single decompiler view. We argue that this assumption is fragile: decompilers are lossy heuristic tools, and different decompilers can expose different artefacts of the same binary. We curate a benchmark of benign utilities and malicious programs spanning a range of threat behaviors. Each sample is compiled and decompiled with both Ghidra and RetDec, yielding matched pseudo-C views. Across a range of LLMs from major model families, we find that providing both decompiler views improves malicious-class F1 , mainly by increasing recall on malicious samples. Agreement analyses further show that Ghidra and RetDec make partially different errors, supporting the view that decompiler outputs provide complementary evidence. Our results suggest that multi-decompiler prompting is a simple, training-free way to improve LLM-based malware triage in practical settings.
1
Introduction
Software is often distributed as compiled binaries rather than source code. This is common across commercial software, games, security tools, and enterprise applications, where source code is withheld to protect intellectual property or simplify deployment. However, binaries are also harder to audit: a program may appear to provide benign functionality while also containing malicious behavior such as credential theft, process injection, file encryption, or command-and-control communication. At the scale faced by malware triage teams, manually inspecting every suspicious binary is infeasible. In the absence of source code, analysts typically rely on decompilers (National Security Agency,
2019; Hex-Rays, 2024). A decompiler attempts to recover an approximate, human-readable C-like representation of a program from a compiled binary (Cifuentes, 1994; Cao et al., 2024). Reverse engineers then inspect this decompiled pseudo-code to reason about the program’s behavior and decide whether it is benign or malicious. Although this workflow is standard, the inspection stage remains a costly human bottleneck: it requires specialist expertise, is time-consuming, and does not scale easily. Figure 1 illustrates this conventional workflow and contrasts it with the LLM-based single-view and multi-view pipelines studied in this paper. The code-understanding capabilities of large language models (LLMs) make them a natural candidate for automating part of this inspection process (Zhang et al., 2025; Xu et al., 2024). Recent work suggests that LLMs can interpret decompiled code and reason about program behavior (Pordanesh and Tan, 2024; Fang et al., 2024; Manuel et al., 2024). A straightforward pipeline is therefore to decompile a binary, pass the pseudo-code to an LLM, and ask the model to classify the sample as benign or malicious. Such a system could support firstpass triage, reduce analyst workload, and surface suspicious samples for human review. However, most LLM-based decompilation pipelines rely on a single decompiler, often treating its output as the canonical representation of the program (Chawla and Prasad, 2026; Manuel et al., 2024). This assumption is fragile. Decompilation is a lossy and heuristic process: different tools make different choices about control-flow recovery, variable naming, type inference, and expression simplification (Dramko et al., 2024; Lee et al., 2011; Schwartz et al., 2013). As a result, each decompiler exposes a different view of the same binary. These views can contain tool-specific artefacts that are not semantically neutral for an LLM (Cao et al., 2024). A behavior obscured in one decompiler’s output may be more visible in
Conventional human analysis
Single-view LLM analysis
Multi-view LLM analysis
Compiled binary (no source, often stripped)
Compiled binary (no source, often stripped)
Compiled binary (no source, often stripped)
Decompiler
Single decompiler e.g., Ghidra
Ghidra decompiler
RetDec decompiler
Decompiled pseudo-C
One pseudo-C view
Ghidra pseudo-C
RetDec pseudo-C
Human analyst inspection manual bottleneck
LLM classifier
LLM classifier with combined views
Decision: benign / malicious
Decision: benign / malicious
Decision: benign / malicious
Figure 1: Three workflows for binary malware classification. Conventional reverse engineering relies on a human analyst to inspect decompiled pseudo-C. A single-view LLM pipeline replaces this manual stage with an LLM, but still depends on one decompiler’s representation. This work studies a multi-view alternative in which outputs from multiple decompilers provide complementary views of the same binary to the LLM.
another, while a noisy representation may also mislead the model. This motivates a simple hypothesis: different decompilers can provide complementary evidence to an LLM. If the errors induced by one decompiler’s representation are not perfectly correlated with those induced by another, then combining multiple decompiled views may improve classification. This is attractive in practice because it can be built on top of existing open-source decompilers and offthe-shelf LLMs, without requiring model training or access to source code. We study this hypothesis empirically. We construct a balanced benchmark of benign and malicious C programs, compile each program into a binary, and decompile every binary with two widely used free and open-source decompilers: Ghidra and RetDec (National Security Agency, 2019; Avast Software, 2024; Cao et al., 2022). The benign samples are curated to reflect common utility behaviors, including parsing, cryptography, monitoring, and networking. The malicious samples cover a range of malware behaviors, including botnets, worms, trojans, rootkits, backdoors, and keylogging. This setup lets us evaluate both how well off-the-shelf LLMs classify decompiled binaries and whether multiple decompiler views provide useful complementary information. Across a panel of LLMs, we find that decompiler choice substantially affects classification behavior, and that combining decompiler views improves performance in most settings across model families.
The gains are particularly important for smaller models, where multi-view inputs improve recall. We also find that disagreements between decompiler views are informative: when single-view predictions differ, the additional context from multiple views often helps the model recover the correct decision. Our main contributions are: • A curated benchmark for LLM-based malware classification from decompiled binaries, with matched Ghidra and RetDec outputs. • A multi-view formulation for comparing singleand multi-decompiler LLM pipelines. • An empirical study showing that decompiler views are complementary and that combining them improves performance in most settings.
2
Related Work
LLMs for malware detection. Large language models are increasingly used to analyse code for security defects, including detecting vulnerabilities in source code across many languages (Dozono et al., 2024; Jiang et al., 2024) and repairing buggy programs (Xia et al., 2023), with recent surveys mapping the breadth of these security applications (Zhang et al., 2025; Xu et al., 2024). Malware detection is a prominent instance of this trend. Beyond decompiled binaries, LLMs and earlier transformer models have been applied across input representations: detecting injected malicious functions in source packages (Tsfaty and Fire, 2022), classifying Android applications from multiple feature
views (Zhao et al., 2025; Qian et al., 2025; Walton et al., 2025), and summarising or deobfuscating real-world malware to support human analysts (Fujii and Yamagishi, 2025; Patsakis et al., 2024; Lu et al., 2024), with broader reviews surveying this fast-growing area (Al-Karaki et al., 2024). The recurring finding is that LLMs carry useful priors about malicious behavior from code-level inputs; our focus is on surfacing those priors when the input is the noisy, decompiled C recovered from a stripped binary rather than source code. LLMs for decompiled-code analysis. Recent work has begun to use LLMs for analysing decompiled binaries. Pordanesh and Tan (2024) study GPT-4’s ability to reason about reverse-engineered code, while Manuel et al. (2024) benchmark LLMs for vulnerability analysis over decompiled functions. Most closely related to our work, Chawla and Prasad (2026) propose a decompilation-driven pipeline for malware detection with LLMs, addressing the same end task that we study. These approaches typically operate on the output of a single decompiler, often Ghidra. This makes the decompiler’s representation the sole view of the binary available to the model. Fang et al. (2024) show that LLM code analysis can be brittle and sensitive to surface form, which is a particular concern when the input is a noisy, tool-specific reconstruction rather than source code. Our work keeps the decompiler–LLM pipeline, but studies whether multiple decompiler views provide complementary evidence for malware classification. Decompiler variability. Decompiler outputs can differ substantially across tools. Cao et al. (2024) evaluate the effectiveness of current decompilers, and Dramko et al. (2024) characterise fidelity issues in recovered C, including errors in type recovery, naming, and control-flow reconstruction. This difficulty is intrinsic to the task: decompilation must reconstruct high-level types and control flow that compilation discards, a problem studied since early work on reverse compilation and type recovery (Cifuentes, 1994; Lee et al., 2011; Schwartz et al., 2013). This line of work shows that decompiled pseudo-code is not a canonical representation of the original program: each tool makes heuristic choices that can change what is exposed, obscured, or distorted. Prior work mainly treats this variability as a challenge for human reverse engineers. We instead ask whether such variability can also be useful for LLM-based analysis, by providing multiple
imperfect but complementary views of the same binary. Combining multiple views. Combining diverse predictions is a standard way to improve robustness in machine learning, including through classical model ensembles and, more recently, LLM methods that aggregate over multiple reasoning paths (Wang et al., 2023; Li et al., 2024) or over the outputs of several prompts, agents, or models (Du et al., 2023; Wang et al., 2024; Chen et al., 2025). These methods usually vary the model-side computation while keeping the input fixed. Our work considers a different axis of diversity: the input representation itself. By decompiling the same binary with multiple tools, we obtain distinct pseudo-code views whose errors and artefacts need not be correlated. We then study whether these views can be combined to improve LLM-based malware classification. To our knowledge, prior work on LLMbased malware detection from decompiled binaries has not systematically evaluated multi-decompiler aggregation.
3
Multi-View Decompiler Classification
From binaries to decompiled views. Our setting follows the static reverse-engineering pipeline introduced in Figure 1. Given a compiled binary, a decompiler attempts to recover an approximate C-like representation that can be inspected by a human analyst or, in our case, by an LLM. Decompilation is more informative than raw disassembly for code understanding, but it is also lossy and heuristic: tools must reconstruct control flow, infer types, recover variables, and assign names without access to the original source (Cifuentes, 1994; Schwartz et al., 2013; Lee et al., 2011). These choices are not uniquely determined, so the same binary can yield different pseudo-code depending on the decompiler. This tool dependence is central to our study. Prior work shows that current decompilers differ in the readability and semantic fidelity of their outputs (Cao et al., 2024; Dramko et al., 2024). In practice, Ghidra and RetDec often expose different surface forms of the same program, including different naming conventions, type recovery, cast structure, and control-flow reconstruction. We treat these outputs as distinct views of the same binary. Rather than assuming that one decompiler provides the canonical representation, we ask whether multiple views provide complementary evidence for
LLM-based malware classification. Task formulation. Let b denote a compiled binary with ground-truth label y(b) ∈ {0, 1}, where 1 denotes malicious and 0 denotes benign. We decompile each binary with two decompilers, D = {G, R}, corresponding to Ghidra and RetDec. Each decompiler δd produces a pseudo-C view cd = δd (b),
d ∈ {G, R}.
The task is to predict y(b) from one or more decompiled views. We use Ghidra and RetDec, two of the most widely used decompilers (Cao et al., 2022; Chawla and Prasad, 2026), because both are free, open source, scriptable, and suitable for reproducible batch processing, while still relying on different decompilation pipelines. LLM classifier. We use an LLM as a binary classifier over decompiled code. A prompt template π wraps one or more pseudo-C views with task instructions and asks the model to reason about the program before returning a final label in {0, 1}. The reasoning step is included because, in pilot experiments, it improved classification reliability 1 . The final decision is read directly from the model’s binary output; we do not use model probabilities or apply a threshold. Single-decompiler prediction. The single-view setting classifies each decompiler output independently. For decompiler d, the prediction is ŷd = f (πsingle (cd )) ,
d ∈ {G, R},
where f is the LLM and πsingle is the prompt used for a single pseudo-C view. This setting tests how much classification performance depends on the choice of decompiler. Multi-view prediction. The multi-view setting presents both decompiler outputs to the model in a single prompt: ŷGR = f (πmulti (cG , cR )) . The prompt tells the model that the two inputs are complementary decompiled views of the same binary and asks it to classify the binary as malicious if either view provides convincing evidence of malicious behavior. This setting tests whether an LLM can benefit from seeing two tool-specific reconstructions of the same program. 1
The prompt templates are given in Appendix E
Disagreement-triggered consensus. We also consider a simple consensus rule that uses the multiview prompt only when the two single-view predictions disagree: ( ŷG if ŷG = ŷR , ŷcons = ŷGR otherwise. The motivation is that agreement between decompiler views provides a simple signal of confidence, while disagreement identifies cases where a single decompiler choice would change the decision. In deployment, this rule avoids running the longer multi-view prompt on every sample, but it still requires the two single-view LLM calls to be made first. It therefore trades additional inference cost on contested examples for a more targeted use of combined decompiler context.
4
Dataset Creation
Benchmark design. We construct a balanced benchmark of 100 C programs, with 50 benign and 50 malicious samples. Each program is compiled into a binary object and decompiled with both Ghidra and RetDec, producing matched decompiler views for every sample. This matched design ensures that all samples pass through the same compilation and decompilation pipeline, so differences in the pseudo-C presented to the LLM reflect decompiler-specific behavior rather than differences in sample processing. The benchmark is designed to reflect the ambiguity encountered in practical malware triage. We intentionally construct the benign corpus around realistic utility behaviors such as file processing, parsing, cryptography, process and system monitoring, and networking. These behaviors overlap with low-level idioms that also appear in malware, so the classifier cannot rely on superficial cues such as the presence of sockets, encryption, or filesystem access. The malicious corpus is curated to cover a range of threat behaviors seen in security analysis, including botnets, worms, banking trojans, rootkits, backdoors, and keylogging. Table 1 summarises the dataset composition. Compilation and decompilation. All samples are compiled on Linux using a single gcc configuration, producing 64-bit x86 ELF relocatable object files (.o). We use -O2 optimisation and apply the same compiler settings uniformly across classes. We also use -fno-stack-protector to
Benign (50 samples) Domain
Example programs
n
Core utilities Archive/parsing Cryptography Monitoring Networking
cat, grep, wc base64, json_tok aes128, sha256, hmac proclist, meminfo http_get, tcp_server
10 10 10 10 10
Malicious (50 samples) Family
behavior type
n
Mirai MyDoom Hellbot Dexter POS Carberp Remhead x0r USB Worm Keylogger Minipig Rovnix Rubilyn
IoT botnet Email worm Botnet PoS malware Banking trojan Rootkit USB worm Keylogger Backdoor/RAT Bootkit Rootkit
13 13 8 5 3 2 2 1 1 1 1
Table 1: Dataset composition. Benign programs are original utilities spread evenly across five functional domains; malicious programs are grouped by malware family and behavior type.
views. All models are queried at temperature 0.6. Prompts ask the model to give a brief rationale before returning structured JSON with a binary decision, where 1 denotes malicious and 0 benign. Full prompt templates for every setting are listed in Appendix E. Each sample-setting pair is evaluated across five independent runs; we report mean performance and run-to-run standard deviation. Data, settings, and metrics. We evaluate on the benchmark from Section 4. All 100 samples have both Ghidra and RetDec outputs, so each model is evaluated on the full benchmark under single-decompiler, multi-view, and disagreementtriggered consensus settings. We report accuracy, precision, recall, and F1 for the malicious class, where Precision = TP/(TP + FP), Recall = TP/(TP + FN), and F1 = 2P R/(P + R). Since false negatives are especially costly in malware triage, we emphasise recall and F1 in the analysis. 5.2
avoid stack-canary instrumentation that can obscure program logic in the decompiled output, and -s to strip symbol information, reflecting the reduced symbolic information available in many binaries encountered during analysis. Each compiled object is decompiled with Ghidra and RetDec.
5
Experiments
5.1
Experimental Setup
Models. We evaluate a cost-conscious panel of instruction-tuned LLMs spanning major model families and both proprietary and open-weight systems: Google’s gemini-2.5-flash-lite (Gemini Team, Google DeepMind, 2025), OpenAI’s GPT-5.4-mini (OpenAI, 2026), Anthropic’s Claude Haiku 4.5 (Anthropic, 2025), Alibaba’s open-weight mixture-of-experts model Qwen3-35B-A3B (Qwen Team, 2025), and Meta’s open-weight Llama-3.3-70B-Instruct (Llama Team, AI @ Meta, 2024). We focus on smaller or lower-cost variants of leading model families because industrial malware triage may require running inference over large volumes of binaries, making routine use of the largest frontier models economically unattractive. This gives a more realistic deployment setting: models must be capable enough to reason about decompiled code, but cheap enough to run across many samples and decompiler
Results
Main results. Table 2 reports malicious-class F1 for each model and decompilation setting. All models obtain substantial performance from decompiled pseudo-C, showing that off-the-shelf LLMs can support malware classification in this setting. However, performance depends strongly on both the model and the decompiler view. There is no universally best single decompiler: Ghidra is stronger for Qwen and GPT-5.4-mini, RetDec is stronger for Llama-3.3-70B, and the two are effectively tied for Claude Haiku 4.5 and gemini-2.5-flash-lite. The multi-view setting is the strongest overall. It gives the best F1 for four of the five models, improving over the better single decompiler by +13.9 for gemini-2.5-flash-lite, +7.9 for Llama-3.3-70B, +7.7 for GPT-5.4-mini, and +3.6 for Claude Haiku 4.5. The exception is Qwen, where multi-view classification is slightly below the best single view (78.0 vs. 79.5). The disagreement-triggered consensus rule is competitive, but it does not improve over direct multi-view prompting except for tying Claude Haiku 4.5. Since direct multi-view classification uses a single LLM call per sample, while consensus requires the two single-view calls and sometimes an additional multi-view call, direct combination is also the simpler option when the goal is final classification.
Setting
Qwen3
Llama
Haiku
Flash-Lite
GPT-mini
Ghidra only RetDec only
79.5±2.7 66.7±2.1
75.0±3.3 81.0±2.4
88.9±1.2 88.9±1.9
75.0±2.4 73.4±3.1
71.8±2.2 61.1±2.8
Multi-view Consensus
78.0±0.7 75.2±1.8
88.9±1.3 80.3±2.1
92.5±0.9 91.5±0.9
88.9±2.0 80.6±3.0
79.5±1.6 73.1±3.1
Table 2: Malicious-class F1 (%) by model and decompilation setting. Subscripts denote standard deviation over five runs. Best result per model is bolded. RetDec prediction
RetDec prediction benign
24
6
36
4
22
8
24M · 0B
6M · 0B
36M · 0B
4M · 0B
22M · 0B
8M · 0B
10
60
4
56
7
63
10M · 0B
10M · 50B
4M · 0B
6M · 50B
7M · 0B
13M · 50B
Agreement Disagreement
Malicious (true) Benign (true)
(a) Llama
Agreement Disagreement
Malicious (true) Benign (true)
(b) Haiku
benign
malicious
malicious
Ghidra prediction
benign
malicious
malicious
Ghidra prediction
benign
benign
malicious benign
Ghidra prediction
RetDec prediction malicious
Agreement Disagreement
Malicious (true) Benign (true)
(c) Flash-Lite
Figure 2: Prediction agreement between Ghidra-only and RetDec-only classifiers. Rows correspond to the Ghidra prediction and columns to the RetDec prediction. Off-diagonal cells show samples where the two decompiler views lead to different labels.
Decompiler complementarity. Figure 2 shows prediction agreement matrices for the singledecompiler settings, with all models reported in Figure 8. Each subplot compares Ghidra-only and RetDec-only predictions for one model; offdiagonal cells are samples where changing only the decompiler view changes the predicted label. These disagreements show that the tools are not interchangeable: each can make different behaviours more or less visible through its choices about control flow, types, casts, and naming. This complementarity matters because the dominant failure mode is missed malicious samples rather than false positives. Since precision is high, F1 gains mostly come from improved recall. When one view obscures the relevant behaviour, the other may expose enough evidence to recover the malicious label. Direct multi-view prompting also often beats the consensus rule, suggesting that the gain is not limited to explicit single-view disagreements: in some cases, neither view is sufficient alone, but together they provide enough evidence for the model to make the malicious call.
6
Conclusions and Future Work
We studied LLM-based malware classification from decompiled binaries and showed that decompiler choice materially affects performance. Single decompiler views often lead models to be conservative, missing malicious samples when the relevant behavior is obscured or rendered unclearly. Providing multiple decompiler views gives the model additional evidence, improving recall and therefore malicious-class F1 in most settings; this is especially valuable for malware triage, where missed malicious samples are more costly than false positives. Our results suggest that decompiler diversity is a simple and practical way to improve off-theshelf LLM analysis without model training. Future work should extend the benchmark with harder benign programs, broader malware behaviors, and emerging AI-era attack surfaces such as malicious or hallucinated dependencies in generated code. It should also explore richer combination strategies, including learned view selection, evidence aggregation, and cost-aware pipelines that decide when additional decompiler views are worth querying.
7
Limitations
Object files, not whole programs. We classify relocatable object files (.o), code fragments without a main entry point or full linkage. This mirrors how individual malware modules often appear, but a deployed analyst usually inspects a complete executable with surrounding context, so our findings may not transfer directly to whole-binary triage. No obfuscation or anti-decompilation. We assume binaries decompile cleanly. In practice, authors sometimes deliberately obfuscate or pack code to resist decompilation, for instance to deter reverse engineering or code theft, and our samples are neither packed nor adversarially hardened (we retain part of the symbol table rather than scrambling or fully obscuring program structure). Heavily obfuscated or anti-decompilation-hardened binaries lie outside the setting we study and would likely degrade every approach we evaluate. Number of decompilers. We study two decompilers, Ghidra and RetDec. Although these two are widely used, they do not cover other proprietary tools (e.g. IDA Pro, Binary Ninja), and our complementarity findings may change with other tools, or with more than two views combined.
8
Ethics and Impact Statement
Intended use and impact. We study the automated classification of binaries as malicious or benign, which is a defensive task. Our aim is to help analysts, researchers, and security systems triage software more reliably, especially when the source code is unavailable and only decompiled output can be inspected. Our goal is detection rather than generating attacks: we do not develop novel malware, attack techniques, or evasion methods. Malicious samples. All but one of our malicious samples are real-world specimens of welldocumented families obtained from an established public repository (ytisf and contributors, 2014); the exception is the synthetic keylogger noted above, which reimplements a publicly described technique and adds no new capability. We introduce no new malware families, capabilities, or evasion methods. Every program in the benchmark, benign and malicious alike, is compiled from source and then statically decompiled inside an isolated, networkdisabled container; the malicious binaries are never executed.
Release and dual-use considerations. To support reproducibility, we share the decompiled artefacts and evaluation code underlying our results for research purposes. Because the malicious samples are either already-public specimens or a trivial reimplementation of a long-documented technique, releasing their decompiled representations does not provide capabilities beyond what the community can already obtain, and we judge the reproducibility benefit to outweigh this marginal risk. We nonetheless acknowledge the dual-use nature of malware research: a determined adversary could attempt to craft samples that evade an LLM-based classifier such as ours. Our released material concerns detection rather than evasion and contains no new offensive functionality. We follow the usage terms of the source repositories and recommend that anyone reusing these artefacts do so only in controlled, nonproduction environments for defensive research.
References Jamal Al-Karaki, Muhammad Al-Zafar Khan, and Marwan Omar. 2024. Exploring LLMs for malware detection: Review, framework design, and countermeasure approaches. Preprint, arXiv:2409.07587. Anthropic. 2025. Introducing claude haiku 4.5. https: //www.anthropic.com/news/claude-haiku-4-5. Large language model (claude-haiku-4-5); accessed June 2026. Avast Software. 2024. RetDec: A retargetable machinecode decompiler. https://github.com/avast/ retdec. Ying Cao, Ruigang Liang, Kai Chen, and Peiwei Hu. 2022. Boosting neural networks to decompile optimized binaries. In Proceedings of the 38th Annual Computer Security Applications Conference (ACSAC). Ying Cao, Runze Zhang, Ruigang Liang, and Kai Chen. 2024. Evaluating the effectiveness of decompilers. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2024), pages 491–502, New York, NY, USA. Association for Computing Machinery. Aniesh Chawla and Udbhav Prasad. 2026. A decompilation-driven framework for malware detection with large language models. Preprint, arXiv:2601.09035. Zhijun Chen, Jingzheng Li, Pengpeng Chen, Zhuoran Li, Kai Sun, Yuankai Luo, Qianren Mao, Dingqi Yang, Hailong Sun, and Philip S. Yu. 2025. Harnessing multiple large language models: A survey on LLM ensemble. Preprint, arXiv:2502.18036.
Cristina Cifuentes. 1994. Reverse Compilation Techniques. Ph.D. thesis, Queensland University of Technology. Kohei Dozono, Tiago Espinha Gasiba, and Andrea Stocco. 2024. Large language models for secure code assessment: A multi-language empirical study. Preprint, arXiv:2408.06428.
iterative binary malware summarization. Preprint, arXiv:2406.18379. Dylan Manuel, Nafis Tanveer Islam, Joseph Khoury, Ana Nunez, Elias Bou-Harb, and Peyman Najafirad. 2024. Enhancing reverse engineering: Investigating and benchmarking large language models for vulnerability analysis in decompiled binaries. Preprint, arXiv:2411.04981.
Luke Dramko, Jeremy Lacomis, Edward J. Schwartz, Bogdan Vasilescu, and Claire Le Goues. 2024. A taxonomy of C decompiler fidelity issues. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association.
National Security Agency. 2019. Ghidra software reverse engineering framework. https:// ghidra-sre.org. Version 12.1, https://github. com/NationalSecurityAgency/ghidra.
Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch. 2023. Improving factuality and reasoning in language models through multiagent debate. Preprint, arXiv:2305.14325.
OpenAI. 2026. Introducing GPT-5.4 mini and nano. https://openai.com/index/ introducing-gpt-5-4-mini-and-nano/. Large language model; accessed June 2026.
Chongzhou Fang, Ning Miao, Shaurya Srivastav, Jialin Liu, Ruoyu Zhang, Ruijie Fang, Asmita, Ryan Tsang, Najmeh Nazari, Han Wang, and Houman Homayoun. 2024. Large language models for code analysis: Do LLMs really do their job? In 33rd USENIX Security Symposium (USENIX Security 24), pages 829–846, Philadelphia, PA. USENIX Association.
Constantinos Patsakis, Fran Casino, and Nikolaos Lykousas. 2024. Assessing LLMs in malicious code deobfuscation of real-world malware campaigns. Expert Systems with Applications, 256:124912.
Shota Fujii and Rei Yamagishi. 2025. Feasibility study for supporting static malware analysis using LLM. In Computer Security. ESORICS 2024 International Workshops, volume 15264 of Lecture Notes in Computer Science. Springer. Gemini Team, Google DeepMind. 2025. Gemini 2.5: Pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities. Preprint, arXiv:2507.06261. Hex-Rays. 2024. IDA Pro: Interactive disassembler and decompiler. https://hex-rays.com/ida-pro. Accessed: June 2026. Xuefeng Jiang, Lvhua Wu, Sheng Sun, Jia Li, Jingjing Xue, Yuwei Wang, Tingting Wu, and Min Liu. 2024. Investigating large language models for code vulnerability detection: An experimental study. Preprint, arXiv:2412.18260.
Saman Pordanesh and Benjamin Tan. 2024. Exploring the efficacy of large language models (gpt-4) in binary reverse engineering. Preprint, arXiv:2406.06637. Xingzhi Qian, Xinran Zheng, Yiling He, Shuo Yang, and Lorenzo Cavallaro. 2025. LAMD: Context-driven android malware detection and classification with LLMs. Preprint, arXiv:2502.13055. Qwen Team. 2025. Qwen3 technical report. Preprint, arXiv:2505.09388. Edward J. Schwartz, JongHyup Lee, Maverick Woo, and David Brumley. 2013. Native x86 decompilation using semantics-preserving structural analysis and iterative control-flow structuring. In 22nd USENIX Security Symposium (USENIX Security 13), pages 353–368. USENIX Association. Chen Tsfaty and Michael Fire. 2022. Malicious source code detection using transformer. Preprint, arXiv:2209.07957.
JongHyup Lee, Thanassis Avgerinos, and David Brumley. 2011. TIE: Principled reverse engineering of types in binary programs. In Proceedings of the Network and Distributed System Security Symposium (NDSS).
Brandon J. Walton, Mst Eshita Khatun, James M. Ghawaly, and Aisha Ali-Gombe. 2025. Exploring large language models for semantic analysis and categorization of android malware. Preprint, arXiv:2501.04848.
Junyou Li, Qin Zhang, Yangbin Yu, Qiang Fu, and Deheng Ye. 2024. More agents is all you need. Transactions on Machine Learning Research (TMLR).
Junlin Wang, Jue Wang, Ben Athiwaratkun, Ce Zhang, and James Zou. 2024. Mixture-of-agents enhances large language model capabilities. Preprint, arXiv:2406.04692.
Llama Team, AI @ Meta. 2024. The Llama 3 herd of models. Preprint, arXiv:2407.21783. Haolang Lu, Hongrui Peng, Guoshun Nan, Jiaoyang Cui, Cheng Wang, Weifei Jin, Songlin Wang, Shengli Pan, and Xiaofeng Tao. 2024. MalSight: Exploring malicious source code and benign pseudocode for
Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2023. Self-consistency improves chain of thought reasoning in language models. In International Conference on Learning Representations (ICLR).
Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated program repair in the era of large pre-trained language models. In Proceedings of the 45th International Conference on Software Engineering (ICSE), pages 1482–1494. H. Xu, S. Wang, N. Li, K. Wang, Y. Zhao, K. Chen, T. Yu, Y. Liu, and H. Wang. 2024. Large language models for cyber security: A systematic literature review. Preprint, arXiv:2405.04760. ytisf and contributors. 2014. theZoo: A live malware repository. https://github.com/ytisf/theZoo. Accessed: June 2026. J. Zhang, H. Bu, H. Wen, Y. Chen, L. Li, and H. Zhu. 2025. When LLMs meet cybersecurity: A systematic literature review. Cybersecurity. Wenxiang Zhao, Juntao Wu, and Zhaoyi Meng. 2025. AppPoet: Large language model based android malware detection via multi-view prompt engineering. Expert Systems with Applications, 262:125546.
A
Popular Decompilers
Table 3 presents four of the most popular opensource and proprietary decompilers used in industry. Decompiler
Availability / Cost
Ghidra RetDec IDA Pro (Hex-Rays) Binary Ninja (Vector 35)
Free, open source (NSA) Free, open source (Avast) Paid, proprietary; free IDA Free tier for evaluation Paid, proprietary; free cloud tier and Free edition for evaluation/education
a single decompiler view, with RetDec alone reaching the best F1 . However, multi-view prompting substantially closes the gap between the lower-cost and larger Gemini models: Flash-Lite improves from 75.0 F1 with its best single view to 88.9 with both views, reducing the gap to Gemini Pro’s best result from 15.3 points to 1.4 points. This supports the main motivation of our deployment setting: combining decompiler views can recover much of the performance otherwise associated with a larger model, while remaining more practical for large-scale triage.
Table 3: Representative C decompilers and their availability. Tool-specific naming and type-recovery heuristics can produce divergent renderings of the same function. We focus on Ghidra and RetDec, both free and open source.
B
Metadata and size statistics
Metadata and size statistics. For each sample, we maintain a metadata record containing the sample identifier, ground-truth label, behavioral annotations, provenance fields, and paths to the source, compiled object, Ghidra output, and RetDec output. We also record basic size statistics for the compiled and decompiled artefacts. Table 4 reports median sizes and ranges by class. Although compiled object sizes differ across classes, the decompiled inputs seen by the LLM are of comparable scale for benign and malicious samples, reducing the risk that the task is dominated by obvious length cues.
Setting Ghidra only RetDec only Multi-view Consensus
Gemini Flash-Lite
Gemini Pro
75.0±2.4 73.4±3.1 88.9±2.0 81.0
83.7±0.7 90.3±1.4 85.4±0.8 86.7
Table 5: Malicious-class F1 (%) for Gemini models. Subscripts denote standard deviation over five runs where applicable. Gemini Pro is included as a largermodel reference point. Multi-view prompting lets the lower-cost Flash-Lite model recover most of the gap to Gemini Pro’s best single-view performance.
D
Per-Family Recall Breakdown
Recall on each malware family (Ghidra / RetDec / Combined), per model, expanding the aggregate recall trends from Section 5. Family sizes (n) are given on the x-axis; single-example families (n=1) are high-variance and shown for completeness only. D.1
Per-family malware recall
Recall on each malware family (Ghidra / RetDec / Combined), per model. Family sizes (n) are given Source lines 261 (20–2030) — Compiled (bytes) 6,128 (1.3k–30k) 16,468 (16.0k–17.0k) on the x-axis; single-example families (n=1) are Ghidra (bytes) 12,705 (1.5k–280k) 10,802 (7.2k–69k) high-variance and shown for completeness only. RetDec (bytes) 14,374 (0.4k–142k) 9,186 (5.2k–54k) Metric
Malicious
Benign
Table 4: Size statistics by class: median and min–max range. Decompiled output sizes are comparable across benign and malicious samples for both decompilers.
C
Gemini-Pro Reference Results
The main experiments focus on smaller or lowercost models, since industrial malware triage may require running inference over large volumes of binaries and decompiler views. For reference, we also evaluate Gemini 2.5 Pro, a larger model from the same family as Gemini 2.5 Flash-Lite. Table 5 shows that the larger model performs strongly from
E
Prompt Templates
We use a definition-only prompt for the main experiments. It defines malicious and benign behavior without listing concrete malware indicators, to avoid steering the model toward particular attack families or surface patterns. In the singledecompiler setting, the user message contains one decompiled pseudo-C view. In the multi-view setting, the same definition is used, but the user message contains both Ghidra and RetDec outputs and states that they are complementary views of the same binary; the exact prompt wrapper is provided in the released codebase. In all settings, the model
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
Ghidra RetDec Combined
50%
67%
67%
67%
100%
100%
100%
100% 75%
85% 69%
77%
69%
0.8
69%
Recall
1.0
92%
1.2
100%
Per-family malware recall Claude Haiku 4.5
0.6 0.4 0.2 0.0
i ra om mi 3) do 3) 1 my n=1 = n ( (
ot llb ) he n=8 (
r xte de =5) (n
r d x0 ) ea ) 2 mh 2 = re (n= (n
p er ) rb ca (n=3
ig nip ) mi n=1 (
r ix ge vn ro =1) ylog =1) e (n (n _k tic he t yn
yn bil ) ru n=1 ( s
Figure 3: Per-family recall — Claude Haiku 4.5.
0.4
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
50%
33%
33%
50%
60%
62%
50%
Ghidra RetDec Combined
67%
85% 69% 46%
0.6
69%
69%
0.8 54%
Recall
1.0
100%
100%
1.2
100%
Per-family malware recall Gemini 2.5 Flash-Lite
0.2 0.0
i m ra oo ) mi 3) yd 13 1 m = = (n (n
ot llb ) he n=8 (
r xte de =5) (n
r ad x0 ) he ) =2 rem n=2 (
p er ) rb ca (n=3
(n
ig nip ) mi n=1 (
r ix ge vn ro =1) ylog =1) e (n (n k ic_ et th yn
yn bil ) ru n=1 ( s
Figure 4: Per-family recall — Gemini 2.5 Flash-Lite.
0.2
i m ra oo ) mi 3) yd 13 1 m = = (n (n
50% 33%
33%
ot llb ) he n=8 (
r xte de =5) (n
p er ) rb ca (n=3
r ad x0 ) he ) =2 rem n=2 (
(n
ig nip ) mi n=1 (
r ix ge vn ro =1) ylog =1) e n (n ( k ic_ et th yn
yn bil ) ru n=1 ( s
Figure 5: Per-family recall — Llama-3.3-70B-Instruct.
100%
100%
100%
100%
67%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
Ghidra RetDec Combined
12%
0.4
0.0
100%
100%
62%
62% 46%
0.6
77%
77%
0.8 54%
Recall
1.0
85%
100%
1.2
100%
Per-family malware recall Llama 3.3-70B
23%
25%
0.4
i ra om mi 3) do 3) 1 my n=1 = (n (
ot llb ) he n=8 (
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
Ghidra RetDec Combined
50%
50%
50%
67%
67%
67%
62%
62% 38%
0.6
54%
62%
62%
0.8
62%
Recall
1.0
100%
100%
1.2
100%
Per-family malware recall Qwen3.6-35B
0.2 0.0
r xte de =5) (n
r ad x0 ) he 2) 2 m = = e r (n (n
p er ) rb ca (n=3
yn bil ) ru n=1 (
ig nip ) mi n=1 (
r ix ge vn ro =1) ylog =1) (n ke (n ic_ et th n sy
Figure 6: Per-family recall — Qwen3.6-35B-A3B.
ot llb ) he n=8 (
50%
0.2 0.0
r xte de =5) n (
p er ) rb ca (n=3
r ad x0 ) he ) =2 rem n=2 n ( (
ig nip ) mi n=1 (
Figure 7: Per-family recall — GPT-5.4-mini.
yn bil ) ru n=1 (
r ix ge vn ro =1) ylog =1) e n n ( ( k ic_ et th n sy
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100% 67%
67%
50%
38%
25%
i m ra oo ) mi 3) yd 13 1 m = = (n (n
Ghidra RetDec Combined
33%
62%
54% 38% 23%
0.4
54%
0.6
54%
0.8 54%
Recall
1.0
60%
100%
1.2
100%
Per-family malware recall GPT-5.4 Mini
Agreement Disagreement
RetDec prediction
6 6M · 0B
10
60
10M · 0B
10M · 50B
Malicious (true) Benign (true)
(a) Qwen3
Agreement Disagreement
36
4 4M · 0B
36M · 0B
4
56
4M · 0B
6M · 50B
Malicious (true) Benign (true)
Agreement Disagreement
(b) Llama
Malicious (true) Benign (true)
(d) Flash-Lite
benign
21
7 7M · 0B
malicious
63 13M · 50B
Ghidra prediction
7 7M · 0B
malicious
21M · 0B
benign
8 8M · 0B
malicious
22
benign
Ghidra prediction
RetDec prediction benign
22M · 0B
Agreement Disagreement
Malicious (true) Benign (true)
(c) Haiku
RetDec prediction malicious
benign
malicious
24 24M · 0B
malicious
Ghidra prediction
benign
malicious
67 17M · 50B
Ghidra prediction
0 0M · 0B
malicious
benign
8 8M · 0B
malicious
25 25M · 0B
benign
Ghidra prediction
RetDec prediction benign
benign
RetDec prediction malicious
1
71
1M · 0B
21M · 50B
Agreement Disagreement
Malicious (true) Benign (true)
(e) GPT-mini
Figure 8: Prediction agreement between Ghidra-only and RetDec-only classifiers. Rows correspond to the Ghidra prediction and columns to the RetDec prediction. Off-diagonal cells show samples where the two decompiler views lead to different labels.
is asked to provide a brief rationale before returning a structured binary decision. For the guided upper-bound experiment in Appendix F, we also use an indicator-guided prompt. This prompt augments the same definition with an explicit checklist of suspicious behaviors.
F
Guided-Prompt Upper Bound
The main experiments use the definition-only prompt in Appendix 9. This prompt deliberately avoids listing concrete malicious indicators, since such a list may steer the model toward behaviors represented in the benchmark rather than testing whether it can infer maliciousness from the decompiled code itself. To estimate how much headroom a more guided prompt can provide, we also evaluate the indicator-guided prompt in Appendix 10 on Gemini 2.5 Flash-Lite, the model with the largest multi-view gain in the main results.
The guided prompt should be interpreted as an optimistic upper bound, not as the main deployable setting. Its indicator list gives the model a strong prior over suspicious behaviors, which can improve performance on known malware patterns but may reduce robustness to novel behaviors or benign programs with superficially similar APIs. We therefore report it only as an ablation.
You are a malware analyst specialising in static analysis of decompiled C code. You will be given decompiled C source code recovered from a compiled binary. Your task is to determine whether the code is malicious. Malicious code is software that intentionally performs harmful, covert, or unauthorised actions against a system or its users without their knowledge or consent. It operates outside the user’s awareness or against their interests, regardless of how it achieves this. Benign code performs legitimate, transparent, and well-scoped operations that serve an obvious, non-harmful purpose and do not attempt to conceal their behavior or effects. Briefly explain what the code appears to do, then decide whether it is benign or malicious. Return your answer as JSON with the following fields: { "rationale": "<brief explanation>", "decision": 0 or 1 } Use decision = 1 for malicious code and decision = 0 for benign code.
Figure 9: Definition-only classification prompt used in the main experiments. The decompiled code is supplied in the user message.
Setting Ghidra only RetDec only Multi-view Consensus
Definition-only
Indicator-guided
75.0 73.4 88.9 81.0
88.9 90.1 85.1 86.4
Table 6: Malicious-class F1 (%) for Gemini 2.5 Flash-Lite under the definition-only and indicatorguided prompts. The guided prompt raises single-view performance to roughly the level of the definition-only multi-view setting, indicating that explicit behavioral guidance can recover much of the same signal. We treat this as an optimistic upper bound rather than the main experimental setting.
You are a malware analyst specialising in static analysis of decompiled C code. You will be given decompiled C source code recovered from a compiled binary. Your task is to determine whether the code is malicious. Malicious code is software that intentionally performs harmful, covert, or unauthorised actions against a system or its users without their knowledge or consent. Common indicators include: - Network scanning, port sweeping, or raw socket abuse - Remote shell or command execution - Process injection or memory manipulation - Keylogging, credential harvesting, or screen capture - Persistence mechanisms - DDoS or flood attack functions - Botnet command-and-control communication - Anti-debugging, anti-analysis, or sandbox evasion - Encryption used to hide payloads or C2 traffic - Destruction of files, logs, or system integrity Benign code performs legitimate, transparent, and well-scoped operations that serve an obvious, non-harmful purpose and do not attempt to conceal their behavior or effects. Briefly explain what the code appears to do, then decide whether it is benign or malicious. Return your answer as JSON with the following fields: { "rationale": "<brief explanation>", "decision": 0 or 1 } Use decision = 1 for malicious code and decision = 0 for benign code.
Figure 10: Indicator-guided prompt used only for the upper-bound analysis in Appendix F. It is not used in the main results.