I found an interesting article:

http://www.usenix.org/events/usenix05/tech/general/king/king.pdf

Good article! The idea of virtual machines that record previous machine states is not that new... given the fact that VMs have been around ever since computers have.

Very interesting

So, we wonder: if it would exist such a debugger, able to run backwards as the cracker wishes, and also able to emulate the IDT, debug registers, etc until the last CPU-related feature - the one in the article is not but let's suppose it exists. How can a protectionist beat this beast?.


Hmm.. it seems hard to find a way one can easily code. I think the following ones would work:

1. Heavy loops, decryption and self-modifying code will make the debugger to store huge amounts of information in order to trace back. Allocating/freeing memory also helps in this process.

2. Computations with the registers will always be faster if not emulated. So, we can measure the elapsed time and compare it to a threshold. All the time-consuming tricks of (1) can be used with only the registers. This could be beaten with clever emulation of those instructions reading the timestamp counter and performance registers (rdpm, rdtsc, ...).

3. Anti-disassembler and code obfuscation. It's pointless to go back in a code you don't understand. One could use Virtual Machines or metamorphism as execryptor does .

And here ends my list.

So, if i'm not wrong, the list of reliable available tricks is reduced to use the same tricks anti-cracking protections are heading to. Tricks based on time-consuming problems, somewhat related with mathematical problems (metamorphism is related to some pretty hard group-theory problem used in crypto, for example). Not ellegant and clever tricks any longer.

Personally, i find reversing this stuff very boring.

Regards,
Havok.

Simics Hindsight

Thank you Extremist. I have downloaded some literature on Simics.
Will see what I find with some reallife testing.

@ Havok:

There are ways a program can detect that it is being runned inside a VM. . . The simulation is pretty good but not perfect, at least with the VM I have played with (VMWare and VirtualPC) http://www.codeproject.com/system/VmDetect.asp

In part, the detectabillity of these specific VM stems form the fact that they pipe as many instructions as possible to the actual silicon CPU directly, in order to improve performance. But it is at least plausible to work around these anti virtual debugger detection tricks (out of my league).

If a program can detect that it is being run inside a VM, then the VM is obviously not providing a true-enough emulation. The "backdoor interfaces" mentioned in the link in naides' post are what give it away; a "true" emulation would not have any such hints, and the software would not be able to "reach" outside and find out if it's running in a VM or not. From the software's point of view, there is nothing existing outside of the hardware.

Being able to run a VM inside another VM would be one test of a true emulation.

Also, time itself will have to be emulated. Relative speeds of instruction execution, the realtime clock(s), all have to be perfect. If the real host CPU is 4GHz, the guest CPU may from our definition of time appear to be running at 40MHz, but from inside the VM all time is slowed, so programs that perform timing measurements will be relative to the "guest time", which is much slower than "host time". What takes 1 second on the host machine may take 1 hour on the guest, but to the guest, it appears to be 1 second as well. (This is seriously starting to look like Einstein's Theory of Relativity...)