4 ms·

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, o

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

tptacek 17y ago
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.
- asciilifeform 17y 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.

tptacek 17y ago

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.

asciilifeform 17y 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.