This is just a little followup of a previous thread

http://www.woodmann.com/forum/showthread.php?p=67341

The packer used in that malware executed a VERR instruction with an invalid source operand which caused the application to crash under VMWare. In further testing I found that this includes both the VERR and VERW instructions where the source operand is an illegal value.

VERR, VERW—Verify a Segment for Reading or Writing
Verifies whether the code or data segment specified with the source operand is readable (VERR)
or writable (VERW) from the current privilege level (CPL). The source operand is a 16-bit
register or a memory location that contains the segment selector for the segment to be verified.
If the segment is accessible and readable (VERR) or writable (VERW), the ZF flag is set; otherwise,
the ZF flag is cleared. Code segments are never verified as writable. This check cannot be
performed on system segments.

Protected Mode Exceptions
The only exceptions generated for these instructions are those related to illegal addressing of the
source operand.


The attached program and source is a simple test of VM detection through these two instructions. The labelled buttons will execute each instruction within an exception handler and output the verdict.

Cheers,
Kayaker

In other words, VERR/VERW doesn't do anything when not executing in a VM.

I think this is a bug in the VM implementation.

This really does make one wonder if the author intended to do this, or if it was an accident. The instruction sure seems rare enough to be intentional, but how did they come about on it? - do they just sit there and try every instruction in the Intel manuals to see if it works different? Talk about determination..that's why it seems like accidental..

I was also going to mention - why not run your webserver using VMWare ESX server, etc, so the app is virtualized. 1 drawback - possible lack of speed. However 2 advantages: If the server gets rooted, you can simply revert to snapshot, and 2, if the virus uses VM detection, it simply won't run ! So authors that use VM detection to prevent examination also prevent some segment of infection (although probably a small percentage at this time..)


-nt20

I think it was developed through reasoning of how the VM emulates the processor; from what I understand, not everything (e.g. the GDT) is virtualised "sufficiently"

I have seen those instructions used in a polymorphic virus more than 3 years ago now. (i have been presenting this virus at my recon trainings, as well)

Those instructions were generated as junk code in the poly layers.
Some trojans have been using the same poly engine for a while as well.

I think the anti VM wasn't made on purpose, but rather out of luck, as they generate tons of junk instructions.

Yes, i have seen those instructions in the poly layers of the Bacalid virus but I doesn't have any problem with this by using the VMWare version 6

http://img2.freeimagehosting.net/uploads/bb453646d7.gif

You can also disable acceleration on previous Vmware versions, and it will work .

That's interesting Nico. It certainly works on VERR/VERW. I was just reading a paper from the recent BlackHat convention that also mentions disabling acceleration to prevent VM detection by other instructions as well:

Covert Debugging: Circumventing Software Armoring Techniques

http://www.offensivecomputing.net/?q=node/492




Sure enough, redpill (SIDT) is fooled when you toggle 'acceleration' on/off. (VM/Settings/Options/Advanced/Disable Acceleration)

With the debug version of vmware-vmx.exe from the bin-debug directory you get a record of the event in vmware.log when toggled, i.e.
vmx| Setting disableAccel: 1

Doing a search for the string 'disableAccel' will show where this occurs in vmware-vmx.exe. I couldn't figure out much else from the disassembly but I'm curious now, what exactly happens when you disable "acceleration" and why does it have this effect on certain instructions? I know the answer lies deep in the theory of how a VM and certain privileged instructions work, but I'm wondering if there's a succinct explanation?

Cheers,
Kayaker

There is some info I found in the VMWare forum:
http://www.vmware.com/community/thread.jspa?messageID=351115

Acceleration would have something to do with "differences in processor behavior", according to a VMWare moderator.

My guess, for what it's worth, would be that there are 2 different methods to emulate certain cpu instructions: one faster and the other more stable but slower.

This also answers part of my question in the newbies section about Intel Virtualization Technology (hardware support for VMs).
It seems that those new cpus make the VM more difficult to detect even with acceleration enabled.

TiGa

I guess it's apparent that certain instructions are passed to the real CPU to handle when acceleration is turned off (SIDT returns the "real" value, VERR/VERW behave as on the real system..), but since there's a significant slowdown there must be much more of the VM OS operations which are passed to the host system to handle as well.

Hmm, makes one wonder if one could programatically toggle acceleration on/off on a VM and what consequences that might have..

Here is a recent paper from VMWare where they describe their emulation method and compare it to hardware virtualization:
http://www.vmware.com/pdf/asplos235_adams.pdf

Here is another paper from Defcon 2006 and its follow-up about acceleration:
http://www.offensivecomputing.net/dc14/vm.pdf
http://www.offensivecomputing.net/dc14/furthur_down_the_vm_spiral.pdf



If acceleration can be enabled or disabled on-the-fly by the VMM, it must be "programatically" doable, maybe by using the internal ComChannel to send the enable/disable acceleration command.

TiGa

I have tested some VM detection tools under VMWare with Hardware Virtualization on a quad core intel cpu.

To activate the "undocumented and unsupported" option:
monitor_control.vt32 = "TRUE"

Red Pill and Scoopy Doo are both detecting a Native OS.
Jerry and VmDetect are still detecting VMWare.

On Virtual PC, only VmDetect is working properly.
All the others give the same results as a Native OS.

I thought this might be interesting since I have not seen this kind of testing anywhere.
TiGa

funny thing to detect VMWare is wrongly handled TF when rdtsc is executed. Actually I wasn't aware of this as I wrote code for detecting all public versions of fake_rdtsc drivers. But after Archer tested it on clear system in VMware I was quite impressed that code reported "rdtsc hooked" even if he didn't have rdtsc faked, so we came to conclusion that VMWare wrongly handled rdtsc and TF

You may get sample code here : http://deroko.phearless.org/fakerdtsc.rar (anti-rdtsc.asm) and deeper explanation(if any is needed) in fakerdts.c driver comments

Some further quite technical and interesting information about different kinds of attacks towards virtual machines:

"An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments" (by Tavis Ormandy):

http://taviso.decsystem.org/virtsec.pdf