Dump Port Driver

A port driver is a driver that implements an abstraction interface to hide underlying protocol details from higher level drivers.  In the case of storage driver stacks, the port driver provides a transport abstraction layer for the miniport driver, which implements hardware-specific protocols to interact with the controller. This allows the miniport to use the SCSI bus, for example, without having to implement its own interface. The miniport is linked against a specific port driver that implements the transport it targets. The port driver also communicates with higher level drivers in the driver stack for the storage device it controls.

As mentioned in I/O paths, the dump port driver is a “copy” of the port driver from the normal I/O path, heavily modified to remove unnecessary code (such as queuing) and to add logic to operate autonomously in crash mode.  There are three storage port drivers provided by Microsoft:  ataport.sys, scsiport.sys and storport.sys.  There are two dump port drivers:  dumpata.sys which corresponds to a stripped-down/modified ataport.sys and diskdump.sys, which corresponds to a stripped-down/modified version of scsiport.sys and storport.sys (which is just highly optimized SCSI).  When loaded into memory, the dump port driver will be named either “dump_diskdump” or “dump_dumpata”.

The dump port driver retains the minimum set of exported functions that a miniport would require in crash mode (the miniport developers have coded the driver to cope in crash mode, likely because they are required to sign NDA’s by Microsoft):  for example, diskdump.sys will contain necessary ScsiPortMoveMemory and StorPortMoveMemory exports so the miniport can manipulate device memory.  Pretty much everything else is different.  The list below points out some of the more notable differences:

  • No device object is created (eg, DeviceScsiport0)
  • SCSI pass through is not supported
  • Tracing and error diagnostics are removed
  • WMI and PnP support is removed
  • No PDO/FDO

The dump port driver also “colludes” with crashdmp.sys to perform crash and hibernation tasks.  It’s DriverEntry routine, invoked by crashdmp.sys during post-initialization, is non-standard:  the second argument is an undocumented structure used by crashdmp.sys.  The dump port driver fills in various fields in that structure with pointers to internal routines that crashdmp.sys uses as callbacks to complete I/O requests.  For example, the callbacks in diskdump.sys (on Windows 8) are:

  • DiskDumpGetTransferSizes
  • DiskDumpIoIssue
  • DiskDumpNotify
  • DiskDumpOpen
  • DiskDumpRead
  • DiskDumpWrite
  • DiskDumpWritePending

DiskDumpIoIssue is central to the Windows 8 version of the bypass technique used to invoke the crash path.  This function is a wrapper around the StartIo routine, which issues SCSI_REQUEST_BLOCK (SRB’s) directly to the miniport driver.  This operation is considered the “lowest level” operation in a storage driver stack.  The StartIo function is used directly in the bypass technique which is used in the bootkit defeat use case.

%d bloggers like this: