Monthly Archives: October 2008

Microsoft Crash Dump Analysis weaknesses.


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/15/d187295720/htdocs/home/wp-content/plugins/deans_code_highlighter/geshi.php on line 2147

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/15/d187295720/htdocs/home/wp-content/plugins/deans_code_highlighter/geshi.php on line 2147

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/15/d187295720/htdocs/home/wp-content/plugins/deans_code_highlighter/geshi.php on line 2147

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/15/d187295720/htdocs/home/wp-content/plugins/deans_code_highlighter/geshi.php on line 2147

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/15/d187295720/htdocs/home/wp-content/plugins/deans_code_highlighter/geshi.php on line 2147

I’m going to discuss about Microsoft Crash Dump Analysis weaknesses, but in fact this blogpost is somehow an introduction to the next version of Win32DD 1.2. Indeed, the next version of win32dd will have crash dump generation implemented and some others things you’ll enjoy too.

Any reader who is interested in this topic is encouraged to refer to Andreas Schuster articles about the dmp file format, Mark Russinovich “Pushing the Limits of Windows: Physical Memory“, and Alex Ionescu’s excellent tool “meminfo“.

What’s the content of the full memory crash dump (*.dmp) files? In fact this is not a really a full memory snapshot. Only pages from MmPhysicalMemoryBlock ranges are copied.

For your information MmPhysicalMemoryBlock structure looks like that:

  1. span class=”co1″>// NumberOfPages * PAGE_SIZE is physical memory size.
  2.     PHYSICAL_MEMORY_RUN Run[1]; // NumberOfRuns is the total entries.

Here is how look the physical memory layout under Windows Vista 32bits with 1GB of RAM.
Only blue blocks are copied into the crashdump file while reading the MmPhysicalMemoryBlock, red blocks are reserved for devices, and others are not-reserved pages.


(Figure 1: Overview of Physical Memory Layout)

To identify these not-reserved pages I wrote a tool, available to download here (This version only works under Vista 32bits and above, with administrator privileges), to list drivers address ranges and system memory address ranges.


(Figure 2: Windows Vista 32-bits with 1GB of RAM)

In the sample above, there are 66 not-reserved pages (0,025%) including spare space at offset 0x00000000. (This page is well know from people who read Jonathan Brossard research about pre-boot password.). This page is not used during the O.S. is running, and the Run[0].BasePage is always equal to 1 (=0x00001000). It means there is at least one “not reserved” page with a fixed address which won’t be in the full crash dump memory during the BSOD process.

These pages could be used to hide code from crash dump without any hooks or structures modification. Full memory snapshot with classical tool can be a solution, but you no more benefit of the powerful crash dump analysis WinDbg’s feature. Win32dd 1.2 will take care of this problem to provide to forensics investigators a most powerful memory imager.