Thanks for the paper, it was a nice read. I was stunned to see how straightforward it was.

Basically by order of appearance you look for

* well know files, or registry keys

* patterns in a memory dump

* use a great hack called "the red pill" using the SIDT instruction

* vm specific hardwares

* specific instructions/capabilities

This is all very old stuff. VMWare is very easy to detect, as it (a) was based on software virtualization, which has a heavy footprint, and (b) made no attempt to be hard to detect.

But the available evidence is that even if you're hardware-virtualizing, there are reliable, millisecond-fast techniques you can use to profile the microarchitecture to detect (say) jumps to hypervisor code in instruction sequences that should run natively. Nate Lawson, Peter Ferrie and I presented some of these at Black Hat a couple years ago.

The gap (in functionality and in performance) between an emulator and a cycle-accurate simulator of an actual chipset is large.

> The gap (in functionality and in performance) between an emulator and a cycle-accurate simulator of an actual chipset is large

On the other hand, there is a large degree of fuzziness in the behavior (between individual machines) of the features within this gap. For example, profiling and high-resolution timing instructions are not equally available on all x86 CPUs. As for the chipset, most of the interesting features are very poorly (if at all) standardized. I hypothesize that a thorough emulator detector written today will have many false alarms on actual bare hardware.

Let's also not forget that not a single emulator has yet been written with the explicit goal of being undetectable by hostile code. High-resolution timers could always be fudged, a tick table consulted for spoofing the requisite intervals, etc. if we know what to expect from the raw hardware.

And if one day emulator-writers fall far behind anti-debugger trick specialists, the hardware ICE could make a come-back.