AI Decompiler Workflows for Agents, and Where They Stall

An AI decompiler is a language model wired into a decompiler or disassembler that rewrites assembly or pseudocode as readable code, renames variables and explains what functions do. In November 2026 most developers meet one of three setups: a plugin inside the decompiler they already use, a model trained specifically on compiled code, or an agent that drives those tools through the Model Context Protocol (MCP).

About Devirt: Devirt recovers the code that protectors such as VMProtect and Themida hide inside their own virtual machines, for files you own or are authorized to analyze. You get an IDA database and annotated pseudocode, with a ledger showing which functions were proven. If nothing is proven, you pay nothing. Start with a free assessment.

This post maps the AI decompiler tools people use, shows how an agent sits on top of them, and covers the place every one of these workflows stalls: functions protected by a virtual machine. It ends with a read-only way to hand an agent results it can trust, using an MCP server with six read tools and no write access at all.

What is an AI decompiler?

An AI decompiler is the model-driven layer on top of classic decompilation. Ghidra, IDA Pro's Hex-Rays decompiler and Binary Ninja turn machine code into pseudocode using rules: control-flow recovery, type inference, signature libraries. An AI decompiler takes that pseudocode, or the raw assembly, and predicts what a human would have written.

In practice that means three jobs:

• Naming: sub_401A30 becomes parse_header, local_28 becomes buffer_len.
• Restructuring: goto ladders become loops, nested conditions get flattened.
• Explaining: a summary of what the function appears to do, often with comments inline.

All three are predictions. They're often good, and they're never proof.

The AI decompiler tools people use

AI decompiler tools fall into three groups: plugins that add a model to your existing decompiler, models trained to decompile assembly, and hosted platforms that pair a decompiler with an agent.

If you're picking one, the plugin route (DAILA or Decai) keeps everything inside the tool you already know. The hosted routes trade some control for convenience and a shared workspace.

How an agent drives a decompiler over MCP

An MCP-based workflow exposes analysis tools, such as a disassembler, decompiler or debugger, as functions an AI agent can call. The agent asks for the function list, opens a function, reads the pseudocode, renames symbols and keeps going until it can answer your question. NowSecure describes the same pattern in r2ai's auto mode, where the model "plans, executes radare2 commands and analyzes their output."

The loop looks like this:

you:    "What does this binary do with the config file it reads at startup?"
agent:  list functions → find candidates by strings and xrefs
agent:  decompile candidate → read pseudocode → rename → summarize
agent:  follow calls → repeat
agent:  answer, with the functions it relied on

It works well on ordinary compiled code. It works badly in two places.

Where AI decompilers stall

Stripped binaries and invented names

With no symbols, every name the agent produces is a guess. The guess then steers the next step. If the model decides a field is timeout when it's a retry counter, the summary built on top inherits the mistake, and nothing in the output marks it.

A made-up example shows how quietly this happens. The decompiler prints:

if (*(int *)(ctx + 0x18) > 3) {
  FUN_00402210(ctx);
  return 0xffffffff;
}
*(int *)(ctx + 0x18) = *(int *)(ctx + 0x18) + 1;

The AI rewrite reads well:

if (session->timeout_seconds > 3) {
    close_session(session);
    return -1;
}
session->timeout_seconds++;

A field that's compared against 3 and incremented once per call is far more likely to be an attempt counter than a timeout in seconds. And close_session is a guess about a function the agent hasn't opened yet. Each name is plausible on its own. Together they produce a confident, wrong story about why the function returns -1. The pseudocode was correct the whole time. The interpretation drifted.

The practical defense is to make the agent keep two lists: what it read directly (constants, calls, control flow) and what it named or inferred. Summaries should only be built from the first list unless something has checked the second.

VM-protected functions: the dispatcher problem

AI decompilers stall completely on VM-protected functions because there's no original logic left to read. Protectors such as VMProtect and Themida compile the protected function into bytecode for a private virtual machine. The binary keeps an interpreter: a dispatcher loop that fetches the next bytecode instruction and a table of handlers that execute it.

Decompile that and you get a perfectly accurate decompilation of the interpreter. Hand it to a model and you get a perfectly reasonable explanation of a dispatcher. Neither tells you what the protected function computes.

A 2026 review of agentic reverse-engineering systems lists obfuscation among the cases where these systems still fail. Devirt's reverse engineering MCP guide walks through where that happens inside an agent workflow. The agent can identify the protector, trace the unprotected code around it and describe the VM. The function stays bytecode until it's devirtualized.

Giving the agent something it can trust

The fix for both failure modes is the same: give the agent inputs that carry their own evidence, so it can tell checked facts from guesses.

Devirt's approach is to recover the protected scope and label every in-scope function with one of four states:

• Proven: the accepted check supports the stated behavior within the declared scope.
• Runtime-dependent: the result needs runtime evidence before an agent should treat it as settled.
• Unresolved: the available evidence didn't establish the behavior.
• Permanently bounded: the question is outside the accepted model or artifact boundary.

A coverage ledger keeps facts, inferences and unknowns separate. An agent reading that ledger can cite "proven" functions and flag the rest, instead of turning an unresolved path into a claim.

Wiring a read-only result source into your MCP client

The Devirt MCP server (@devirt/mcp-server on npm) is a read-only MCP server. It lets your agent read Devirt assessments, jobs, coverage ledgers and completed results, next to whatever other MCP tools you use. It needs Node 22 or later and a separately scoped read-only API key from your Devirt workspace.

The setup steps and the config block for your MCP client are in the package README on npm. It needs a Devirt API key; keep the key out of prompts and source control.

The server exposes six tools:

devirt_get_capabilities
devirt_list_assessments
devirt_get_assessment
devirt_list_jobs
devirt_get_job
devirt_get_result

Responses come back in a versioned structuredContent envelope (devirt.mcp.v1). The server also exposes account-scoped assessment, job and coverage-ledger resources.

What the agent can and can't do with it

The Devirt MCP server is deliberately narrow. A tool that can only read can't be talked into uploading something.

It can:

• list your assessments and jobs
• open an individual record
• fetch a completed result, including the coverage ledger and proof states

It can't:

• upload a binary
• submit a job
• accept an offer
• start checkout
• run a hosted model

Upload, authorization, scope approval and payment all happen in your Devirt account, not through an agent tool. Your model stays your model: Devirt is not an AI model, and you can revoke the key from workspace settings whenever you choose.

A workflow that holds up

Put together, the setup that survives contact with real binaries looks like this:

1. Orient with the AI decompiler. DAILA, Decai or your agent maps functions, strings and the question you're stuck on.
2. Find the blocked boundary. If the function you need sits behind a VM protector, the agent will keep describing a dispatcher. That's your signal.
3. Recover and check the protected scope. For a file you own or are authorized to analyze, upload it and get a feasibility decision and scope. The recovered functions come back with proof states.
4. Continue with evidence. Your MCP client reads the result, and the agent picks the investigation back up from checked functions.

Questions developers ask

Is AI good at decompiling?
AI is good at readability and weak at correctness. In a decompiler workflow a language model is most useful for naming, summarizing and navigating functions. It's least reliable when it has to infer behavior the assembly doesn't show: types, indirect calls, virtualized code. Treat AI decompiler output as a lead to verify, not a finding.

Can an AI decompiler handle VMProtect or Themida?
It can describe the protector's virtual machine, not the protected logic. The function has to be devirtualized first. After that, an AI decompiler is useful again for explaining the recovered code.

Do I have to use a specific agent?
No. Any MCP-compatible client can register the server. It sits beside REA, IDA, Ghidra or Binary Ninja integrations, or your own model pipeline.

Is decompiling legal?
It depends on the jurisdiction, the software license and the purpose, and using AI doesn't change that. Devirt only accepts files you own or are authorized to analyze, and it doesn't remove DRM, bypass license checks or crack software.

If you want to try the handoff, Devirt's AI reverse engineering page covers the agent workflow and the free triage. Start there before you upload anything.