Bootkit hard drive Forensics-Lecture 2

Bootkit hard drive Forensics-Lecture 2

DriverStartIo routine

In the previous article, we can know that DriverStartIo is used by micro ports to execute some hard disk I/0 requests. Like the IoCallDriver routine, DriverStartIo generally runs two parameters, one device object and one IRP. However, most hardware devices do not access and connect through the microport. In most cases, they access through the normal port. (In the first lecture, we will introduce ports and microports)

Note:

IRP: it is also called an input/output packet. It is called an I/o request packet.

The IRP_MJ_SCSI routine generally points to the IdePortDispatch routine in the atapi. sys driver. Through Reverse compilation, we can find out how these devices send requests receive information from the DeviceExtension layer.

At the beginning, we can see that ebx is an address of device extension, which can be shared by all ATAPI devices.

Call logic sequence:

Get the device extension of the micro port from a device object.

Get the device extension of IdePort1 from offset 0x5C of device extension on another microport.

Get the device object of IdePort1 from offset 0x0C in other device extension.

Call the IoStartPacket routine to the device object specified in the IRP and IdePort1 columns.

 

Note:

 

Device extension: DEVICE_EXTENSION is another important data structure related to device objects.

Device object: the object of a device. It is the data structure of the driver in the kernel. Each driver has a unique DRIVER_OBJECT, And the IO Manager uses the driver object to represent each device driver.

This diagram describes the information of a bootkit component.

The atapi. sys driver can create the device port and IdePort of the micro-end device, and the DriverObject routine of the two devices specifies an identical driver component. Therefore, it is very easy to use DriverStartIo to hook the child or insert rootkit.

Use WinDbg to detect DriverStartIo rootkit

To detect DriverStartIo rootkit, follow these simple steps.

First, we can find the boot disk and disk stack according to the following command

Disk stacks displayed in a clean System

 

 

Disk stack displayed after rootkit Infection

Based on my previous article, I want to make some corrections. I have said that commands cannot be used for systems infected with TDL4! Drvobj and! Mongobj, But I found my research was wrong... This is not the case.

If you want to check each driver component in the hard disk stack, you can use the "dt _ DEVICE_OBJECT <address>" command to find the DriverObject routine. Most of the bootkit backdoors are in the underlying driver file, so this command will be used for your reference.

DriverStartIo shows no bootkit

You can see that DriverStartIo is not implanted with bootkit, because these addresses are properly displayed. However, this is not a real driver object. As I said before, IoStartPacket can only be called with IdePort1, not the hard disk's micro port. This means that when IoStartPacket calls DriverStartIo, it will get a driver object from the DriverObject routine and then get the DriverStartIo routine. Obviously, this bootkit is embedded in DriverStartIo. It simply creates a copy of The atapi driver object and then modifies the DriverStartIo routine. Then, create a DriverObject routine driven by IdePort1, then it will point to a new address, that is, a malicious driver object.

The fact is that this TDL4 has infected the system and it has successfully implanted bootkit in the atapi driver object, then, replace the DriverObject routine of the drive of the disk micro-port with all the addresses that are malicious code. DriverStartIo is not required.

There is also a simpler method to detect all false driving objects. Drivers of all devices point to the same driver object. Therefore, you only need to enumerate the micro-port drivers of these devices, so that you can check whether all the DriverObject routines point to the same address.

The following describes these methods.

 

Method 1: DrvObj

The driver object with bootkit has the same name as the real driver object, that is, "\ driver \ atapi ". In this case, you need to enter the command "! Drvobj \ driver \ atapi 2 "to view the driver objects that are normal. In the figure below, you will find that the address of a driver object has changed, so it may have a bootkit.

Method 2: NextDevice

You can run the "dt _ DEVICE_OBJECT <address>" command to list devices. Each drive object contains a routine such as NextDevice. In this figure, we can see all the DriverObject routines. If one of the routines calls the driver object of the microport, this routine may be infected with bootkit.

Therefore, all devices should point to a correct driver object, but this microport is not.

Method 3: DeviceExtension

This is the last method. device extensions can be upgraded from one system to another. However, as I mentioned earlier, you can find the device extension of the IdePort1 routine in offset 0x5C, instead of searching for the device extension of the micro port. In this way, we can find the device object of the IdePort1 routine in offset 0x5C, because the device object in IdePort1 specifies a real driver object. With a simple command, we can find the DeviceObject.
The command is "dt _ DEVICE_OBJECT poi (@ C ++ (nt! _ DEVICE_OBJECT *) <address>)-> DeviceExtension) + 0x5C) + 0x0C) ", where" <address>"