As mentioned in my recent presentation at Brucon 2014, I’ve written a small Windbg extension for exploring basic information about the Windows crash dump stack. You can download the source code here. This is currently the only supported platform, but it’s only a few hours of work to add other platforms, which I hope to accomplish soon. Of course, feel free to commit your own changes to the repo and I will check them out.
To use the extension, first, make sure you have all symbols loaded (“.reload”). The extension is more useful with symbol resolution. You will want to attach x86 Windbg to a virtual machine running Windows 8.0 x86.
To load the extension:
0: kd> .load <path_to>\DmpExt.dll
To get extension usage:
0: kd> !dmpext DmpExt 1.0 ----------- Target OS build: Win NT 6.2 Available commands: -stack: Display the crash dump driver stack -crashdmp: Display details about crashdmp.sys -filters: Display details about crash dump filters
Or simply use !help:
0: kd> !help Commands for C:\<path>\DmpExt.dll: !dmpext - The !dmpext extension displays information about the crash dump infrastructure.
-stack command simply enumerates drivers in the crash dump stack:
0: kd> !dmpext -stack Crash dump stack drivers: dump_LSI_SAS dump_dumpfve dump_diskdump dump_dmpflt
Here we see that the dump miniport (LSI_SAS.sys), dump port (diskdump.sys), and two third-party filter drivers (dumpfve.sys and dmpflt.sys) are all loaded into the stack. These drivers make up the crash I/O path to disk.
-crashdmp command will display information about the operating system’s book-keeping driver, crashdmp.sys, such as the image base and dump block pointer, which is the starting point for the bypass technique discussed on this website:
0: kd> !dmpext -crashdmp Crashdmp.sys information: Image entry: 0x81a4dcb0 Image base: 0x82fe5000 Initialized: 1 Crashdmp GUID: 0e1d2972-65af-4ac1-bfa3-cef4ab0c38fe Dump block: 0x82fee300 Context: 0x82fee298 Crashdmp device GUID: d8e2592f-1aab-4d56-a746-1f7585df40f4 Crashdmp call table (0x81a4e0c0): Version 1.4 0 => crashdmp!CrashdmpInitialize 1 => crashdmp!CrashdmpLoadDumpStack 2 => crashdmp!CrashdmpInitDumpStack 3 => crashdmp!CrashdmpFreeDumpStack 4 => crashdmp!CrashdmpDisable 5 => crashdmp!CrashdmpNotify 6 => crashdmp!CrashdmpWrite 7 => crashdmp!CrashdmpUpdatePhysicalRange 8 => crashdmp!CrashdmpResumeCapable 9 => crashdmp!CrashdmpGetTransferSizes 10 => crashdmp!CrashdmpLogStatusData 11 => crashdmp!CrashdmpReady
-filters command will display information about 3rd party vendor crash dump filter drivers, such as whole disk encryption solutions that encrypt hibernation and crash dump file contents:
0: kd> !dmpext -filters Installed dump filters: Listhead at 0x880b18ec Filter at 0x8809a798: Version: 2.0 DumpStart: dump_dumpfve!DumpStart (9081a7cc) DumpFinish: dump_dumpfve!DumpFinish (9081a84e) DumpUnload: dump_dumpfve!DumpUnload (9081a912) DumpWrite: dump_dumpfve!DumpWrite (9081a858) DumpRead: dump_dumpfve!DumpRead (9081a8da) Dump data: 8809e000 Filter at 0x88099318: Version: 2.0 *** ERROR: Module load completed but symbols could not be loaded for dump_dmpflt.sys DumpStart: dump_dmpflt (909ed490) DumpFinish: dump_dmpflt (909ed3e0) DumpUnload: dump_dmpflt (909ed4a0) DumpWrite: dump_dmpflt (909ed4d0) DumpRead: dump_dmpflt (909ed480) Dump data: 00000000
In the output above, Microsoft’s full volume encryption driver (dumpfve.sys) and my own dmpflt.sys filter driver are loaded in the stack. The filter block pointer provided in the output is the starting point for hijacking the crashdmp.sys book-keeping structure as outlined in the filter hijack technique.
Happy crash dumping!