How to evaluate a devirtualization result
before paying
Evaluating a devirtualization result before paying means checking what was promised, how it was counted and what happens when it falls short. Readable pseudocode is easy to show. It does not tell you whether the recovered code behaves like the original, or whether the functions your question depends on were in scope at all.
This guide lists the checks to make at three points: when you receive a written offer, when the result is released, and when you decide what to keep. It uses Devirt's terms, such as the four proof states and the 80% proven condition, but the questions work for any devirtualization service or tool.
What should you check before paying for devirtualization?
Before paying for devirtualization, check four things: the written offer names your file, the functions in scope, the outputs and the price; the coverage figure states its unit and its denominator; counterexamples and timeouts are reported outside the proven count; and a result that misses the agreed requirement is not released as a successful delivery. At Devirt, Full and Deep delivery require at least 80% proven coverage of the protected functions in the agreed scope.
Each of those checks has its own section below, followed by what no devirtualization result can give you and a short checklist to keep.
Does the written offer name your file and the functions you need?
A devirtualization offer should name the exact file, the work in scope, the outputs and the price. At Devirt, the written offer identifies all four before any paid work starts, and paid work begins only after you accept it in your account.
Read the scope against your own question. If you need one licence check or one network routine, make sure those functions are inside the agreed scope. A high coverage figure over the wrong functions still leaves your question open.
The protector name alone does not settle scope. Devirt checks the family, architecture, build, layers and complexity of each file. Complex or unfamiliar files may need a manual review, a separate written quote or a decline, and an offer for a separately quoted engagement expires after 72 hours.
How is the coverage figure counted?
A devirtualization coverage figure is only meaningful when it states its unit and its denominator. Functions, handlers, blocks and paths each give a different percentage for the same work, and so does dividing by every function in the binary instead of the protected ones.
Devirt counts the protected functions in scope before recovery starts. Every one of them is reported in one of four proof states, so a function that was not proven cannot drop out of the total. The article on how to read a devirtualization coverage figure shows how one result can read 70%, 77% or 90% depending on what is counted.
What does the 80% proven condition cover?
Devirt's 80% proven condition is a delivery requirement for Full and Deep recovery: at least 80% of the protected functions in the agreed scope must reach the proven state before the result is released. It is not 80% of the original source code, and it is not a promise that every uploaded file is eligible.
The functions that are not proven stay in the result. Each one sits in one of the other three states:
- Runtime-dependent: a real input or environment is still needed to settle the behavior.
- Unresolved: the function was inspected, but the available evidence did not settle it.
- Permanently bounded: a stated limit prevents a stronger conclusion.
The article on runtime-dependent, unresolved and bounded functions explains what you can do with each state.
Are counterexamples and timeouts reported?
A trustworthy devirtualization result reports its failed and unfinished checks. At Devirt, the proof summary lists the counterexamples and timeouts beside the proven count, and neither one ever counts as proof.
A counterexample means the checker found an input on which the recovered code and the original disagree. A timeout means the checker did not finish, so it establishes nothing either way. If a result shows only successes, ask where the rest went.
How was the recovered code checked?
Devirt checks recovered code three ways before a result is released. Each check answers a different question, so ask which ones a result went through.
- The logic. A solver looks for an input that makes the recovered code and the original disagree. A proof holds within its stated model and assumptions.
- The behavior. Recovered operations are translated to LLVM IR and compared with the original observations and native execution for selected inputs. These comparisons do not establish every possible behavior.
- The delivery. The requested files are checked, the coverage figures must add up, and IDA output is saved and reopened.
The full path from upload to delivery shows where each check sits.
Which outputs and tool versions will you receive?
A devirtualization result is only useful in a form your own tools can open. Devirt offers five output formats, and the eligible formats and the total are shown before payment. Each one comes with the coverage ledger and the proof summary.
| Output | Choose it when |
|---|---|
| IDA database (.i64) | You want to continue the investigation in IDA. |
| Annotated pseudocode (.c) | You want to read the recovered logic. |
| Full RE report (.pdf) | You need to explain the result to others. |
| LLVM IR (.ll) | You have your own analysis toolchain. |
| API JSON | Your next step is another system. |
Check the tool version before you pay. Devirt lists the tool versions with the artifacts, and a newer database is not promised to open in an older version of the tool. For an IDA result, see what a recovered VMProtect database contains and how to review it.
What happens if the result falls short?
A Devirt result that misses the accepted package requirements is not released as a successful delivery. Credit restoration and refund handling then follow the billing terms, and a terminal processing failure restores the allowance it consumed.
For a separately quoted engagement, a senior reverse engineer validates the result before release, and the balance is due before release. The commitments Devirt makes before you pay set out the delivery condition in full.
Is a feasibility estimate the same as delivered proof?
A feasibility estimate is not delivered proof. A Devirt assessment gives an expected recoverable range with its reasons before any paid work starts: the strongest evidence, the runtime dependencies and the permanent bounds. Delivered proof is the coverage ledger and proof summary that come with the finished result.
The synthetic sample assessment shows what an estimate looks like. You can accept the offer and fund the agreed work, or decline it. Declining charges nothing, opens no paid engagement and requests deletion of the assessment input.
What a devirtualization result cannot give you
A devirtualization result cannot give you the original source code. Compilation discards names, comments and project structure, and protection removes more on top of that. What you receive is recovered logic in a form your tools can read, with the evidence for each conclusion.
A proof also has edges. It holds within its stated model and assumptions, and a runtime-dependent function is only as settled as the input you can supply for it. Read the ledger before you quote a result, so those limits travel with your conclusion.
A checklist to keep
- The written offer names the file, the functions in scope, the outputs and the price.
- The functions your question depends on are inside that scope.
- The coverage figure states its unit and denominator.
- Every function in scope sits in one of four proof states, and the states add up.
- Counterexamples and timeouts appear in the proof summary, outside the proven count.
- The output format and tool version match what you will open it in.
- You know what happens if the result misses the agreed requirement.
- You read the estimate as an estimate, and the ledger as the evidence.
The same checks apply on every protector Devirt handles, including VMProtect devirtualization and Themida devirtualization.
To see an offer for your own file, create an account and upload a file you own or are authorized to analyze. Paid work starts only after you accept the offer.