Paper deep dive
Multi-View Decompilation for LLM-Based Malware Classification
Bercan Turkmen, Vyas Raina
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 98%
Last extracted: 6/21/2026, 5:27:24 AM
Summary
The paper proposes a 'multi-view' approach to malware classification using Large Language Models (LLMs) and multiple decompilers. The authors argue that single-decompiler pipelines are fragile because decompilers are lossy and heuristic. By providing an LLM with complementary pseudo-C views from both Ghidra and RetDec, the researchers demonstrate improved malicious-class F1 scores, primarily driven by increased recall. The study uses a curated benchmark of 100 C programs (50 benign, 50 malicious) and evaluates several LLMs, including Gemini, GPT-5.4-mini, Claude Haiku, Qwen, and Llama, finding that multi-view prompting generally outperforms single-view methods.
Entities (8)
Relation Signals (4)
LLM → classifies → Decompiled pseudo-C
confidence 100% · The task is to predict y(b) from one or more decompiled views.
Ghidra → producesviewof → Compiled Binary
confidence 100% · Each sample is compiled and decompiled with both Ghidra and RetDec, yielding matched pseudo-C views.
RetDec → producesviewof → Compiled Binary
confidence 100% · Each sample is compiled and decompiled with both Ghidra and RetDec, yielding matched pseudo-C views.
Multi-view prompting → improves → Malicious-class F1
confidence 95% · the multi-view setting is the strongest overall. It gives the best F1 for four of the five models
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2606.20436v1
- Canonical: https://arxiv.org/abs/2606.20436v1
Trouble viewing inline? Open PDF directly →
Full Text
46,355 characters extracted from source content.
Expand or collapse full text
Multi-View Decompilation for LLM-Based Malware Classification Bercan Efe Independent Researcher befeturkmen@gmail.com Vyas Raina SPARK vyas@sparkairesearch.com § github.com/B3f3/Compiled-C-Malware Abstract Malware analysts often inspect compiled bi- naries through decompiled pseudo-C, when source code is unavailable.Recent work suggests that large language models (LLMs) can assist this process by classifying decom- piled 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 differ- ent decompilers can expose different artefacts of the same binary. We curate a benchmark of benign utilities and malicious programs span- ning 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 fam- ilies, we find that providing both decompiler views improves malicious-classF 1 , mainly by increasing recall on malicious samples. Agree- ment analyses further show that Ghidra and RetDec make partially different errors, support- ing 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 mal- ware 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 en- terprise applications, where source code is withheld to protect intellectual property or simplify deploy- ment. However, binaries are also harder to audit: a program may appear to provide benign functional- ity while also containing malicious behavior such as credential theft, process injection, file encryp- tion, 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 engi- neers 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 ex- pertise, is time-consuming, and does not scale eas- ily. 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 lan- guage models (LLMs) make them a natural candi- date 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 decom- pile 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 first- pass triage, reduce analyst workload, and surface suspicious samples for human review. However, most LLM-based decompilation pipelines rely on a single decompiler, often treat- ing its output as the canonical representation of the program (Chawla and Prasad, 2026; Manuel et al., 2024). This assumption is fragile. Decom- pilation is a lossy and heuristic process: different tools make different choices about control-flow re- covery, variable naming, type inference, and ex- pression 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 arXiv:2606.20436v1 [cs.CR] 18 Jun 2026 Conventional human analysis Compiled binary (no source, often stripped) Decompiler Decompiled pseudo-C Human analyst inspection manual bottleneck Decision: benign / malicious Single-view LLM analysis Compiled binary (no source, often stripped) Single decompiler e.g., Ghidra One pseudo-C view LLM classifier Decision: benign / malicious Multi-view LLM analysis Compiled binary (no source, often stripped) Ghidra decompiler RetDec decompiler Ghidra pseudo-C RetDec pseudo-C LLM classifier with combined views 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 mis- lead the model. This motivates a simple hypothesis: different decompilers can provide complementary evidence to an LLM. If the errors induced by one decom- piler’s representation are not perfectly correlated with those induced by another, then combining mul- tiple decompiled views may improve classification. This is attractive in practice because it can be built on top of existing open-source decompilers and off- the-shelf LLMs, without requiring model training or access to source code. We study this hypothesis empirically. We con- struct a balanced benchmark of benign and mali- cious C programs, compile each program into a bi- nary, 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 sam- ples 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 comple- mentary information. Across a panel of LLMs, we find that decompiler choice substantially affects classification behavior, and that combining decompiler views improves per- formance 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 decom- piler views are informative: when single-view pre- dictions 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 single- and 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. Be- yond decompiled binaries, LLMs and earlier trans- former models have been applied across input rep- resentations: detecting injected malicious functions in source packages (Tsfaty and Fire, 2022), classi- fying 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 (Fu- jii 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 in- put 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 decom- piled 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 func- tions. Most closely related to our work, Chawla and Prasad (2026) propose a decompilation-driven pipeline for malware detection with LLMs, ad- dressing 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 con- cern when the input is a noisy, tool-specific recon- struction 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 is- sues in recovered C, including errors in type recov- ery, 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 recov- ery (Cifuentes, 1994; Lee et al., 2011; Schwartz et al., 2013). This line of work shows that decom- piled 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 variabil- ity as a challenge for human reverse engineers. We instead ask whether such variability can also be use- ful 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 meth- ods 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 com- putation while keeping the input fixed. Our work considers a different axis of diversity: the input rep- resentation itself. By decompiling the same binary with multiple tools, we obtain distinct pseudo-code views whose errors and artefacts need not be cor- related. We then study whether these views can be combined to improve LLM-based malware classi- fication. To our knowledge, prior work on LLM- based malware detection from decompiled binaries has not systematically evaluated multi-decompiler aggregation. 3 Multi-View Decompiler Classification From binaries to decompiled views. Our set- ting 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. Decom- pilation 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 with- out 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 out- puts (Cao et al., 2024; Dramko et al., 2024). In practice, Ghidra and RetDec often expose differ- ent 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 mul- tiple views provide complementary evidence for LLM-based malware classification. Task formulation. Letbdenote a compiled bi- nary with ground-truth labely(b) ∈ 0, 1, where 1denotes malicious and0denotes benign. We de- compile each binary with two decompilers,D = G, R, corresponding to Ghidra and RetDec. Each decompiler δ d produces a pseudo-C view c d = δ d (b), d ∈ G, R. The task is to predicty(b)from one or more de- compiled 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 re- producible batch processing, while still relying on different decompilation pipelines. LLM classifier.We use an LLM as a binary clas- sifier 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 in0, 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 indepen- dently. For decompiler d, the prediction is ˆy d = f(π single (c d )), d ∈ G, R, wherefis 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: ˆy GR = f(π multi (c G ,c R )). The prompt tells the model that the two inputs are complementary decompiled views of the same bi- nary and asks it to classify the binary as malicious if either view provides convincing evidence of mali- cious behavior. This setting tests whether an LLM can benefit from seeing two tool-specific recon- structions 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 multi- view prompt only when the two single-view predic- tions disagree: ˆy cons = ( ˆy G if ˆy G = ˆy R , ˆy GR otherwise. The motivation is that agreement between decom- piler 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 re- quires 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 com- piled into a binary object and decompiled with both Ghidra and RetDec, producing matched de- compiler 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 dif- ferences in sample processing. The benchmark is designed to reflect the ambi- guity encountered in practical malware triage. We intentionally construct the benign corpus around realistic utility behaviors such as file processing, parsing, cryptography, process and system monitor- ing, 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 singlegccconfig- uration, producing 64-bit x86 ELF relocatable ob- ject files (.o). We use-O2optimisation and ap- ply the same compiler settings uniformly across classes. We also use-fno-stack-protectorto Benign (50 samples) DomainExample programsn Core utilities cat, grep, wc10 Archive/parsing base64, json_tok10 Cryptography aes128, sha256, hmac10 Monitoring proclist, meminfo10 Networking http_get, tcp_server 10 Malicious (50 samples) Familybehavior typen MiraiIoT botnet13 MyDoomEmail worm13 HellbotBotnet8 Dexter POSPoS malware5 CarberpBanking trojan3 RemheadRootkit2 x0r USB WormUSB worm2 KeyloggerKeylogger1 MinipigBackdoor/RAT1 RovnixBootkit1 RubilynRootkit1 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. avoid stack-canary instrumentation that can ob- scure program logic in the decompiled output, and -sto strip symbol information, reflecting the re- duced symbolic information available in many bi- naries 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 sys- tems: Google’sgemini-2.5-flash-lite(Gem- ini Team, Google DeepMind, 2025), Ope- nAI’sGPT-5.4-mini(OpenAI, 2026), Anthropic’s Claude Haiku 4.5(Anthropic, 2025), Al- ibaba’s open-weight mixture-of-experts model Qwen3-35B-A3B(Qwen Team, 2025), and Meta’s open-weightLlama-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 run- ning inference over large volumes of binaries, mak- ing routine use of the largest frontier models eco- nomically unattractive. This gives a more real- istic deployment setting: models must be capable enough to reason about decompiled code, but cheap enough to run across many samples and decompiler views. All models are queried at temperature0.6. Prompts ask the model to give a brief rationale before returning structured JSON with a binary de- cision, where1denotes malicious and0benign. Full prompt templates for every setting are listed in Appendix E. Each sample-setting pair is evalu- ated 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 disagreement- triggered consensus settings. We report accuracy, precision, recall, andF 1 for the malicious class, wherePrecision = TP/(TP + FP),Recall = TP/(TP + FN), andF 1 = 2PR/(P + R). Since false negatives are especially costly in malware triage, we emphasise recall and F 1 in the analysis. 5.2 Results Main results.Table 2 reports malicious-classF 1 for each model and decompilation setting. All mod- els obtain substantial performance from decom- piled 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 andGPT-5.4-mini, Ret- Dec is stronger forLlama-3.3-70B, and the two are effectively tied forClaude Haiku 4.5and gemini-2.5-flash-lite. The multi-view setting is the strongest over- all. It gives the bestF 1 for four of the five mod- els, improving over the better single decompiler by+13.9forgemini-2.5-flash-lite,+7.9for Llama-3.3-70B,+7.7forGPT-5.4-mini, and +3.6forClaude Haiku 4.5. The exception is Qwen, where multi-view classification is slightly below the best single view (78.0vs.79.5). The disagreement-triggered consensus rule is competi- tive, but it does not improve over direct multi-view prompting except for tyingClaude 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 sim- pler option when the goal is final classification. Setting Qwen3 Llama Haiku Flash-Lite GPT-mini Ghidra only 79.5 ±2.7 75.0 ±3.3 88.9 ±1.2 75.0 ±2.4 71.8 ±2.2 RetDec only 66.7 ±2.1 81.0 ±2.4 88.9 ±1.9 73.4 ±3.1 61.1 ±2.8 Multi-view 78.0 ±0.7 88.9 ±1.3 92.5 ±0.9 88.9 ±2.0 79.5 ±1.6 Consensus 75.2 ±1.8 80.3 ±2.1 91.5 ±0.9 80.6 ±3.0 73.1 ±3.1 Table 2: Malicious-classF 1 (%) by model and decompilation setting. Subscripts denote standard deviation over five runs. Best result per model is bolded. maliciousbenign RetDec prediction benign malicious Ghidra prediction 24 24M · 0B 6 6M · 0B 10 10M · 0B 60 10M · 50B Agreement Disagreement Malicious (true) Benign (true) (a) Llama maliciousbenign RetDec prediction benign malicious Ghidra prediction 36 36M · 0B 4 4M · 0B 4 4M · 0B 56 6M · 50B Agreement Disagreement Malicious (true) Benign (true) (b) Haiku maliciousbenign RetDec prediction benign malicious Ghidra prediction 22 22M · 0B 8 8M · 0B 7 7M · 0B 63 13M · 50B 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 single- decompiler settings, with all models reported in Figure 8. Each subplot compares Ghidra-only and RetDec-only predictions for one model; off- diagonal cells are samples where changing only the decompiler view changes the predicted label. These disagreements show that the tools are not in- terchangeable: each can make different behaviours more or less visible through its choices about con- trol flow, types, casts, and naming. This complementarity matters because the dom- inant failure mode is missed malicious samples rather than false positives. Since precision is high, F 1 gains mostly come from improved recall. When one view obscures the relevant behaviour, the other may expose enough evidence to recover the ma- licious label. Direct multi-view prompting also often beats the consensus rule, suggesting that the gain is not limited to explicit single-view disagree- ments: 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 decom- piler choice materially affects performance. Single decompiler views often lead models to be conserva- tive, missing malicious samples when the relevant behavior is obscured or rendered unclearly. Pro- viding multiple decompiler views gives the model additional evidence, improving recall and therefore malicious-classF 1 in most settings; this is espe- cially valuable for malware triage, where missed malicious samples are more costly than false posi- tives. Our results suggest that decompiler diversity is a simple and practical way to improve off-the- shelf LLM analysis without model training. Future work should extend the benchmark with harder be- nign 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 aggre- gation, 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 with- out amainentry point or full linkage. This mirrors how individual malware modules often appear, but a deployed analyst usually inspects a complete exe- cutable with surrounding context, so our findings may not transfer directly to whole-binary triage. No obfuscation or anti-decompilation. We as- sume binaries decompile cleanly. In practice, au- thors 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 scram- bling or fully obscuring program structure). Heav- ily obfuscated or anti-decompilation-hardened bi- naries lie outside the setting we study and would likely degrade every approach we evaluate. Number of decompilers. We study two decom- pilers, Ghidra and RetDec. Although these two are widely used, they do not cover other proprietary tools (e.g. IDA Pro, Binary Ninja), and our comple- mentarity 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 auto- mated classification of binaries as malicious or be- nign, 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 gen- erating attacks: we do not develop novel malware, attack techniques, or evasion methods. Malicious samples. All but one of our mali- cious samples are real-world specimens of well- documented 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 meth- ods. Every program in the benchmark, benign and malicious alike, is compiled from source and then statically decompiled inside an isolated, network- disabled container; the malicious binaries are never executed. Release and dual-use considerations. To sup- port reproducibility, we share the decompiled arte- facts and evaluation code underlying our results for research purposes. Because the malicious sam- ples 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 nonethe- less 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 de- tection rather than evasion and contains no new of- fensive functionality. We follow the usage terms of the source repositories and recommend that anyone reusing these artefacts do so only in controlled, non- production environments for defensive research. References Jamal Al-Karaki, Muhammad Al-Zafar Khan, and Mar- wan Omar. 2024. Exploring LLMs for malware de- tection: Review, framework design, and countermea- sure approaches. Preprint, arXiv:2409.07587. Anthropic. 2025. Introducing claude haiku 4.5.https: //w.anthropic.com/news/claude-haiku-4-5. Largelanguagemodel(claude-haiku-4-5); accessed June 2026. Avast Software. 2024. RetDec: A retargetable machine- code decompiler.https://github.com/avast/ retdec. Ying Cao, Ruigang Liang, Kai Chen, and Peiwei Hu. 2022. Boosting neural networks to decompile op- timized binaries. In Proceedings of the 38th An- nual 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 Interna- tional 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 de- tection 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 Tech- niques. Ph.D. thesis, Queensland University of Tech- nology. 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. 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. 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. 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. 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 Com- puter Science. Springer. Gemini Team, Google DeepMind. 2025. Gemini 2.5: Pushing the frontier with advanced reasoning, multi- modality, 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 vulner- ability detection: An experimental study. Preprint, arXiv:2412.18260. JongHyup Lee, Thanassis Avgerinos, and David Brum- ley. 2011. TIE: Principled reverse engineering of types in binary programs. In Proceedings of the Net- work and Distributed System Security Symposium (NDSS). Junyou Li, Qin Zhang, Yangbin Yu, Qiang Fu, and De- heng Ye. 2024. More agents is all you need. Trans- actions on Machine Learning Research (TMLR). 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 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 vul- nerability analysis in decompiled binaries. Preprint, arXiv:2411.04981. National Security Agency. 2019.Ghidra soft- ware reverse engineering framework.https:// ghidra-sre.org . Version 12.1,https://github. com/NationalSecurityAgency/ghidra. OpenAI.2026.IntroducingGPT-5.4mini andnano.https://openai.com/index/ introducing-gpt-5-4-mini-and-nano/ . Large language model; accessed June 2026. Constantinos Patsakis, Fran Casino, and Nikolaos Lyk- ousas. 2024. Assessing LLMs in malicious code deobfuscation of real-world malware campaigns. Ex- pert Systems with Applications, 256:124912. Saman Pordanesh and Benjamin Tan. 2024.Ex- ploring 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. Brandon J. Walton, Mst Eshita Khatun, James M. Ghawaly, and Aisha Ali-Gombe. 2025.Explor- ing large language models for semantic analysis and categorization of android malware. Preprint, arXiv:2501.04848. Junlin Wang, Jue Wang, Ben Athiwaratkun, Ce Zhang, and James Zou. 2024.Mixture-of-agents en- hances large language model capabilities. Preprint, arXiv:2406.04692. 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 Inter- national 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 mal- ware detection via multi-view prompt engineering. Expert Systems with Applications, 262:125546. A Popular Decompilers Table 3 presents four of the most popular open- source and proprietary decompilers used in indus- try. DecompilerAvailability / Cost GhidraFree, open source (NSA) RetDecFree, open source (Avast) IDA Pro (Hex-Rays) Paid, proprietary; freeIDA Freetier for evaluation Binary Ninja (Vector 35) Paid, proprietary; free cloud tier and Free edition for evaluation/education Table 3: Representative C decompilers and their avail- ability. Tool-specific naming and type-recovery heuris- tics can produce divergent renderings of the same func- tion. 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 sam- ple identifier, ground-truth label, behavioral anno- tations, 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 ob- ject sizes differ across classes, the decompiled in- puts 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. MetricMaliciousBenign Source lines261 (20–2030)— Compiled (bytes)6,128 (1.3k–30k)16,468 (16.0k–17.0k) Ghidra (bytes)12,705 (1.5k–280k)10,802 (7.2k–69k) RetDec (bytes)14,374 (0.4k–142k)9,186 (5.2k–54k) 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 lower- cost models, since industrial malware triage may re- quire running inference over large volumes of bina- ries and decompiler views. For reference, we also evaluateGemini 2.5 Pro, a larger model from the same family asGemini 2.5 Flash-Lite. Table 5 shows that the larger model performs strongly from a single decompiler view, with RetDec alone reach- ing the bestF 1 . However, multi-view prompting substantially closes the gap between the lower-cost and larger Gemini models:Flash-Liteimproves from75.0 F 1 with its best single view to88.9with both views, reducing the gap toGemini Pro’s best result from15.3points to1.4points. 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. Setting Gemini Flash-Lite Gemini Pro Ghidra only 75.0 ±2.4 83.7 ±0.7 RetDec only 73.4 ±3.1 90.3 ±1.4 Multi-view 88.9 ±2.0 85.4 ±0.8 Consensus 81.0 86.7 Table 5: Malicious-classF 1 (%) for Gemini models. Subscripts denote standard deviation over five runs where applicable.Gemini Prois included as a larger- model reference point. Multi-view prompting lets the lower-costFlash-Litemodel 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 thex-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 on thex-axis; single-example families (n=1) are high-variance and shown for completeness only. E Prompt Templates We use a definition-only prompt for the main exper- iments. It defines malicious and benign behav- ior without listing concrete malware indicators, to avoid steering the model toward particular at- tack families or surface patterns. In the single- decompiler setting, the user message contains one decompiled pseudo-C view. In the multi-view set- ting, the same definition is used, but the user mes- sage 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 mirai (n=13) mydoom (n=13) hellbot (n=8) dexter (n=5) carberp (n=3) x0r (n=2) remhead (n=2) minipig (n=1) rubilyn (n=1) rovnix (n=1) synthetic_keylogger (n=1) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Recall 69%69% 100%100% 67% 100%100%100%100%100% 77% 85% 75% 100% 67% 100% 50% 100%100%100% 69% 92% 100%100% 67% 100%100%100%100%100% Per-family malware recall Claude Haiku 4.5 Ghidra RetDec Combined Figure 3: Per-family recall — Claude Haiku 4.5. mirai (n=13) mydoom (n=13) hellbot (n=8) dexter (n=5) carberp (n=3) x0r (n=2) remhead (n=2) minipig (n=1) rubilyn (n=1) rovnix (n=1) synthetic_keylogger (n=1) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Recall 54% 46% 50% 100% 33% 100% 50% 100%100%100%100% 69%69% 60% 33% 100% 50% 100%100%100%100% 69% 85% 62% 100% 67% 100%100%100%100%100%100% Per-family malware recall Gemini 2.5 Flash-Lite Ghidra RetDec Combined Figure 4: Per-family recall — Gemini 2.5 Flash-Lite. mirai (n=13) mydoom (n=13) hellbot (n=8) dexter (n=5) carberp (n=3) x0r (n=2) remhead (n=2) minipig (n=1) rubilyn (n=1) rovnix (n=1) synthetic_keylogger (n=1) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Recall 54% 46% 62% 100% 33% 100%100%100%100% 77%77% 12% 100% 67% 100% 50% 100%100%100% 62% 85% 100%100% 33% 100%100%100%100%100%100% Per-family malware recall Llama 3.3-70B Ghidra RetDec Combined Figure 5: Per-family recall — Llama-3.3-70B-Instruct. mirai (n=13) mydoom (n=13) hellbot (n=8) dexter (n=5) carberp (n=3) x0r (n=2) remhead (n=2) minipig (n=1) rubilyn (n=1) rovnix (n=1) synthetic_keylogger (n=1) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Recall 62% 54% 62% 100% 67% 100% 50% 100%100%100% 62% 23% 25% 100% 67% 50%50% 100%100%100% 62% 38% 62% 100% 67% 100%100%100%100%100% Per-family malware recall Qwen3.6-35B Ghidra RetDec Combined Figure 6: Per-family recall — Qwen3.6-35B-A3B. mirai (n=13) mydoom (n=13) hellbot (n=8) dexter (n=5) carberp (n=3) x0r (n=2) remhead (n=2) minipig (n=1) rubilyn (n=1) rovnix (n=1) synthetic_keylogger (n=1) 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Recall 54% 38% 38% 100% 67% 50% 100%100%100%100% 54% 23% 25% 60% 33% 100% 50% 100%100%100% 54%54% 62% 100% 67% 100%100%100%100%100% Per-family malware recall GPT-5.4 Mini Ghidra RetDec Combined Figure 7: Per-family recall — GPT-5.4-mini. maliciousbenign RetDec prediction benign malicious Ghidra prediction 25 25M · 0B 8 8M · 0B 0 0M · 0B 67 17M · 50B Agreement Disagreement Malicious (true) Benign (true) (a) Qwen3 maliciousbenign RetDec prediction benign malicious Ghidra prediction 24 24M · 0B 6 6M · 0B 10 10M · 0B 60 10M · 50B Agreement Disagreement Malicious (true) Benign (true) (b) Llama maliciousbenign RetDec prediction benign malicious Ghidra prediction 36 36M · 0B 4 4M · 0B 4 4M · 0B 56 6M · 50B Agreement Disagreement Malicious (true) Benign (true) (c) Haiku maliciousbenign RetDec prediction benign malicious Ghidra prediction 22 22M · 0B 8 8M · 0B 7 7M · 0B 63 13M · 50B Agreement Disagreement Malicious (true) Benign (true) (d) Flash-Lite maliciousbenign RetDec prediction benign malicious Ghidra prediction 21 21M · 0B 7 7M · 0B 1 1M · 0B 71 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 Ap- pendix 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 decom- piled code itself. To estimate how much headroom a more guided prompt can provide, we also eval- uate the indicator-guided prompt in Appendix 10 onGemini 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 deploy- able 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. SettingDefinition-onlyIndicator-guided Ghidra only75.088.9 RetDec only73.490.1 Multi-view88.985.1 Consensus81.086.4 Table 6: Malicious-classF 1 (%) forGemini 2.5 Flash-Liteunder the definition-only and indicator- guided 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.