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?

the_endian
  • 1,860
  • 17
  • 39
  • It's not just about using a debugger/disassembler being more difficult it's the whole analysis processes. The question is not focused. As I see the subject it's too much to say about this. Specifically about the last part. If you have an example please add it to the question to make it easier to answer. – EWD-0- Nov 23 '17 at 11:05
  • @EWD-0- you mean a specific file to be examined or a specific type of vm? – the_endian Nov 23 '17 at 11:27
  • See added example – the_endian Nov 23 '17 at 11:38
  • http://static.usenix.org/event/woot09/tech/full_papers/rolles.pdf, http://ieeexplore.ieee.org/document/5207639/ – julian Nov 24 '17 at 17:37
  • http://www.msreverseengineering.com/blog/2018/1/23/a-walk-through-tutorial-with-code-on-statically-unpacking-the-finspy-vm-part-one-x86-deobfuscation, https://www.welivesecurity.com/wp-content/uploads/2018/01/WP-FinFisher.pdf – julian Jan 24 '18 at 13:48

2 Answers2

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.

Johann Aydinbas
  • 1,391
  • 7
  • 11
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

EWD-0-
  • 119
  • 6