"Hardware virtualization offers great power to malware that can harness it. But with great power comes great responsibility". It takes an Olympic class dick to say something like that. It's an excellent example of the hyper-emphasis placed on technology in the current climate. God save the queen.

Hypervisor malware is, I would agree, easy enough to detect and once detected, easy enough to defeat and erase from a System. And invariably all such malware is just a meal ticket by the backdoor akin to a raid of the fridge in a Playboy mansion...... which many would cite as being a complete and utter waste of Time in an Energising Environment [which spookily enough, the little Blue Pill may rule with some, making a Junkie lord of that which Nature provides for Free. A Lack of Intellectual Drive in Sexual Matters resulting in a Selfish Disposition, further exacerbated by a masking Agent. But hey, if the Real Thing isn't available, who's to blame for wanting a clone of it.]

However, I digress/wander and wonder on a Tangent.:-)

Hypervisor Palware* as a rootkit though, will only be detected whenever it surfaces, having completely infected the System and thus effectively having it, the System, under ITs Proxy Controls.

The System then is vulnerable to the whim of a Takeover although the wiser of Incumbent Administrators will initiate a Makeover realising that Control of the System has been lost.

*Hypervisor Palware is Virtualising Software creating Intelligently Designed Machines to Mentor and Monitor Operating Systems with ITs XTremes in TakeOver and Makeover of Bored Room Play.

So you can detect if you are running on a VM by looking at hardware oddities. But how does the virus detector know it is running in a malware VM? And this will get worse, not better, as operating systems use paravirtualisation more and there's no "real hardware" to look for oddities in.

If it really is undetectable, how can you show it's installed? The money is safe.

Forget about obscure minutiae of a particular set of hardware. The malware must be stored both on disk and in RAM and it must occupy some space. This will reduce the ammount of truly free space in both places. Either the rootkit owns up to this (511MiB of RAM?) or it tries to simulate having the full whack (Counting proof and the compression limit). Either way is easily detected regardless of which revision your motherboard is.

Theres no reason to buy Vista - unless its to play DRM protected things that will only run on Vista.

Run it in a VM and theres no DRM.

Its not going to happen if they can find a way of stopping it.

is already in use by microsoft in the xbox360 hypervisor. Originally they wanted to build this into vista too, but current day cpus are not really capable of true virtualization. On the xbox 360 hardware the hypervisor runs in the cpu's internal ram and takes it's keys from the cpu's internal efuse based eprom. The external ram and the disk is not used. The actual hypervisor code loads in an encrypted form from the boot flash, along with the dashboard. It's the safest solution but as it was originally ibm's idea for cypto boxes, one error and the system is automatically bricked.

For a pc based hypervisor, one would need to add it's code to the bios and reserve some ram in the bios data area or in the system management mode ram, which is already hidden from other modes. (at least marked as not available or reserved by the bios) The original concept for the vista hypervisor wanted to place the drm code into a separate virtual partition, but since the takeup of hypervisor ready cpus are very low, microsoft choose a trusted kernel approach instead of the untrusted kernel, trusted hypervisor hardware configuration. Currently the only x86 platform that fully supports using a hypervisor is apple's x86 line. (it also uses efi instead of the old pc bios, so the system can be secured against the users before booting the os)

A hypervisor running on vista is possible, by booting it before the os, making all hardware access transparent and only trap those calls that are interesting for the writer or required for hiding it. The ram used for the code can be just below the extended bios data area, that is the memory vista leaves alone, regardless of it's size (as long as it's less than 64Kb and within the first 640Kb). The code can be hidden on the disk after the main partition table and before the first partition or after the last partition and before the reserve partition table. Old bios extension patches and boot monitors were often placed there too. The code will be loaded before the os boots and after the hypervisor is running in transparent mode the os can be chainloaded. There are some 32 bit pmode examples for such system on os development boards and in usenet archives. Adding hardware acceleration and 64 bit support (intel's vm solution) would eliminate the timing problems what made the classical vm code detectable.

Great insight, this guy. "Malware is easy to find, all you need to do is to find what part is missed".

Sure, and fighting crime is easy too - all you need is to catch all the criminals.

With "experts" like that, no wonder the world is being taken over by dimwits.

Total agreement with Pascal. If you find the part she missed, she will fix it and you basically end up in an development race between two pieces of software. At any given point in time she has an untracable version of a root kit on your system or she is in the progress of fixing that flaw.

However if you were to 100% conceal the root kit and show the hardware as a 100% direct comparison to it's true state - how will you represent the ram the malware would alledgy run in? The malware must exist somewhere and if you know the system started with 256MB RAM why not attempt to fill it all (and any buffers she maybe using to counteract) with 1's and see what happens? That would potentially work in my eyes for finding any given malware but truth be told - how can your malware tool correctly understand the different versions of software installed and how could it tell between what the user is typing and what the memory manager thinks is (the malware's) executable code?

Truth be told tho - she's got an easier job than you. She can control your application's input and outputs directly to minipulate your ersults and if not, she can just mute your ability to warn the user.

Your best malware detection would itself be a VM machine outside of her VM. But whoever gets the most outside of the VM (and actual true hardware) is the first person that wins!!!

just some thoughts

If it is so easy to create this 100% undetectable rootkit, why does Joanna Rutkowska require $412,000 to create a version to be tested?

The person writing the detector isn't asking for $412,000.

The reason is that the detector author can pick any obscure hardware idiosyncrasy to use in detection.

If need be, the detector author could introduce additional hardware with an unexpected idiosyncrasy. And they could do this after the rootkit is installed.

Whereas, 100% undetectable the rootkit creator must anticipate all idiosyncrasies, including future ones that might be installed later, during diagnosis.