don't expect links to download here, you may expect sometimes only contacts to owners of these technologies (I don't owe everything, you will need to obtain permission of another parties to use some of technologies), contact me in case you want to see capabilities of these technologies
last update: 2011 Feb 15

[CPU]
hypervisor skeleton: Intel IA-32e, Intel IA-32, AMD64
memory tool: Intel IA-32e only
protection of memory: Intel IA-32e only
debugger: Intel IA-32e only

[OS] ms windows only
hypervisor skeleton: x64 as well 32 bit versions of ms windows
memory tool: ms windows x64 only, PE32+ (native 64 bit) as well PE32 (compatibility 32 bit submode) processes may be analyzed
debugger: ms windows x64 only, only PE32+ (native 64 bit processes), not PE32 (processes running in 32 bit compatibility submode of long mode, hypervisor itself supports it but debugger client is capable to disassemble only 64-bit code)

[00] hypervisor skeleton
[01] stable when turning on virtualization, stable when running and operating, stable when turning off virtualization
[02] turning virtualization on/off on the fly (without necessity to reboot PC)
[03] private virtual memory translation tables, accessing guest memory by mapping guest pages (to prevent guest paging tables modification on access like changing Accessed or Dirty bit of paging tables), it also allows writing into pages which are mapped read-only under guest, obtaining list of mapped memory pages by walking paging tables from base of translation tables to the last level of tables
[04] SMP support: private stack for every CPU, private per CPU data - something like KPRCB of win64, synchronization among CPUs

[10] forensic memory analysis by hypervisor
[11] knowing currently executing PID, TID by watching guest and extracting PID, TID + knowing when guest switches processes/threads
[12] freezing execution of ring3 code of all ring3 threads of any given PID and then dump virtual memory of the PID (ring3 as well ring0 virtual memory space, size of present pages of ring3 virtual memory = about 5 MB for small process, size of ring0 present pages = about 500 MB for clean OS installation and loaded common drivers) - the dump contains page attributes also (e.g. executable, writeable, ...) as well info about modules (about 125 modules including ring3 executable, loaded ring3 DLLs, win64 ring0 kernel and loaded ring0 sys drivers for small process), dumping only selected ring3 module into PE32+ exe, dll file is also possible - currently exports and imports of PE32+ are not yet reconstructed
[13] freezing execution of ring3 code of all ring3 threads and then dump the whole RAM into file (dumping 4 GB RAM lasts about 2-3 minutes)
[14] forcing guest to map in nonpresent pages (typically everything is present in physical memory but only at least once executed or accessed pages are mapped into virtual memory space, hypervisor may force guest to map in not yet mapped pages into virtual memory (like pages which weren't yet executed either accessed), for performance reasons - win64 maps only pages on demand as code is executed / memory is accessed, most of pages are loaded in RAM but not mapped into virtual memory space of process)

[20] hypervisor based protection of process virtual memory
[21] when thread leaves context, hypervisor encrypts desired memory pages of process (e.g. code page of process, stack page of thread)
[22] when thread enters context, hypervisor decrypts protected memory pages - memory is decrypted only when thread is executing which prevents alien process (debugger, memory analysing tool) to inspect protected memory of process (preventing attack against inspecting memory at SMP is also possible - prevent attacker running at CPU1 to access memory when thread is executing at CPU0 so the memory is decrypted)

[30] debugger based on hypervisor
[31] ring3 process being debugged is created normally, so KERNEL32.CreateProcess dwCreationFlags.DEBUG_PROCESS is not set, then KERNEL32.IsDebuggerPresent=0 and also all process internals never have any flag indicating debugging
[32] guest exception handlers bypassed (OS doesn't know anything about exception / single_step / int3_breakpoint / debug_register_breakpoint until you decide to inject event back to guest)
[33] win64 debug subsystem completely replaced by hypervisor so debugger calls directly to hypervisor (never called KERNEL32.WaitForDebugEvent ContinueDebugEvent Get/SetThreadContext Read/WriteProcessMemory either their NTDLL equivalents ZwWaitForDebugEvent ZwDebugContinue either direct win64 syscall equivalents)
[34] more events than only exceptions may be intercepted, e.g. RDTSC instruction interception possible (not yet implemented, will be implemented only if asked for it)
[35] halt before loading DLLs or standard halt later at OEP hit (halting so early before DLLs loading is not possible using common debugger which halts at ntdll.DbgBreakPoint - DbgBreakPoint hits much more later, ntdll.DbgBreakPoint never hits in hypervisor based debugger - no need to do that, another technologies used to perform the break)
[36] more last branches recorded, 4 for Core 2 Duo, 16 for Core i7
more info

[status] 00, 10, 20 are finished and ready to use, 30 is still developed but basically is also ready to use

[screenshots]

[10] memory analysis by hypervisor - list of processes
[10] memory analysis by hypervisor - ring3 virtual memory page
[10] memory analysis by hypervisor - ring3 executable code page
[10] memory analysis by hypervisor - ring0 page holding part of ntoskrnl.exe (windows 2008 server R2 x64)

[30] hypervisor based ring3 debugger