I must concur with miles. All too often we (end users/system administrators) can get enamored with a utility that has some great features and neglect to understand how it functions and any consequences it may bring (known/unknown). "Trust but verify" I think someone once said. I certainly am not a programming expert so I can't disassemble such a tool. But I imagine I could (like miles) think of some testing that might validate if a system is being compromised by such a tool or if the effect is memory-resident only. In the past this is the kind of tool that our technicans and other system administrators would have rejoiced over. Imagine being able to access and service end users (non-Active Directory shop) Windows user accounts when they were out and we show up after a two-hour drive and could not log on to their profile? Awesome time-saver. Sure we could change their password from our admin service account, but then we would have to leave a note for a callback. This is a transparent "solution" that leaves the passwords intact...just completely ignored. However, if in our enthusiasm to have an easy solution (and not validating what is really happening) we run the risk of spreading some kind of malicious rootkit or sleeper issue behind. That is why (as miles suggests) Piotr's release of the source code could be valuable. It likely won't detract from the hard work he has done, but would allow skilled coders to understand and "proof" his work. I can only imagine he has his reasons. As has been noted in these comments, Nitin Kumar and Vipin Kumar have released their Vbootkit 2.0 code openly...and others have already started to review it ( [Dailydave] Nitin Kumar & Vipin Kumar: "please remember to give necessary credit to the authors" PKB. - http://lists.immunitysec.com/pipermail/dailydave/2007-April/... ) and compare it to the eEye BootRoot project http://research.eeye.com/html/tools/RT20060801-7.html . Based on what I have read and the research that miles and others have done on this and other bootkit tools that are "open" in the code, it likely (warning: logical conjecture here) hijacks the memory during the BIOS to bootloader process. From there it hooks INT 0x13 to control content of memory sectors loaded by NTLDR and begins patching areas of the kernel specifically dealing with the security profiles and user SAM files dealing with user logon authentication and the GINA processes. With these patched, the operator can access these profiles without any password input needed. What makes this tool (and Vbootkit) interesting is that they take the normal stay-resident MBR bootkit design http://www2.gmer.net/mbr/ and do it all on the fly (apparently) leaving no trace on the system behind. That's pretty sophisticated stuff. Particularly when it has been coded to work on both Windows as well as Linux kernels. This similarity with MBR bootkits likely leaves some (as seen in the comments) that it must be leaving a MBR bootkit behind. However the MBR on a test system can be hashed/checked (as well as inspected at the sector level with a hex-editor) by a number of tools such as mbr.exe - http://www2.gmer.net/mbr/mbr.exe or GMER - http://www.gmer.net/index.php and also including an off-line boot of the system using a LiveCD boot disk (to ensure the OS booting the system to check isn't compromised by any potential rootkits left on the system). As miles stated, the MBR is not changed by Kon-Boot. Mitigation? Pretty severe stuff: disable CD/DVD, USB, PXE booting of the system in BIOS. Then password the BIOS. Then (as thras has pointed out) you need to apply a pre-boot authentication solution and/or whole disk encryption; TrueCrypt, PGP, CE-Infosys for example seem to work great against Kon-Boot. Only then will you likely stand a chance against a Kon-Boot attack...at least on Windows systems. Please Piotr, release your l33t coding! We are dying to know your method!