deroko
October 18th, 2007, 10:16
well I have posted this like 2 months ago, and source of poc is available for a while, but just to write something interesting here we go again.
Whole story started when TiGa was trying to detect presence of virtual machine using timers, trick was to know if rdtsc is hooked by playing with cr4 and installing own int 0D handler. In fact I answered with a simple poc code to detect all known public implementations of rdtsc faking driver. (I usually don't like to present way of detection, without way to fight it back
)
Code:
Trick consist of setting TF and seeing where exception is generated. All of public implementations, yes, including mine too, had a lille flaw, it didn't tace care of TF when used, all of them used add [esp.reg_Eip], 2 which resulted in int 1 to be generated after instruction after rdtsc if TF is set. This could be used to detect all public implementations of fake rdtsc drivers. When rdtsc is executed we have to check if TF is set in eflags, if so, we have to call int 1 handler (default KiTrap01).
Oki trick, was good, and I knew we have one way to detect all public fake rdtsc driver. But to be honest I was shocked when Archer author of PhantomOlly and QuickUnpack reported that VmWare even without any kinda of driver got "rdtsc hooked" message. This simply means that vmware didn't take care of privileged instruction which by default is not privileged(rdtsc) and when TF is set. So we got one way to detect 100% sure if vmware is active and in such viri can detect if they are runned in vmware. I highly doubt that malware analysers are using any kinda of fake rdtsc drivers as they don't need them
So, my comrades, we have one more way to make viri analysing a lille bit harder in vmware
wondering if vmware team will fix this flaw in next release till then you may write driver to handle rdtsc properly in vmware 
Whole story started when TiGa was trying to detect presence of virtual machine using timers, trick was to know if rdtsc is hooked by playing with cr4 and installing own int 0D handler. In fact I answered with a simple poc code to detect all known public implementations of rdtsc faking driver. (I usually don't like to present way of detection, without way to fight it back
)Code:
Code:
p586
.model flat, stdcall
locals
jumps
include c:\tasm32\include\shitheap.inc
include c:\tasm32\include\extern.inc
public C start
.data
nothooked db "rdtsc not hooked", 0
hooked db "rdtsc hooked", 0
start: push offset sehhandle
push dword ptr fs:[0]
mov dword ptr fs:[0], esp
pushf
or dword ptr[esp], 100h
popf
rdtsc
__safenop: nop
pop dword ptr fs:[0]
add esp, 4
call ExitProcess, 0
sehhandle: mov eax, [esp+0ch]
cmp [eax.context_eip], offset __safenop
jne __badbad
call MessageBoxA, 0, o nothooked, 0, 0
call ExitProcess, 0
__badbad: call MessageBoxA, 0, o hooked, 0,0
call ExitProcess, 0
end start
Trick consist of setting TF and seeing where exception is generated. All of public implementations, yes, including mine too, had a lille flaw, it didn't tace care of TF when used, all of them used add [esp.reg_Eip], 2 which resulted in int 1 to be generated after instruction after rdtsc if TF is set. This could be used to detect all public implementations of fake rdtsc drivers. When rdtsc is executed we have to check if TF is set in eflags, if so, we have to call int 1 handler (default KiTrap01).
Oki trick, was good, and I knew we have one way to detect all public fake rdtsc driver. But to be honest I was shocked when Archer author of PhantomOlly and QuickUnpack reported that VmWare even without any kinda of driver got "rdtsc hooked" message. This simply means that vmware didn't take care of privileged instruction which by default is not privileged(rdtsc) and when TF is set. So we got one way to detect 100% sure if vmware is active and in such viri can detect if they are runned in vmware. I highly doubt that malware analysers are using any kinda of fake rdtsc drivers as they don't need them
So, my comrades, we have one more way to make viri analysing a lille bit harder in vmware wondering if vmware team will fix this flaw in next release
till then you may write driver to handle rdtsc properly in vmware