> 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.
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.