Decompiler Output as Attack Surface: AI Reverse Engineering Faces Prompt Injection Threats

Give an AI agent a stripped binary, then trust the analysis summary it produces—this seemingly efficient workflow is being cracked open by a study: strings embedded in C programs can pass through the decompilation process of tools like Ghidra and land intact in the context window of LLM-based reverse engineering agents. The binary is no longer just data; it is a prompt.

When decompiler output becomes instructions

This is not an entirely new vulnerability class. Since people began feeding external input into LLMs, prompt injection has been the soft underbelly of LLM applications. Chat agents reading web pages, email assistants summarizing inboxes, coding agents digesting PRs—similar stories have played out repeatedly.

The real novelty lies in the pipeline: decompiled code. For decades, the security and reverse engineering community has treated it as a technically adversarial but functionally trustworthy artifact. Malware analysts of course know the binary in front of them is hostile, but the pseudo-C code, recovered strings, and control flow graphs produced by decompilers have always been regarded as faithful, inert representations. You read it, reason about it, and don't worry that it might do something back to you.

Now, that output is fed directly into an LLM agent (the study used Cline paired with GhidraMCP and Qwen3-8B), becoming part of the model's reasoning context. The trust boundary that used to exist between "the binary" and "the analyst's brain" has been quietly replaced by "the binary" and "the LLM context window"—and no one updated the threat model.

Ghidra and GhidraMCP

Ghidra is an open-source reverse engineering framework from the U.S. National Security Agency (NSA), offering disassembly, decompilation, symbol recovery, and more, widely used in malware analysis and vulnerability research. Its decompiler can restore machine code into fairly readable pseudo-C code. GhidraMCP is an extension based on the Model Context Protocol (MCP) that exposes Ghidra's analysis capabilities to LLM agents, enabling the model to invoke operations such as decompilation, function queries, and string reading. MCP was proposed by Anthropic to standardize how LLMs connect to external tools and data sources, allowing agents to call tools safely. In this study, Cline serves as the agent framework, connecting to Ghidra through GhidraMCP and feeding decompiler output directly into Qwen3-8B's context, thereby forming the attack surface.

Prompt Injection

Prompt injection refers to a security issue in which an attacker plants malicious instructions into an LLM's input to induce the model to deviate from its original task and perform unintended actions. It resembles SQL injection in traditional web security, but targets LLM architectures where natural language instructions and data are not strictly separated. Common forms include direct injection (user input containing malicious instructions) and indirect injection (instructions planted through external content such as web pages, documents, or code). In reverse engineering scenarios, if strings embedded in a binary contain instruction-like text, the model may mistake them for instructions to follow rather than data to analyze, resulting in logic hijacking. There is currently no fully reliable general defense; main mitigations include input sanitization, instruction-data separation, and output validation.

It's logic hijacking, not RCE

We need to honestly define the boundaries of this issue. According to current descriptions, it is not an exploit against Ghidra itself, nor remote code execution on the analyst's machine. It is a form of logic hijacking: making the AI agent misreport, mislead, or redirect its own analysis because it cannot distinguish between "data I should analyze" and "instructions I should follow."

That distinction sounds subtle, but just recall: this is exactly the unsolved problem for every LLM-integrated tool today.

What is underestimated is the blast radius of the "trusted input" assumption. Every AI reverse engineering tool shipping today—malware triage, firmware analysis, vulnerability discovery—makes the same implicit bet: decompiler output can be handed to the model without sanitization. This bet has never been examined; it was simply inherited from the pre-LLM era. Back then, humans did the reasoning, and humans (mostly) don't get "prompt injected" by strings in a disassembly listing.

What is overestimated is novelty. Two upvotes and zero comments on Hacker News indicate that discussion has not caught up with the implications, not that the implications are small. It is still the same prompt injection story, just in a different costume. The costume matters because of who is in the room: security researchers are precisely the people most likely to deliberately use such agents on such hostile inputs every day.

Distinguishing logic hijacking from RCE

Logic hijacking refers to an attacker manipulating an AI agent's reasoning process so that it outputs incorrect conclusions or executes unintended logic, without directly gaining code execution privileges. Remote code execution (RCE), by contrast, is when an attacker exploits a vulnerability to run arbitrary code on a target system, a higher severity level. In this case, the attacker does not need to exploit a software vulnerability in Ghidra or the agent framework; they only need to embed specific strings in the binary to influence the LLM's analysis conclusions, which constitutes manipulation at the logic level. This attack does not change the actual execution behavior of the malware, nor does it directly control the analyst's machine, but it may mislead security decisions, for example by misclassifying malware as benign. Its harm lies in breaking the chain of trust, not in the loss of system control.

Impact on the AI reverse engineering toolchain

If you are building or procuring AI-assisted reverse engineering tools, decompiler output must be treated like any other untrusted, attacker-controlled LLM input. That means sanitizing before it reaches the model, strictly separating "content to analyze" from "instructions to follow" (which no one has fully solved), and maintaining skepticism toward AI-generated analysis summaries of any binary that isn't self-compiled.

Malware authors have long fought human analysts through obfuscated strings and packing. Adding prompt injection payloads aimed at AI analysts is the logical and cheap next step, and it requires no change to how the malware actually executes. It is a free attack on the tool, not on the target.

For the broader industry, this is another data point in the same pattern: whenever we bolt an LLM onto an existing trust boundary, that boundary needs to be re-examined from scratch rather than inherited from the previous tool.

Input sanitization and instruction-data separation

Input sanitization refers to filtering, escaping, or restructuring external data before feeding it into an LLM, in order to remove or isolate content that could be interpreted as instructions. In reverse engineering scenarios, strings in decompiler output can be escaped, explicit data boundary markers added, or structured formats (such as JSON) used to distinguish data from instructions. Instruction-data separation is a more fundamental solution aimed at enabling the model to clearly distinguish "content to analyze" from "instructions to follow," for example by emphasizing in system prompts that data is non-executable, using delimiters, or adopting a dual-model architecture (one model processes data, another executes instructions). However, due to the ambiguity of natural language, complete separation remains an open problem. Current practical mitigations include sandboxing untrusted input, restricting an agent's tool-calling permissions, and requiring human review of critical conclusions.

Open questions

When your AI reverse engineering agent reads a binary built specifically to deceive it, how do you know the summary it gives you isn't the malware's final payload?

This research comes from it4sec.substack.com, by Cor of Skyblue Soft. The core fact—that strings survive decompilation and enter the LLM context—currently relies mainly on a single-source demonstration and still needs more independent reproduction. But even so, the trust boundary question it raises is enough to make everyone deploying AI agents in security scenarios stop and inspect their own pipelines.

One-line Summary

Strings embedded in C programs can survive decompilation and enter the LLM context, turning the binary into a prompt and hijacking AI reverse engineering agents.

Paragraph Summary

The article reveals a new prompt injection risk targeting AI reverse engineering agents: strings embedded in C programs remain intact after decompilation by tools like Ghidra and are fed directly into the context window of an LLM (such as Qwen3-8B), making the binary itself the attack payload. This is not traditional RCE but logic hijacking—an attacker can make the AI agent misreport or mislead analysis conclusions without changing how the malware executes. Current AI reverse engineering tools generally inherit pre-LLM assumptions, treating decompiler output as trusted input handed to the model without sanitization. Security researchers, as heavy users of such tools on hostile inputs, have a concentrated exposure surface. Response directions include input sanitization, instruction-data separation, and skepticism toward AI-generated summaries.