800+ IT
News
als RSS Feed abonnieren📚 Bootkit Disk Forensics - Part 2
💡 Newskategorie: Video
🔗 Quelle: malwaretech.com
DriverStartIo
As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1).
IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport's device object.
 |
| To start with, ebx is the address of the device extension (which is shared between all atapi devices). |
The call logic is something like this:
- Get the miniport's device extension from its device object (passed to us in the call).
- Get IdePort1's device extension from offset 0x5C into the miniport's device extension.
- Get IdePort1's device object from offset 0x0C into its device extension.
- Call IoStartPacket with the IRP and IdePort1's device object.
 |
| The relationship between the various objects. |
As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices' objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver's object.
Detecting DriverStartIo hook with WinDbg
For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it's stack.
 |
| Device stack for boot device on a clean system |
 |
| Device stack on a TDL4 infected system. |
As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it's not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use "dt _DEVICE_OBJECT <address>" to find the DriverObject field).
With most bootkits, the lowest level driver is always the one hooked, so I'll use this in my example.
 |
| DriverStartIo appears not to be hooked. |
You can see here that DriverStartIo isn't hooked because the address resolve to its proper symbol; however, this isn't actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1's device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi's driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1's device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original).
As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport's device object with the address of an identical driver object, without the DriverStartIo field modified.).
If you know what you're looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport's driver then making sure all the DriverObject fields point to the same address is all that's needed. This can be done a multitude of ways.
Method 1: DrvObj
The fake driver object will have the same name as the real one (in my case "\driver\atapi"), all you need to do is type "!drvobj \driver\atapi 2" to get the real driver's object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one).
Method 2: NextDevice
Starting with the miniport device, enumerate devices using "dt _DEVICE_OBJECT <address>" and the NextDevice field of each device's object. We're looking for any DriverObject field that dosen't match that of the miniport (this is the real driver object).
 |
| All devices should point to the real driver object, except for the miniport. |
Method 3: DeviceExtension
This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1's device extension at offset 0x5C isn't the miniport's device extension, then from IdePort1's device extension you can find its device object at offset 0x0C (IdePort1's device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: "dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>" is the miniport device object.
