Devirt offers an automated devirtualization service for malware analysts whose samples hide their logic inside a protector's virtual machine. Upload an authorized sample, and Devirt returns the recovered functions as an IDA database or annotated pseudocode, with a coverage ledger of what was checked. Standard automated jobs have a 24-hour SLA, each sample is processed in an isolated environment, and input deletion begins once processing finishes.
Create an account first, then upload in your workspace. If your file needs manual review, we email a written quote before paid work begins. Upload a file of up to 500 MiB and see the scope and the total before you pay. Compare the published price list.
For authorized analysis · Updated
Why does VM-protected malware defeat a decompiler?
VM-protected malware defeats a decompiler because code virtualization rewrites selected functions as bytecode for a private virtual machine that the protector embeds in the sample. Decompilers such as the Hex-Rays decompiler are built for the instruction sets of real processors, such as x86 and x64, so on a virtualized function they show the virtual machine's interpreter instead of the malware's logic.
Malware authors use the same commercial protectors that software vendors do. MITRE ATT&CK lists this under sub-technique T1027.002, Software Packing, which covers virtual machine software protection, and its procedure examples include tracked groups that protected their malware with VMProtect or Themida.
Does every protected sample need devirtualization?
Not every protected malware sample needs devirtualization. ANY.RUN's 2024 analysis of five malware families protected with Themida or VMProtect found that almost all of them skipped virtualization: the malware code itself was largely unprotected beyond the first compression and decryption stages. Devirtualization matters when the functions you have to explain are themselves virtualized; a sample that is only packed or obfuscated still fits protected binary analysis, which covers all three kinds of protection.
Unpacking undoes the packing layer, but a virtualized function stays bytecode, run by the interpreter, until devirtualization recovers its logic. Illustration, not a measured result.
You do not have to identify the protector first. Choose auto-detect at upload: a recognized, eligible build follows the automated path, and an unfamiliar build can get a free assessment and a written offer before any payment. The VMProtect unpacking vs devirtualization comparison explains why unpacking alone leaves virtualized functions unreadable.
What does a malware analyst get back?
Devirt returns the output you select, together with the coverage ledger and a proof summary. Four formats cover most malware work.
Devirt output formats for malware analysis
Format
What it contains
Use it to
IDA database (.i64)
Proven functions, named imports, typed API calls and the coverage ledger
Keep investigating the sample in IDA
Annotated pseudocode (.c)
Readable C with semantic naming and function-level commentary
Read and quote the recovered logic
Full RE report (.pdf)
Architecture, behavior, identity surfaces and an executive summary
Brief incident leads and decision-makers
API JSON (.json)
Structured findings and coverage
Feed your own tracking and detection pipelines
For a behavioral account of a whole sample, protected or not, the malware analysis service reports file, process, persistence, network and import behavior, with its analysis bounds stated.
How does the evidence work?
Every Devirt result carries a coverage ledger, so an incident note can say which functions were proven and which stayed open. The ledger places every in-scope unit in one of four states: proven, runtime-dependent, unresolved or permanently bounded.
For malware, the runtime-dependent state matters: behavior that depends on a real input, key or environment stays marked instead of disappearing from the report. The three kinds of check explains what counts as proof.
Every in-scope function in a Devirt result ends in exactly one of four states, and the four states always add up to the functions counted. Illustration, not a measured result.
Questions malware analysts ask
How are live malicious samples handled?
Recovery observes the sample's execution in an isolated environment, and Devirt's data-handling policy requires analysis infrastructure to be network-isolated during execution. Samples are processed only for the analysis you requested: they are not shared between customers, used to train models or added to the curated library, and input deletion begins once processing finishes and the output is available. Processing audit records are kept for 90 days, and you can request your own processing log.
Which protectors does Devirt cover?
The automated path covers VMProtect 2.x and 3.x and Themida and Code Virtualizer. Loki-based virtual machines require a separate free assessment for every binary, including Obfuscator X and Griffin. Samples protected with Enigma Protector, a .NET virtualizer or a commercial packer start with a free assessment. Recognition is decided at intake, and a sample with a custom VM or several protection layers gets a separate assessment. The supported protectors list shows where each family starts.
Can I submit samples I did not write?
Yes, for defensive work. Malware analysis and defensive threat intelligence are accepted use cases under the acceptable use policy. Deploying or improving malware is prohibited, and Devirt can decline a job or ask you to clarify its scope.
How fast is a result?
Standard automated jobs have a 24-hour SLA from confirmed payment, and eligible jobs can run express with a one-hour SLA. The portal, email and an optional signed webhook tell you when the result is ready.
