Software Reverse Engineering Services Compared: 4 Provider Types

There are four kinds of software reverse engineering service in 2026: specialist consultancies, R&D outsourcing firms, independent freelancers and automated services. Picking between them is mostly a scoping question. Can the job be defined before it starts, and how will you check the result when it arrives? This post compares the four by job type, then covers the one factor that changes the answer most: whether the binary is protected.

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: written by Devirt, which runs an automated reverse engineering service for protected and ordinary binaries. The comparison describes provider types, not named companies, and doesn't rank anyone.

What a software reverse engineering service sells

A software reverse engineering service sells recovered understanding of a compiled program: what it does, how its parts talk to each other, and how confident you can be in each conclusion. It doesn't sell source code. Identifiers, comments and project layout are gone after compilation, so the deliverable is some mix of:

• pseudocode for the functions in scope
• a disassembler database (an IDA .i64 or a Ghidra project) with the recovered functions in place
• a written report
• machine-readable output such as LLVM IR or JSON

What differs between provider types is how the scope gets set, which of these you get, and whether there's evidence attached.

Which kind of software reverse engineering provider should you use?

Pick by the job, not the provider. Scope-able, repeatable work suits a standardized service. Open-ended work suits people who can invent the method as they go.

Two things stand out in that last row. Only one model tends to build verification into the output by default, and for the other three you have to ask for it. Ask anyway, because it's the difference between a result you can audit and a result you have to trust.

Four example jobs, matched to a provider type

Abstract tables only go so far. Here are four common software reverse engineering jobs and the provider type each one usually points to.

A legacy file format nobody documented. Your company owns a 15-year-old desktop tool, the vendor is gone, and you need to read its project files in a new system. The job is open-ended: nobody knows yet how the format is structured or how many versions exist. That points to a specialist consultancy, or to an R&D outsourcing firm if the reader then has to be built and maintained.

A malware sample your team has to explain. The question is narrow (what does this sample do, and what does it talk to?) and the deadline is usually short. If the sample is unprotected, an in-house analyst or a freelancer with malware experience may be enough. If key functions are virtualized, the bottleneck is devirtualization, which is where an automated service earns its place before the analyst takes over.

A protected DLL in software you license. Your license allows analysis for interoperability, but the functions you care about sit behind a commercial protector. The scope is clear and the protector is known, so this is repeatable work. An automated service with support for that protector fits, as long as it reports which functions were proven and which weren't.

An undocumented network protocol. You need two systems to talk, and only one side's binary is available. The work mixes static analysis with traffic captures and testing against a live system. That points to a consultancy, because the method has to be worked out on the job.

The pattern holds across all four. The better the job can be scoped before it starts, the more it suits a standardized service. The more it depends on discovery, the more it needs people.

How do you check what a provider delivered?

You check a software reverse engineering result against a scope agreed before the work, and the tool for it is a coverage ledger. The ledger lists every unit in scope (every function, say) and puts each one in one of four states:

1. Proven: there is verification evidence inside a declared scope.
2. Runtime-dependent: settling it needs a real input or environment state.
3. Unresolved: it was inspected and the evidence didn't settle it.
4. Permanently bounded: an explicit limit was agreed.

Then run the one check that matters. The count of units in scope before the work has to equal the count in the ledger. If 140 functions were in scope and the report discusses 110, ask where the other 30 went. A result where the unproven units quietly disappear will always look better than it is.

Whatever provider you pick, ask them to report in something like this shape. Some of them won't, and that tells you something too.

What changes when the binary is protected?

Protected software is a compiled program that a commercial protector (VMProtect, Themida and the like) has packed, obfuscated or virtualized. Protection is where the four models split hardest.

• Packing compresses or encrypts code, and unpacking gets it back. Most providers can handle this.
• Obfuscation keeps code native but makes it miserable to read: substituted instructions, junk code, flattened control flow.
• Virtualization replaces a function's instructions with bytecode for an interpreter embedded in the binary. Point a decompiler at a virtualized function and it will faithfully decompile the interpreter. You get handlers and a dispatch loop, not the logic you came for.

Recovering what a virtualized function computes is called devirtualization. It's slow by hand, which is why it's the one job where an automated service can beat a team on turnaround, as long as the protector is supported. If yours isn't, you're back to a consultancy, or to a service that does a feasibility review first.

There's a longer explanation of why an unpacked binary can still be unreadable in this comparison of unpacking and devirtualization.

Questions to send any provider

Copy these into your first email:

• What exactly is in scope, in one sentence?
• Which formats will you deliver? (Name the disassembler you use.)
• How will you report units you couldn't recover?
• Will the count of units in scope match the count in your report?
• What do you need from me to confirm I'm authorized to analyze this file?
• Where does the analysis run, who can access the binary, and when is it deleted?
• What happens to payment if the result falls short?

A provider who answers these clearly is probably worth talking to. One who can't is probably not the right fit, whatever their portfolio says.

Is hiring reverse engineering legal?

It depends on the jurisdiction, the software license and your authorization. Get legal advice for your case, since this post isn't it. What you can check is the provider's intake. Legitimate services ask whether you own the binary or are authorized to analyze it, and they refuse requests to strip licensing, defeat DRM or enable cheating. The EFF reverse engineering FAQ is a reasonable primer for the US.

Where the automated model fits, using Devirt as the example

Disclosure again, since this is our product. Devirt is an automated service for protected and ordinary binaries:

• Inputs: native executables, .NET assemblies and JavaScript bundles.
• Automated devirtualization: eligible VMProtect, Themida, Code Virtualizer, Enigma Protector and Obsidium profiles.
• Feasibility first: custom or unsupported VMs get a free feasibility review and a written scope and quote before any paid work.
• Outputs: an IDA database, annotated pseudocode, a full report, LLVM IR and API JSON, with a coverage ledger in the four states above.
• Your file: analysis is isolated, uploads are never used for training, and inputs are deleted after the artifacts are generated and verified.

Details are on the software reverse engineering services page, and pricing is at devirt.re/pricing.

For a one-off protocol nobody has documented, a consultancy is still the better fit. For a VMProtect-protected DLL you need to read by Friday, it usually isn't.