Recover what a packed, obfuscated or virtualized executable does, for binaries you are authorized to analyze, with readable output and a ledger that states what was proven.
Protected binary analysis is the reverse engineering of an executable whose code was packed, obfuscated or virtualized to resist analysis, with the goal of recovering what that code does. It is a different job from the binary scanning used in software supply-chain security, which lists the components and known vulnerabilities inside a file. Devirt analyzes protected binaries you are authorized to study and returns recovered logic with a function-level ledger of what was proven.
Family recognition is an intake decision, not a guarantee for every build. Custom behavior and multiple protection layers can require a separate assessment.
A binary does not need virtualization to enter the automated analysis path. Devirt can reverse ordinary compiled programs, map their behavior and interfaces, and surface risk indicators for your authorized review.
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 workA protected binary is a program that a software protector has changed so that the usual disassemble-and-decompile workflow stops working. Each protection technique breaks a different step of that workflow.
Software composition analysis (SCA) and protected binary analysis both read compiled files, but they answer different questions. SCA identifies the open-source and third-party components in a binary, often as a software bill of materials, and checks them for known vulnerabilities and license issues.
Protected binary analysis asks what the program's own code does once the protection is taken into account: how a file format is parsed, what a license check or a malware sample does, or what a legacy component computes. No component database answers that, because the logic belongs to that one program.
The same question applies beyond desktop programs. For a kernel-mode driver, an anti-cheat driver audit documents what the driver monitors, collects and exposes, for teams authorized to audit it. For a protection scheme, rights holders commission a review of their own DRM design to see which modules are protected and what they call. In the browser, virtualized JavaScript hides a script's logic inside a custom interpreter, the way a native VM protector hides a function.
Protected binary analysis combines three kinds of evidence. Static analysis reads the file on disk and can cover paths no test run takes. Dynamic analysis observes the program while it runs and sees real values, but only on the paths a run takes.
Devirtualization is the stage for code inside a protector's virtual machine. Unpacking alone does not make virtualized functions readable, because the bytecode never turns back into native instructions. Devirtualization recovers the logic those functions carry.
A protected binary analysis from Devirt delivers the recovered work in the formats you choose, together with the coverage ledger for the agreed scope.
Every Devirt result places each unit in the agreed scope in one of four states, so nothing drops out of the count. Proven means verification evidence exists within a declared scope. Runtime-dependent means a known real input or environment state is still needed. Unresolved means the unit was inspected but the evidence did not settle it. Permanently bounded means the unit lies outside an explicit analysis limit.
The four states add up to the total, and a counterexample or a timeout is never counted as proof. Readable output and proof stay linked, so you can check any recovered function against its state before relying on it.
Protected binary analysis recovers what compiled code does, not the source code it came from. Names, comments and project structure that compilation discarded do not come back, so recovered pseudocode is a new description of the program.
Some functions depend on inputs or environment states that no analysis observed, and those stay runtime-dependent or unresolved in the ledger instead of being reported as recovered. Unfamiliar builds and multiple protection layers can need a written assessment before work starts.
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 pricesProtected binary analysis is used for authorized work such as malware research, security audits, interoperability and the recovery of software you own. Devirt requires that you own, or are authorized to analyze, every binary you submit, and its acceptable use policy prohibits unlawful circumvention and redistribution without rights.
Each Devirt analysis runs in an isolated service with no shared customer state, and uploaded samples are not used to train models or shared between customers. Released output is retained for 72 hours by default or 30 days on Team, and processing audit logs for 90 days.
A Devirt result reports the functions it could not prove as runtime-dependent, unresolved or bounded rather than hiding them. If an automated job fails or misses its service level, used credits are returned and the per-job cash refund is requested automatically.
Protected binary analysis starts from auto-detection, which lets the processor identify the VM family. Novel or unfamiliar builds get a free assessment first, with estimated coverage, a timeline and a written quote before you decide.
No. Protected binary analysis recovers the logic of compiled code, not its original source. Names, comments and file structure that the compiler discarded cannot be restored by any analysis.
Standard automated Devirt jobs have a 24-hour service level, and eligible express jobs a one-hour service level. Novel engagements use an accepted offer, a 72 to 168 hour window and senior review before release.
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.