"A bootkit is similar to a rootkit, so it serves to enable and continued privileged access to a computer while actively hiding its presence from administrators by subverting standard operating system functionality or other application" (Wikipedia).
The main difference is that a bootkit infects the boot sequence of the computer. It means that instead of a common rootkit which represents a driver in the system, the code of the bootkit is injected into the master boot record of the hard disk, so that the bootkit is harder to detect because it is executed before the operating system and can control everything.
This article will try to answer to several questions about Bootkits :
- How can a bootkit subvert the operating system since it is not already executed when the bootkit runs?
- Why using a bootkit instead of a rootkit?
- Why bootkit is useful against encrypted systems?


A bootkit aims to subvert the operating system, and to hide his presence into it.
So how can it be resident, and subvert the operating system since the bootkit executes itself before the loading of the operating system?


Basically, Windows, Linux, or others operating systems communicate with the hardware through what we call interrupts, or IRQ.


Here is the Wikipedia definition of an interrupt request:
"When working with computer hardware, installing and removing devices, the system relies on interrupt requests. There are default settings that are configured in the system BIOS and recognized by the operating system. These default settings can be altered by advanced users. Modern plug and play technology has not only reduced the need for concern for these settings, but has virtually eliminated manual configuration."


So, for example, when the operating system wants to read a part of the hard disk, it has to do an interruption. Then, the interrupt (here 13h) handler (function described in a descriptor table) will handle and complete the request made by the operating system.
The solution for the bootkit is to hook the interrupt table in order to modify these requests. To hook means that, instead of the original handler, the bootkit puts an internal address in the interrupt table in order to handle requests instead of letting them being completed by the original handler.
So what is the interest of hooking interrupt 13h? It permits to rewrite portion of code of the operating system. When the kernel will be loaded, you can patch some parts of his code in order to subvert it. When you are able to overwrite parts of the code you want, you are also able to patch code integrity tests or other protection mechanisms, so you have the complete control of the system.
This is the reason why using a bootkit instead of a rootkit is interesting. A rootkit is able to hide itself, but some of his tricks can be detected. In the case of a bootkit, it's very difficult to detect at runtime that the operating system has been subverted since all security mechanisms has been patched during the boot process of the computer.


We can admit that these types of attacks are not easy to detect. For example, if someone wanted to write a driver or a userland application (with administrator privilege) which reads the master boot record in order to compare it with the original master boot record, the 13h interrupt handler that is hooked by a malicious function can reply to the operating system that nothing has changed since last time, and the operating system have to trust it. So any of the software protection that we can imagine can be easily patched and aren't be a serious solution for strong security.
The only way to get a real security is to have an hardware solution which is able to prove that the boot sequence has not be modified.


So why are we focusing on bootkits in an encrypted system?
Disk encryption software solutions permit to cipher every single byte on your hard drive, and make all physical readind/writing impossible, protecting your documents and your operating system.
The only part that can't be encrypted is the boot sequence which is located in the master boot record. This part is executed at boot time, ask you for a password which will permit to decrypt all the data (so, it's normal that this part can't be encrypted).
So, logically, a bootkit is able to rewrite part of code in the unciphered boot process, and to hook interruptions in order to control the operating system.


This attack vector was theoretically valuable, but difficult to exploit because of small space left in the encrypted data to put bootkit code. Since around 2 years, some attacks like stoned bootkit have been done against TrueCrypt encryption solution, showing that it is possible to subvert the operating system, even if this one is fully ciphered.

Microsoft's encryption system (Bitlocker) use hardware protection (Trusted Platform Modules) in order to prevent bootkit attacks.

Since one or two years, several researchers have put in relief the lack of hardware protection in TrueCrypt, since hardware protection is actually one of the best security model we can imagine.