In general, nothing about (say) Bochs obsoletes software protection. Advanced protected code (say) encrypts sensitive blocks, and uses (say) runtime artifacts to decrypt them before executing.

There are software protection schemes that nobody has published breaks for, presumably because they are too much of a pain in the ass to break.

...security through obscurity never really works.

A nonstatement. Just because something has also been secured, doesn't mean that it is secure. Obfuscation has no true correlation to true security.

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

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.

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.

Alternatively, one could use automated means to find sections of a binary which behave in a logically distinct manner (branch differently in at least one place) when emulated instruction timings are twiddled. Then turn the disassembled section red in your debugger and attack it manually.