5

It is practically common knowledge in reverse engineering that trying to use a native debugger or disassembler on a "VM protected" or virtualized program is much more difficult to analyze. However, I would like to know specific, concrete ways in which this is the case and why. Please list some reasons along with any relevant work on whether the various reasons have been overcome manually (not using a script).

In case this question is perceived as being too general, let us focus on a specific example. The example is we are trying to use a native debugger (such as x64Dbg) to locate a call to the Windows API CreateFile and find out the location of a file write. In an unprotected program, we could open it up, place a breakpoint on CreateFile and locate the call after examining cross-referenced calls.

How would this process successfully be obstructed by Themida Protector? Obviously, at the end of the day, the program must still write the file, but what steps severely hamper analysis?

1

It depends on your goal. If all you care about is side-effects (as in API calls, written files, network stuff and so on), they don't really make life difficult. As you said, in the end the API has to be used and you will be able to catch it.

The purpose of virtualization is preventing people from understanding internal processes of the target. As such, often times people virtualize only specific code blocks to lessen the overall negative performance impact and just protect for example code that reads a license file, code that does cryptography and so on.

This makes it very tedious to extract algorithms from the target. If your question is what happens inside, VM protections are the worst. If you just care about what the target does, well, they do nothing.

Basically, their goal is turning an executable into a black box, not shroud their doings.

0

So as I understood the question has two main parts. First why it is hard to reverse/analyze a virtualized code. Standard assembly instructions have particular byte code which by that you can understand what is happening in the program. By using virtualization one can create arbitrary byte codes which then is translated to the original code that system can understand. This means by viewing the code you can't understand what goes on.

This goes further when we encounter virtualization machines which produce the original code part by part at run time not all the code at once. So as an analyst you see small parts of the real assembly at run time.

The second part about CreateFile/WriteFile. If by this example you mean analyzing behavior of a program, there is no difference between virtualized or normal executable most of the time. In both cases you can put BP on CreateFile/WriteFile in the debugger or a better way just do black box monitoring.

It's worth mentioning that the other problem we face reversing virtualized code is that they mostly benefit from heavy protectors/anti debugging techniques too.

http://resources.infosecinstitute.com/reverse-engineering-virtual-machine-protected-binaries/#gref

http://resources.infosecinstitute.com/tutorial-building-reverse-engineering-simple-virtual-machine-protection/#gref

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.