Automated VMProtect devirtualization for files you are authorized to analyze: an IDA database and readable pseudocode, with every protected function accounted for in a coverage ledger.
VMProtect devirtualization is the recovery of readable program logic from functions that VMProtect has translated into bytecode for its own virtual machine. VMProtect runs that bytecode through an interpreter embedded in the protected file, so a disassembler shows the interpreter instead of the function. Devirt devirtualizes VMProtect 2.x and 3.x files as an automated service for authorized analysis, and reports every protected function in one of four proof states: proven, runtime-dependent, unresolved or permanently bounded.
Family recognition is an intake decision, not a guarantee for every build. Custom behavior and multiple protection layers can require a separate assessment.
Virtualization replaces ordinary instructions with a custom interpreter. Devirt recovers meaningful operations and program structure so you can investigate behavior in your own tools.
The delivery pairs readable output with a full ledger for the agreed scope. Proven, runtime-dependent, unresolved, and permanently bounded units remain distinguishable, including units that were never virtualized.
See how the checks workVMProtect devirtualization is for teams whose VMProtect reverse engineering stops at the virtual machine and who need to read VMProtect-protected code they are allowed to analyze: malware analysts and incident responders working on protected samples, security researchers auditing software within an authorized scope, software owners recovering the logic of their own protected builds, and interoperability engineers verifying compatibility.
VMProtect is a commercial protector that malware authors also use, so the same VMProtect analysis serves defenders and software owners. Every upload requires authorization to analyze the file.
VMProtect protects code in three ways: virtualization turns instructions into bytecode for a virtual machine, mutation replaces instructions with equivalent but more complex sequences, and Ultra mutates code and then virtualizes it. One protected file can mix all three with ordinary native code, and it can also be packed.
Devirt identifies the protection first, then treats each layer as a separate stage: unpacking for eligible packers, deobfuscation where supported transformations apply, and devirtualization of virtualized functions. The devirtualization stage reconstructs the virtual machine and its handler semantics, then reconnects virtual operations, branches and native exits into functions you can follow. Eligible operations receive formal checks before anything is called proven.
A VMProtect devirtualization result is delivered in the formats you choose, each with the coverage ledger and a proof summary. The IDA output is checked after it is saved and reopened.
Devirt counts the protected functions in scope before recovery starts and reports every one of them in one of four proof states, so a function that was not proven cannot drop out of the result. A counterexample or a timeout never counts as proof.
Unpacking a VMProtect file does not devirtualize it. VMProtect packing compresses the file and unpacks it in memory when the program starts, but virtualized functions never return to native instructions, so an unpacked file still hides its virtualized functions behind the virtual machine. Recovering those functions is the devirtualization step.
Devirt accepts only files you own or are authorized to analyze, and a supported VM family does not by itself establish permission to analyze a particular binary. The acceptable use policy prohibits unlawful circumvention and redistribution without rights.
Each file is analyzed in isolation, is never shared between customers and is not used for training. Confidentiality, EU requirements and exclusivity can be agreed before transfer.
One recovered program. Different ways to work with it. Inspect a teaching example, switch formats, and follow the link back to its evidence.
; Authored teaching VM, not vendor bytecode
00 LOAD32 r0, input.size
01 PUSH r0
02 PUSH 0x10
03 UGE
04 STORE p0
05 LOAD32 r1, input.magic
06 PUSH r1
07 PUSH 0x44565254
08 EQ
09 LOAD p0
10 AND
11 RET
#include <stdbool.h>
#include <stdint.h>
bool validate_record(uint32_t size, uint32_t magic) {
const uint32_t header_size = 16u;
const uint32_t expected_magic = 0x44565254u;
if (size < header_size) {
return false;
}
return magic == expected_magic;
}
Drag the divider to reveal the difference. Or choose a view above. Keyboard: arrow keys, Home and End.
Check the declared size. Check the type marker. Accept only when both checks pass.
Readable code explains the behavior. The ledger explains how far you can rely on it.
Original teaching material, not customer output. The IDA view illustrates a database's contents; it is not a downloadable .i64. No measured proof or service benchmark is claimed by these examples.
Standard automated jobs have a 24-hour SLA; eligible express jobs have a one-hour SLA. Novel engagements use an accepted offer, a 72–168 hour window, and senior review before release.
Compare starting pricesYes. Automated intake covers VMProtect 2.x and 3.x. Family recognition is an intake decision, not a guarantee for every build, and custom behavior or several protection layers can require a separate assessment before any work is agreed.
No. Devirt is a service: you upload a file you are authorized to analyze, Devirt identifies the protection and agrees the scope, and you receive the outputs you chose with the coverage ledger. The methods behind this work are explained in Devirt research.
Unpacking alone never removes VMProtect virtualization. Devirt identifies the protection at intake, and its analysis path includes a separate unpacking stage for eligible packers before devirtualization starts.
They stay in the result. Every protected function counted before recovery ends up proven, runtime-dependent, unresolved or permanently bounded, so you can see what the evidence covers and what it does not.
Standard automated jobs have a 24-hour SLA, and eligible express jobs have a one-hour SLA. Novel engagements use an accepted offer, a 72 to 168 hour window and senior review before release.
Devirt accepts a file only when you own it or are authorized to analyze it, for purposes such as security research, malware analysis, interoperability and compliance verification. The rules differ between jurisdictions and licenses, so confirm your own basis before uploading.
Yes. The site has a synthetic sample assessment that shows the report format: architecture signals, the proof plan, scope boundaries and the decision path. It is a public teaching sample built for the purpose, not a customer result.
Isolated analysis. No sharing between customers. No training on your upload. Your file is used only for the work you requested.
Read the data-handling policyIsolated processing
Not yet released
Recording the work
Input deletion follows delivery. This timeline shows the default 72-hour output window. Team outputs are kept for 30 days. Audit records have a separate 90-day window.
Policy illustration, not a live deletion certificate. Deletion is confirmed from provider receipts. Assessment inputs, unpaid jobs, and account/billing records have their own rules in the policy.
Start in your account. If your upload needs manual work, we review it and email you a written scope and quote before paid work begins.
Create an account, verify your email and upload your file. We review custom work and email your scope and quote.