Timing Attack, similar to Locky

```c
/*
This is the Locky anti-VM code from 21 June 2016 (sample SHA1 25f8f920f946887e0fa86ea46842f8e3f4506f53)

Some VM products may behave significantly differently to a real system
with regards to timing of code execution.

GetProcessHeap() may take significantly longer in a VM than a real env.

Virtualised TSCs can also be problematic.

Multiple processor cores assigned to a VM may also worsen this problem.

See http://blog.badtrace.com/post/rdtsc-x86-instruction-to-detect-vms/
*/

BOOL passVMCheck()
{
unsigned __int64 tsc1;
unsigned __int64 tsc2;
unsigned __int64 tsc3;
int i = 0;

// Try this 10 times in case of small fluctuations
for (i = 0; i < 10; i++)
{
tsc1 = __rdtsc();

// Waste some cycles - should be faster than CloseHandle on bare metal
GetProcessHeap();

tsc2 = __rdtsc();

// Waste some cycles - slightly longer than GetProcessHeap() on bare metal
CloseHandle(0);

tsc3 = __rdtsc();

// Did it take at least 10 times more CPU cycles to perform CloseHandle than it took to perform GetProcessHeap()?
if ( ( LODWORD(tsc3) - LODWORD(tsc2) ) / ( LODWORD(tsc2) - LODWORD(tsc1) ) >= 10)
return TRUE;
}

// We consistently saw a small ratio of difference between GetProcessHeap and CloseHandle execution times
// so we're probably in a VM!
return FALSE;
}
```