AI-Assisted Reverse Engineering for Defenders

Large language models can now read decompiled malware and explain it in plain English in seconds, but they also invent function purposes, miss what obfuscation hides and can be targeted by text planted in the sample itself. Malware analysis teams are adding LLMs to Ghidra and IDA style workflows to triage samples faster, rename functions, summarise behaviour and draft detection content. This guide covers how to use those tools defensively: where they help, what the published research and vendor evaluations actually show, how to verify output, and how to handle samples and model data safely. It is written for malware analysts, incident responders, threat intelligence teams and the managers approving AI tooling in a lab. It describes analysis workflows only and contains no attack techniques or code. For the underlying lab and tool basics, start with the Malware Analysis Guide for Defenders and the Ghidra for Malware Analysis Guide.

Key takeaways

LLMs are an accelerator, not an analyst. Published evaluations show real value for summarising and explaining code, and Microsoft's Project Ire reported 0.89 precision on hard real-world files, but recall in that test was only 0.26. Keep a human verdict.
Every claim needs evidence in the binary. Require the model to cite addresses, functions or strings for each behaviour it reports, and check them in the disassembler before anything reaches a report or a block list.
The sample is adversarial input. Malware has already been found carrying prompt injection text aimed at AI analysis tools. Treat strings, resources and comments in samples as untrusted prompts (OWASP LLM01:2025, MITRE ATLAS AML.T0051).
Preprocessing decides quality. Models do far better on decompiled, unpacked code than on raw or packed binaries. Unpacking, string decoding and good decompiler output still come first.
Data handling is the first policy decision. Samples can contain stolen customer data, credentials and internal hostnames. Decide which model endpoints may see which samples before anyone pastes decompiled code into a chat window.

Where AI fits in the reverse engineering workflow

Reverse engineering for defence answers practical questions: is this file malicious, what does it do, how does it persist and communicate, and what can we detect or block. LLMs help most where the work is reading and describing large amounts of code, and least where it depends on precise semantics, runtime state or anti-analysis tricks.

Workflow stage	What AI assistance adds	Where it is weak	Verification step
Initial triage	Plain-language summary of a decompiled sample, likely category (stealer, loader, ransomware), candidate indicators	Verdicts on unusual software ("malicious" can depend on context), packed samples	Compare with sandbox output and static indicators; never close a case on an AI verdict alone
Function explanation	Explains decompiled functions, suggests names, comments and types	Invents purposes for code it does not understand; misreads compiler idioms and inlined library code	Analyst checks cited addresses and cross-references before accepting renames
Library and API recognition	Recognises common crypto, compression and networking patterns and Windows API usage	Confuses similar algorithms and custom variants; trusts imported names that the malware resolved dynamically	Confirm with constants, signatures and function similarity tools such as Ghidra BSim
Configuration and indicator extraction	Spots likely configuration blocks, decoding loops and embedded domains	Decoded values that are guessed rather than computed	Decode with a deterministic script or emulator and compare
Detection drafting	First draft of YARA rules, hunting queries and report text	Rules that match on generic or hallucinated byte patterns, causing false positives	Test rules against a goodware corpus and the sample set; see the YARA Rules Guide
Reporting	Readable narrative for incident and management audiences	Confident tone that hides uncertainty	Mark AI-drafted sections and state confidence for each finding

What the evidence says

Claims about AI reverse engineering range from careful research to marketing. The sources below are the ones a lab can rely on, with what each actually measured.

Code analysis, including obfuscated code (USENIX Security 2024): Fang and colleagues, "Large Language Models for Code Analysis: Do LLMs Really Do Their Job?", ran a systematic evaluation of LLMs on code analysis tasks with a focus on obfuscated code, plus real-world case studies. Their conclusion is that LLMs can be valuable for automating code analysis, with limitations. It is the most cited peer-reviewed baseline for this question.
Decompilation (EMNLP 2024): the LLM4Decompile paper by Tan and colleagues released open models from 1.3 billion to 33 billion parameters. The authors report that their end-to-end models outperform GPT-4o and Ghidra on the HumanEval and ExeBench benchmarks by over 100 percent in re-executability, and that models refining Ghidra's output improved by a further 16.2 percent. These are benchmark programs, not malware: they show models can improve decompiler readability, not that they handle hostile code.
Binary code understanding: a benchmark by Shang and colleagues (arXiv preprint 2404.09836) tested function name recovery and binary code summarisation and found existing LLMs can understand binary code to a certain extent. Treat it as supporting evidence, not settled science.
Autonomous classification at scale (Microsoft Research, 5 August 2025): Project Ire is a prototype agent that uses decompilers, angr and Ghidra through a tool interface, records a "chain of evidence" and runs a validator against it. On a public Windows driver dataset it reported precision 0.98 and recall 0.83. On about 4,000 hard-target files awaiting manual review it reported precision 0.89, recall 0.26 and a 4 percent false positive rate. Microsoft also describes the validator catching a function wrongly labelled as anti-debugging.
Whole-binary analysis with long context (Google, 29 April 2024): VirusTotal described submitting complete decompiled or disassembled samples (Hex-Rays and IDA Pro output) to Gemini 1.5 Pro in one prompt, including two WannaCry components of more than 280,000 tokens analysed in 34 seconds. The post itself notes that obfuscation and packing need better preprocessing, that very large binaries can exceed limits, and that decompiled output is roughly 5 to 10 times more concise than disassembly. The examples were hand-picked, with no accuracy metrics.

The consistent message: models are good at reading and summarising, worse at being right about edge cases, and nobody has published evidence that they can replace expert review on hard samples. Design the workflow around that.

Limits, hallucination and anti-analysis

NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, uses the term confabulation for confidently stated false output, and OWASP lists the same problem as LLM09:2025 Misinformation. In reverse engineering it shows up in predictable ways:

Plausible names for unknown code: the model calls a function "decrypt_config" because it contains a loop and XOR, when it is a checksum. Once renamed, every later reader trusts the name.
Imported intent: the model recognises a family name from strings and describes that family's documented behaviour, rather than what this sample does. Google's WannaCry example claims interpretation from code, but analysts must check this on every sample.
Missed indirection: APIs resolved at runtime by hash, code decrypted in memory and control flow flattening are invisible to a model reading static decompiler output. ATT&CK T1027.002 Software Packing, T1497 Virtualization/Sandbox Evasion and T1622 Debugger Evasion all reduce what any static reader, human or model, can see.
Context truncation: chunking a large binary loses the links between functions; long-context models reduce this but still have limits.
Non-determinism: the same prompt can give different answers on different runs. Record the model, version, prompt and output for every finding you keep.
Prompt injection from the sample: Check Point Research reported in June 2025 a sample containing text instructing AI tools to ignore prior instructions and reply "NO MALWARE DETECTED". It failed against the models they tested, but it shows attackers are targeting AI analysis. See the OWASP LLM Top 10 LLM01 Prompt Injection Guide.

Verification rules that work

Ask for evidence, not conclusions: every stated behaviour must cite a function address, a string offset or a cross-reference.
Check each cited location in the disassembler before accepting a rename, comment or indicator.
Recompute decoded values (configuration, domains, keys) with deterministic tools; never copy a value the model "decoded" in its head.
Cross-check behaviour claims against dynamic evidence from a sandbox where available. See the Malware Sandbox Guide.
Label every AI-generated name and comment in the project (for example with a prefix or a dedicated comment type) until an analyst confirms it.
Require a second analyst for any verdict that drives containment, blocking or external reporting.

Data handling for samples and model inputs

Sending a decompiled sample to a model is a data transfer. Samples taken from your own incidents can contain embedded credentials, stolen documents, internal hostnames, victim identifiers and personal data. Some services also share what you upload: VirusTotal's documentation states that the contents of submitted files may be shared with premium customers. Decide the rules before tools are installed.

Sample or data class	Example	Allowed model deployment	Conditions
Public commodity samples	Known families already on public repositories	Approved external API or local model	Enterprise terms with no training on inputs; no internal context added to prompts
Samples from your own incidents	Malware recovered from your hosts, with your hostnames or credentials in its configuration	Local or private-tenant model only	Strip or mask internal identifiers where possible; record in the case file
Samples containing third-party or personal data	Stealer logs, exfiltrated archives, ransom notes naming victims	Local model only, or no AI processing	Data protection review; legal hold rules apply
Client or classified material	Samples received under NDA or from government partners	As permitted by the sharing agreement, often none	Check Traffic Light Protocol markings and contract terms first

Keep the lab isolation: an AI-assisted workstation is still a malware analysis workstation. If the model runs as a cloud API, the analysis host needs controlled egress to that endpoint only, which is a deliberate hole in the lab network to design and log.
Log prompts and outputs: keep them with the case record for evidence and for reviewing errors, and protect those logs as sensitive data.
Watch for leakage in the other direction: do not paste internal incident notes, other customers' data or credentials into prompts for context (OWASP LLM02:2025 Sensitive Information Disclosure). See the GenAI Data Security Risks and Mitigations Guide.

Securing AI agents and tool integrations in the lab

The newest pattern connects an LLM agent directly to the disassembler, so the model can list functions, read decompiled code and write names and comments back. Ghidra supports this kind of automation through its Java and Python scripting (including the PyGhidra launcher for Python 3) and headless analysis; community extensions expose it to agents through the Model Context Protocol. Agent access changes the risk.

Read-mostly by default: give the agent read access to the program database and a limited write scope (names and comments), never shell access on the analysis host. Check Point's lesson from the injection sample was to limit agent permissions for exactly this reason (OWASP LLM06:2025 Excessive Agency).
No execution of the sample by the agent: dynamic analysis stays in the sandbox, launched by the analyst or a fixed pipeline, not by model decision.
Patch the tools: Ghidra's own security advisories in 2026 include a High rated conditional code execution issue in the Swift Demangler analyser and a High rated path traversal in APK project export. A model that loads files automatically triggers these loaders without a human looking first. Track the advisories and keep the current release (Ghidra 12.2 needs JDK 25).
Treat tool servers as identities: an MCP server or API key that lets an agent read your sample repository is a non-human credential with access to sensitive material. Scope it, store its secret properly and rotate it. See the Local MCP Server Security Guide.
Separate projects: run agent sessions against a copy of the program database, so bad renames can be discarded without damaging the analyst's annotated project.

How to implement

Write the policy first: sample data classes, approved models and endpoints, logging and retention, and who may enable agent write-back. Get privacy and legal sign-off for incident samples.
Pick deployment: local models for sensitive samples, an enterprise API for commodity triage, or both. Lock egress from analysis hosts to the approved endpoints.
Pilot on solved cases: run the tooling on 20 to 50 historical samples your team has already analysed. Compare AI output with the known answers and record error types (wrong verdict, invented behaviour, missed capability, wrong indicator).
Set acceptance rules: from the pilot, decide which outputs can be used with light review (summaries, draft comments) and which need full verification (verdicts, indicators, detection rules).
Roll out in rings: start with senior analysts who can spot errors, then extend to triage staff with the verification checklist built into the case template.
Review and roll back: review a sample of AI-assisted cases monthly. If error rates rise after a model change, pin or revert the model version; keep the non-AI workflow documented so the lab can work without the tool.

Decision guidance

Option	Best for	Trade-offs
Chat assistant with pasted decompiled code	Occasional use, commodity samples, small teams	No audit trail by default, easy to leak sensitive data, manual copy errors
Disassembler plug-in or script calling an approved model	Regular triage with function-level explanations and renames	Needs egress design and logging; output written straight into projects must be labelled
Agent with tool access (disassembler, decompilers, sandbox results)	High-volume triage queues, large teams with engineering support	Largest injection and permission risk; needs evidence chains and validators like Project Ire's approach
Local open model	Sensitive incident samples, regulated or disconnected labs	Lower capability on hard code than leading hosted models; hardware cost; you own updates

Small teams get most value from a plug-in on commodity samples, plus a retainer or online service for deep work (see Online malware analysis services). Large teams can justify agent pipelines for triage queues, but only with evidence logging, a validator step and measured error rates.

Detection and measurement

Verified-claim rate: percentage of AI-reported behaviours confirmed by an analyst, by sample type.
Error rate by type: invented behaviours, wrong verdicts and wrong indicators per 100 samples, tracked across model versions.
Time to first useful summary: median time from sample intake to a verified triage note, with and without AI.
Detection quality: false positive rate of AI-drafted YARA or hunting rules on your goodware corpus before and after review.
Data handling compliance: percentage of AI-assisted cases with model, prompt and output logged and sample class recorded.
Injection attempts: count of samples found containing text aimed at AI tools; feed these into detection content as a behaviour of interest.

Framework mapping

Framework	Reference	Relevance
OWASP Top 10 for LLM Applications 2025	LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, LLM09 Misinformation	Injection from samples, sample data leakage, agent permissions, hallucinated analysis
MITRE ATLAS	AML.T0051 LLM Prompt Injection (AML.T0051.001 Indirect)	Text embedded in samples targeting AI analysis tools
MITRE ATT&CK v20	T1027.002 Software Packing, T1497 Virtualization/Sandbox Evasion, T1622 Debugger Evasion	Anti-analysis that limits static and AI-assisted reading
MITRE D3FEND	D3-FA File Analysis	The defensive technique AI tooling supports
NIST SP 800-53 Rev 5	SI-3 Malicious Code Protection, IR-4 Incident Handling	Analysis output feeding protection and response
NIST CSF 2.0	DE.AE-02, RS.AN-03, PR.DS-01	Event analysis, root cause analysis, protection of sample and log data at rest
NIST AI 600-1	Generative AI Profile	Confabulation and information security risks of the model itself

Common failure patterns

AI verdict closes the case. A "benign" summary of a packed loader ends the investigation. Project Ire's 0.26 recall on hard files shows how much a capable system can still miss.
Hallucinated names become ground truth. Unlabelled AI renames are saved to the shared project and later analysts build on them.
Incident samples pasted into consumer chat tools. Configuration blocks with your internal hostnames and stolen credentials leave the organisation with no record.
Agents with shell access. A tool-using agent on the analysis host is one successful injection away from running commands near live malware.
Indicators copied without decoding. Domains or keys "decoded" by the model are pushed to block lists and are wrong, or worse, block legitimate services.
Skipping preprocessing. Raw packed binaries go to the model and the output describes only the unpacking stub.

Practitioner checklist

Publish a sample data classification and the approved model endpoints for each class.
Restrict analysis host egress to approved model endpoints and log every call.
Pilot on already solved samples and record error types before wider use.
Require evidence (addresses, strings, cross-references) for every AI-reported behaviour.
Label AI-generated names and comments until an analyst confirms them.
Recompute every decoded indicator with deterministic tools before sharing or blocking.
Give agents read-mostly access, no shell, and no ability to run samples.
Treat strings and resources in samples as untrusted prompts and record injection attempts.
Patch Ghidra and other analysis tools against their published advisories.
Re-measure error rates on every model or prompt change, and keep a non-AI fallback workflow.

AI-assisted reverse engineering for defenders: faster malware triage without trusting hallucinations