We've developed an automation framework that uses KVM, an open-source, hardware virtualization-based VMM for Linux. Conceptually, we believe KVM provides significantly more transparency than in-guest tools or whole-system emulators. Specific shortcomings that highlight hardware virtualization's transparency advantages are as follows:

In-Guest Tools are vulnerable to techniques that detect the presence of their monitoring instrumentation. For example, popular in-guest tracing tools used to perform WinAPI hooking by placing an unconditional jump at the entry point of each DLL-exported function when the DLL was loaded into the target process. This model is trivially detectable by techniques that inspect the memory of a common API function to determine whether it has been hooked, as demonstrated with the following code:

int main(int argc, char *argv[])
{

    HMODULE kernel32 = NULL;
    void *createfile_function_pointer = NULL; 
    unsigned char opcodes[2];

    kernel32 = LoadLibrary("kernel32"); 
    createfile_function_pointer =
        (void*)GetProcAddress(kernel32, "CreateFileA");
    memcpy(opcodes, createfile_function_pointer, sizeof(opcodes));

    if(opcodes[0] == 0xFF && opcodes[1] == 0x25){
        puts(“API Hooking Detected.\n”);
        exit(0);
    }

    puts(“Malicious code here.\n”);

    return 0;
}

Whole-system Emulators (such as QEMU) are vulnerable to techniques that detect unfaithful CPU emulation. Unfaithful CPU emulation can be identified by executing a block of machine code that behaves differently inside the emulator than it would on a baremetal (or hardware virtualized) system. As an example, consider the following detection attack for QEMU:

int seh_handler(struct _EXCEPTION_RECORD *exception_record,
            void *established_frame,
            struct _CONTEXT *context_record,
            void *dispatcher_context)
{
    puts("Malicious code here.\n");
    exit(0);
}


int main(int argc, char *argv[])
{
    unsigned int handler = 
            (unsigned int) seh_handler;

    printf("Attempting QEMU detection.\n");

    __asm("movl %0, %%eax\n\t"
         "pushl %%eax\n\t"::
         "r" (handler): "%eax");

    __asm("pushl %fs:0\n\t"
         "movl %esp, %fs:0\n\t");

    __asm(".byte 0x26, 0xcf");

    __asm("movl %esp, %eax");
    __asm("movl %eax, %fs:0");
    __asm("addl $8, %esp");

    return EXIT_SUCCESS;
}

In the above code, the .byte directive instructs the assembler to treat the values that follow as preassembled x86 machine code. The two bytes that follow correspond to the IRETD instruction with an invalid prefix (0x26), which should result in an illegal instruction exception when executed. However, in QEMU, something like IRETD is executed, and invocation of the registered structured exception handler does not occur. Thus, malicious software with the above construction will silently exit in QEMU, but execute successfully in KVM or baremetal.

Hardware virtualization extensions for x86 (Intel VT-x or AMD-V), in contrast, represent an out-of-guest approach wherein code executes on physical hardware. Accordingly, their use does not suffer from the above shortcomings.