Reading and Writing to Raw Disk Sectors

Download source and binary - 287.47 KB

Introduction

This is a tool to read and write raw disk sectors on Windows systems (NT5.0, 5.1 kernels)
Inspiration to write this tool came to me when I had my laptop infected with some malware which was sitting on top of disk class driver as an upper filter and not allowing me to write to disk sectors using user mode disk editing tools like WinHex.

After a few days, I thought I should write a utility to read and write raw disk sectors by directly
communicating with disk class driver.

Background

To understand this article, one should have knowledge of C Programming and Windows Driver Programming.

We will go through the following topics to understand the utility in a better way:

Device stack for storage drivers
Enumerating device objects representing disks and partitions
How to read/write to sectors

1. Device Stack for Storage Drivers

Microsoft provides generic storage drivers for managing the storage on a logical level and thus abstracting hardware details from upper level file system and other file drivers. This is called disk class driver (a driver to handle disk class of hardware, i.e. "disk.sys").

Similarly to handle SCSI, IDE hardware devices, Microsoft provides generic port interface drivers to which drivers supplied by specific vendors for their disk devices can be dynamically linked.

E.g. scsiport.sys (old interface) storport.sys (new interface) is used as an interface to SCSI port while Pciidex.sys is used as an interface to IDE port.

2. Enumerating Device Objects Representing Disks and Partitions

There is a question which needs to be answered first.

How does the OS come to know that a harddisk has been attached to the system?

Whenever a new disk device is attached to the system, SCSI and IDE port drivers create device object (although PCI driver is the first one which comes into the picture) to represent a SCSI/IDE device and inform I/O manager about it. I/O manager in turn queries the devices to know their device id and vendor id. Depending on dev id and vendor id, I/O manager decides (through registry or INF file mechanism) which driver is suitable to handle this device (driver supplied by vendor) and loads the hardware device driver which creates device objects representing the Functions device objects for the device and attaches itself to lower devices created by respective port drivers.

I/O manager informs disk class driver (disk.sys) of new disks added into the system. Disk class driver then creates the device objects representing the raw disks.

If a valid partition is present on the system, then it creates device objects for the respective partitions too.

E.g. Device objects created by disk class driver are as follows:

\Device\Harddisk0\DR(0) --> Represents Raw Harddisk 0
\Device\Harddisk0\DP(1)0x7e000-0x7ff50c00+2 --> Represents partition 2 of disk 0

The first hexadecimal digit shows the start and thsecond shows the length of partition.

That means all the device objects representing disks and partitions are chained in driver object of disk class driver (i.e. disk.sys).

Now to enumerate the device objects created, you first need to have access to the driver object of disk class driver.

The solution is to use undocumented Object management kernel function "ObReferenceObjectByName" prototype:

NTSTATUS ObReferenceObjectByName(
        PUNICODE_STRING, 
        DWORD, 
        PACCESS_STATE, 
        ACCESS_MASK,
        POBJECT_TYPE,
        KPROCESSOR_MODE,
        PVOID,
        PVOID *Object);

The first argument is a Unicode string, i.e. "\Driver\disk", object receives the pointer to the DRIVER_OBJECT of disk.sys.

From DRIVER_OBJECT, you can enumerate all the device objects created by disk class driver and store pointer to device objects responsible for raw disks and partitions. The following snippet will clear the things:

PDEVICE_OBJECT pDeviceObject;
  ..... 
// DeviceType 7 corresponds to FILE_DISK_DEVICE Type Device Object and

 // It should have name too that's why Flags checks for 0x40 (DO_DEVICE_HAS_NAME )

                if (pDeviceObject->DeviceType == 7
                        && (pDeviceObjectTemp->Flags & 0x40))

3. How to Read/Write to Sectors

Once you have pointers to device objects for raw disks and partitions, reading and writing to those raw disks/partitions is not a difficult thing. You only have to do a IoCallDriver on the respective device object with IRP_MJ_READ/IRP_MJ_WRITE function codes initialized in the IRPs.

The following code will make things clear:

LARGET_INTEGER lDiskOffset; 

PDEVICE_OBJECT pDevObj; //Device object representing disk/partition

KEVENT Event; 

// Trying to read some arbitrary sector number 1169944 and 
// by default assuming sector size 

// 512 

..........

..........

        lDiskOffset.QuadPart = 1169944*512;
        sBuf = ExAllocatePool(NonPagedPool, size);
        
        if (!sBuf) {
            ObDereferenceObject(pFileObj);
            return STATUS_INSUFFICIENT_RESOURCES;
        }
        KeInitializeEvent(&Event, NotificationEvent, FALSE);
        memset(sBuf, '0x00', size);
        pIrp = IoBuildSynchronousFsdRequest(IRP_MJ_WRITE/*IRP_MJ_READ*/, 
			pDevObj, sBuf, size, &lDiskOffset, &Event, &ioStatus);
        
        
        if (!pIrp) {
            ExFreePool(sBuf);
            return STATUS_INSUFFICIENT_RESOURCES;
        }
        
        status = IoCallDriver(pDevObj, pIrp);

        if (status == STATUS_PENDING) {
            KeWaitForSingleObject(&Event, Executive, KernelMode, FALSE,    NULL);
            status = ioStatus.Status;
        }
        ExFreePool(sBuf);

..........

Given above is just a sample code for sending a write operation to sector number 1169944.

Points of Interest

While writing the code, I was just doing a READ operation for verifying my results. I didn't take care while passing data buffer for write operations in the design (Please see driver code for more explanations). So I implemented an ugly hack for passing user mode buffer for write operations. I will improve it in future releases.