[kareldjag/michk]

Unpopular projects that should be known...

A pdf technical presentation (Ramooflax in english):
https://github.com/sduverger/ramooflax/ ... ementation
Slides: https://raw.github.com/wiki/sduverger/r ... des_en.pdf


This helps for real time full OS analysis (FORENSIC or DEBUGGING).
Works quite well with AMD, from USB 2.0 client via a python script.
Minimal hypervisor...but great functions as BIOS is virtualized!
Needs unfortunately more tests and supported platforms (processors/OS).
Challenge done in all case.

NB. As an extension to this post, Virtdbg project is also interesting:
http://esec-lab.sogeti.com/dotclear/pub ... slides.pdf
Host project: http://code.google.com/p/virtdbg/

Rgds

[feryno]

ah, topic which I love

I have small notes:

ramooflax_en.pdf -> chapter 2.3 Architecture -> Setup

The setup then retrieves physical memory size (RAM) and relocate the
VMM at its end. By providing the VM a slightly lower RAM size, we can
be sure that the VM won't try to allocate physical memory pages used
by the VMM (except targeted attacks of course).

ramooflax_en.pdf -> chapter 8 Events filtering -> 8.1 Software interrupts

Software interrupts intercept is only performed when the VM is in real
mode. It allows specific filtering of BIOS services requests mainly related
to SMAPs and GateA20 via int 0x15. The interception leads to the
emulation of the service if needed, or redirect real mode code execution
to the correct IVT handler.

the method of intercepting real mode interrupt 15h to report less memory to the guest can be effectively bypassed by replacing int 15h (opcodes 0CDh, 15h) with a code like

Code: Select all

; real mode 16 bit code to replace the int 15h instruction:
push gs
push 0
pop gs
push word 0202h ; flags
call dword [gs:15h*4] ; int 15h vector
pop gs

using the above sample, the guest is able to retrieve the real E820 smap, not the reduced memory size as the hypervisor wishes
but when the hypervisor is already living in the stolen and hidden memory part and protects it by nested paging, then the guest can only detect that but can't do anything with that (at worst situation the guest crashes when it attempts to use the stolen memory part, I also read a pdf where authors had an idea to substitute the stolen memory from the disk - something like swap)

second note -

ramooflax_en.pdf -> chapter 2.5 Limitations

The hypervisor only virtualizes a single Core, which does not prevent VMs
to make use of the unvirtualized ones (discouraged). Cores virtualization
is relatively complex to setup in our architecture, mainly because the
Application Processors or Cores initialization must be done by the hyper-
visor to enable virtualization on each of them, but must also intercept
initialization done by the VM (standard SMP kernel boot code).

really pity that the author of the hypervisor surrended here without fight
if efficiently encoded, waking up all APs requires about 100 bytes of code + few bytes (4 bytes exactly on AMD64) to put them into "sleeping" state (Intel virtualization has better possibilities than AMD in this situation - intel CPU can be put directly from host mode into wait-for-INIT/wait-for-SIPI state at vmentry, no need for the guest to execute anything)
running hypervisor on application CPUs also requires intercepting and handling some events else the hypervisor won't survive "the fire of INIT/SIPI" on application CPUs delivered to them from the bootstrap CPU (INIT IPI is capable to terminate virtualization when hypervisor doesn't care)

[ramooflax]

Hi,

Thanks for the interest !

About the physical ram size interception, you are correct. A guest may finally know the real amount of RAM by different means. The intercept was just here to help guest OS boot using its classical method (say e820) and properly initialize its physical memory manager with the correct RAM amount. That's all. There were no ninja stealth trickz ! I think that a malware can easily, for now, discover the hypervisor and other stuff. It was not developped to be stealth, only to provide a flexible way to analyze an OS. But i would be really interested if you find some trivial way to crash the hypervisor, i did not really challenged it by the way.

To be fast, i could have fixed the bios stored SMAPs directly and let the guest read them, instead of providing my own copy. I also could have maintained a shadow IDT, there were so many ideas. But the intercept was a good way to check for correct real mode interrupts management as well as v8086 virtualization before Intel introduced Unrestricted guest mode. This piece of code is a ghost from the past :)

About the multi-core lazziness, despite the initialization there can be many synchronization issues that came into the game. I didn't had time to cope with it. I also experienced some troubles with ioAPIC.

[feryno]

Hi ramooflax,
the article you wrote for the whole world about your hypervisor is excelent.
On AMD SVM platform, the only way to survive INIT on APs for me was to emulate APIC (not the whole APIC, only very simple emulation). Intercepting INIT / redirection of INIT into #SX didn't help me to pass this situation. Seems that writing 0 into EFER (INIT does that) is capable to kill hypervisor immediately. Protecting hypervisor from guest writing 0 into EFER.SVME by guest execution of the WRMSR instruction was quite easy, but protecting hypervisor from guest sending INIT IPI from bootstrap to all APs was nightmare for me. Luckily solved that.
Hope I have time to write same article about that and post it.
Certainly mustn't release binary (currently 10000 bytes) / share sources (about 200kB asm code) / be too detailed for public (maybe only for trusted people). Would be disaster if that fall into wrong hands / brains (new kind of bootkit malware for mafia).

You wrote about "multi-core lazziness" - it's not lazinness! It is about saving a lot of time and spend it on better things (I spend a lot of time until realized the necessity of APIC emulation and implementing it as simple as possible).

Cheers, Feryno