LiBERATED HYPERViSOR
libertas Updated: 2015-10-042015-08-05*

Hypervisors are extremely helpful for dynamic analysis. This is a project to write a hypervisor for use in research of Windows. The Liberated Hypervisor provides monitoring tools accessible from ring 1 which you can update however you want. Perhaps you wish to monitor PatchGuard contexts. Or another sort of kernel mode code which relocates onto random memory locations and performs uncommon operations therein. Such as disabling write protection (by modifying the CR0), clearing hardware breakpoints (by resetting DR7), or accessing IDTR via SIDT/LIDT instructs. Without a hypervisor you cannot detect any of that, because those are just instructions (and you will not know where to set breakpoints because of the random relocation in memory). Liberated Hypervisor addresses these issues.

How to Run
You need VMWare Workstation, or some sort of hardware debugger (more on this later). Nested virtualisation (VT-x) and the ability to debug the hypervisor code externally (through the host machine via Windbg or some such thing) are needed - so you can do kernel debugging in the exact same manner as regular.

Other virtual machine systems may work, such as Fusion or QEMU, but I believe you will have to run two VMs and configure debugging between them. Additionally, with a Windows host you can use VirtualKD to make communication with the debugger very fast. VirtualBox does not support nested VM, nor is it allowed to execute VMX operations in it (at this time).

If you do not trust VT-x emulation, you can use physical box/board with a serial port.  USB debuggers like the one below are not recommended. Unless you already know that the hardware you plan to use is confirmed to support it, do not trust any claimed specs or suspicions by forum commentators. There are some very subtle features needed to use these setups. It is also significantly easier to dump the memory from a hanged VM than a physical RAM DIMM (though not impossible!), which is a plus :)

Configuring VMWare
- Virtualize Intel VT-x/EPT or AMD-V/RVI
- Virtualize CPU performance counters

It is recommended that you add these lines in a corresponding VMX file [1], or you will get mysterious, random-looking NMI_HARDWARE_FAILURE bug check:
hypervisor.cpuid.v0 = "FALSE"
mce.enable = "TRUE"
vhu.enable = "TRUE"

Don't Go Insane
Avoid using APIs inside a VMExit handler (VMX root mode). The handler can be executed from any contexts, including exception handlers or code under a very high IRQL, so it is tough to conclude that calling an API is 100% safe unless you know exactly what it does.

Avoid calling DbgPrint() from the VMExit handler. 99% of the time it works fine, but sometimes causes mysterious errors like a fault in the double fault handler when you request a lot of log. Instead, store log texts into pre-allocated non-paged pool and print them out later from a safe context.

Do not step-in to vmlaunch and vmresume instructions. The debugger will never return control to you, and the debug system/VM will hang.

Do not put software breakpoints everywhere in the VMExit handler. Although it seems to be fine in most cases, in some situation, the debugger does not get control back, and the system just freezes when 0xCC or 0xCD imm8 is executed.

Memory Dumping a Hanged System
The biggest advantage of using VMWare is that the memory dumps are handled by Windbg just like a normal crash dump analysis file.

First suspend the virtual machine.

Next, navigate to where snapshot files are stored and run the vmss2core command under the VMware Workstation directory using the latest vmsn and vmem files.
$cd "C:\Users\user\Documents\Virtual Machines\Windows 8 x64"$ "C:\Program Files (x86)\VMware\VMware Workstation\vmss2core-win.exe" -W8 "Windows 8 x64-Snapshot45.vmsn" "Windows 8 x64-Snapshot45.vmem"

scanning pa=0 len=0x10000000
Cannot read context LA from PRCB.
...
... 2020 MBs written.
... 2030 MBs written.
... 2040 MBs written.
Finished writing core.

Note that sometimes VMWare breaks their vmss2core utility. If you get a 0byte files back, download a slightly older version.

\$ windbg -z memory.dmp

Implementation
For my own part, Liberated Hypervisor monitors for uncommon instructions from non-image kernel space and stops threads when write protection CR0 modifications occur.

In less than 4000 lines of code, we have the ability to investigate some runtime behavior of the kernel which should be unmonitorable.

Installation
1. Compile liberated-hypervisor-src.zip

2. bcdedit /set {current} testsigning on

3. sc create Liberated type= kernel binPath= C:\path\to\liberated.sys
sc start Liberated

4. Once you have installed the .sys, it logs interesting activities on C:\Windows\Liberated.log and DebugView when it occurred, or you can run LiberatedTest.exe and see that the output is being changed.