Check four things when you evaluate software reverse engineering companies: what they'll do before they quote, what the quote names, how they report progress, and what you can verify at delivery. This checklist, written in November 2026, walks through those four stages in order, with 23 checks you can copy into your own vendor review.

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.

Disclosure: Devirt wrote this. We run an automated reverse engineering service for protected and ordinary binaries. The checklist is meant to work for any provider, ours included. Where Devirt appears, it's an example of a written answer, not a ranking.

Before you ask for a quote

Software reverse engineering companies can only quote well if you can say what you need. Settle these first.

• [ ] Write the goal in one sentence. "Recover the file-format parser in this executable so we can read old project files." Not "analyze this binary."
• [ ] List the files. Exact names and versions, and whether you expect any of them to be packed or protected.
• [ ] Confirm your rights. You should own the binary or be authorized to analyze it. A good company will ask, and a company that doesn't ask is a red flag.
• [ ] Decide what you'll do with the result. Your own analysts in IDA or Ghidra? A report for an auditor? Input for a rebuild? That decides the formats you need.
• [ ] Check the company's own limits. Reputable software reverse engineering companies publish what they won't do. Expect refusals for licence removal, DRM circumvention and cheating.

What should a reverse engineering quote include?

A software reverse engineering quote should name four things before any money moves: the exact file, the work in scope, the outputs that will be delivered, and the price. A strong quote also states the delivery condition, meaning how much of the scope has to be proven before the result counts as delivered, and what happens to payment if that condition is missed.

• [ ] File named. The quote refers to your specific binary, not "your software".
• [ ] Scope named. Which functions, components or behaviors, matching your one-sentence goal.
• [ ] Outputs listed. Pseudocode, a disassembler database, a report, machine-readable output: whichever you agreed.
• [ ] Price stated. Fixed, per result or time-based, so you know which one you're signing.
• [ ] Delivery condition stated. What counts as done? Devirt's Full and Deep packages, for example, require at least 80% proven coverage of the protected functions in the agreed scope before release. Whatever the number, it should be written down.
• [ ] Shortfall terms stated. What happens to credits, payment or refunds if the condition isn't met?
• [ ] Data handling stated. Where the analysis runs, who can access the file, whether it's ever reused, and when it's deleted.

If a quote names a price but not a scope, you've got nothing to check the result against.

While the work runs

Most software reverse engineering companies go quiet between kickoff and delivery. A few checks keep the work honest.

• [ ] Scope changes are written down. If the company finds the job is bigger or different, you should get a revised written scope before extra work starts.
• [ ] Protection is identified early. If the file turns out to be virtualized by a commercial protector, the company should say so and explain what that means for the result. Virtualized functions decompile into an interpreter, not into the original logic.
• [ ] You know when to expect the result. Ask what the turnaround depends on: analyst time, the queue, the file size.

How do you know the result is complete?

A software reverse engineering result is complete only against the scope agreed in the quote, and a coverage ledger is how you check it. The ledger lists every unit in scope and records each one as proven, runtime-dependent, unresolved or permanently bounded. Count the units in scope before the work and count them again in the ledger. The two numbers must match, because nothing should drop out of the count to make the result look better.

At delivery, check:

• [ ] It opens. The database loads in your version of your disassembler without rebuilding anything.
• [ ] The counts match. Units in scope = units in the ledger.
• [ ] Every unit has a state. Unproven units are labeled, not left out.
• [ ] Proven means evidence. Ask what "proven" rests on. Readable output isn't the same as proven output.
• [ ] The limits are stated. The report says what it couldn't establish, and why.

For a fuller walk-through of these checks on a protected binary, see how to evaluate a devirtualization result before paying.

After delivery

• [ ] Download within the retention window. Many services keep results for a limited time. Devirt's paid results, for instance, stay available for 72 hours by default, or 30 days on the Team plan.
• [ ] Confirm deletion if you need it. If your policy requires proof that the input was deleted, ask for it in writing.
• [ ] Record what was unresolved. The unresolved and runtime-dependent units are your next questions, whether you answer them in-house or in a second engagement.

Red flags at each stage

Most problems with software reverse engineering companies show up early, if you know where to look.

Before the quote. The company never asks whether you're authorized to analyze the file. Or it offers to "remove protection" so you can redistribute the software. Either one tells you how it handles risk, and the risk ends up being yours.

At the quote. A price with no scope. A promise to "recover the source code", which no company can do, because names and comments don't survive compilation. No written answer on where your file goes and when it's deleted.

During the work. The scope grows without a written revision. Nobody mentions protection until the deadline, then the result arrives late and vague.

At delivery. The report covers fewer units than the scope, with no explanation. Everything is described as recovered, nothing is marked unresolved, and there's no way to see what "recovered" rests on. A result with no uncertainty in it is usually a result with the uncertainty taken out.

None of these is proof of bad faith. Each one is a reason to ask a follow-up question before you pay.

Is it legal to hire a reverse engineering company?

It depends on your jurisdiction, the license and your authorization, and this checklist isn't legal advice. The EFF's reverse engineering FAQ is a sensible starting point in the US. What every buyer can check is the company's intake: it should accept only files you own or are authorized to analyze.

Where Devirt fits

Devirt is an automated software reverse engineering service for protected binaries (eligible VMProtect, Themida, Code Virtualizer, Enigma Protector and Obsidium profiles) and for ordinary native, .NET and JavaScript binaries. You get a free assessment and a written scope before paid work, outputs in five formats, and a coverage ledger for the full scope. Custom virtual machines get a free feasibility review and a written quote. More on the software reverse engineering services page; prices are on devirt.re/pricing.

Keep the checklist for whichever company you hire. It works best when you send it with your first email.