Anti-VM z dílny autorů Lockyho

[RubberDuck]

https://blogs.forcepoint.com/security-labs/locky-returned-new-anti-vm-trick

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

[Kockatá hlava]

I s nativnim RDTSC je problem, ze nekdy vraci podivny nebo nepredvidatelny hodnoty. Nejspis je to kvuli hyperthreadingu a multicore, uz si presne nevzpominam. Pokud ale malware vi, ze nekdy muze chybne detekovat host jako VM, tak to nemusi delat problemy.