Timing Attack, similar to Locky

[alichtman]

/* 
   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;
}

[alichtman]

Need to find functions to substitute in for those Windows API calls.