Category Archives: Forensics

Reply to HBGary — and personal notes.

One HBGary developper wrote a blogpost about windd entitled “Windd – Almost there, but not quite…“.
HBGary says *they* but I would like to say to readers that windd is a project that I developped and maintain alone, on my spare time.

More and more people are using windd so it looks I have to explain some things about the behavior of Windows Memory Manager and windd itself. Reading HBGary blogpost really made me feel enthusiastic because I recently complained about the lack of feedback on windd which is really frustrating when you lead a free project.

As you probably know early version of windd were open-source, but mainly because of the lack of feedback windd is no more open-source but still free. As far I have seen, open-source doesn’t mean people understand what you wrote or read the code, it is more like a philosophical aspect like “We have access to the source”. Anyway, people are still free to send me an e-mail, at matt/msuiche/net if they have questions about the internal behavior of Windd, to insult me or just to thank me.

Back to HBGary blogpost, we can read :

  • Is windd acquiring all of the available physical memory on the system?
  • Would a “raw format” image dump of a 64-bit vista machine load properly into HBGary’s Responder?
  • Should windd memory images that contain greater than 4GB of ram be considered admissible in court?
  • Was windd really the first tool to support physical memory acquisition on Windows 7? (as claimed by the author)

Author replied “No” to all questions above.

In this blogpost, I am going to provide details about the bug for both technical and no technical people by explain how windd works. The main problem with HBGary article is that they mix accessible physical memory and accessible physical memory address spaces. So I assume most people do not even know the difference between these two *things*.

In July 2008, Mark Russinovich wrote a very well explained article about Windows Physical Memory Manager entitled “Pushing the Limits of Windows: Physical Memory“. In this article Mark also used a tool written by Alex Ionescu (co-author of Windows Internals 5th) called “meminfo” to retrieve information related to Windows PFN Database.

In this article Mark explains what physical memory, physical address space and PFN Database are.
For lazy readers here is a short summary.

Figure above is the physical address space.
Red blocks are devices address space, blue blocks are physical memory and the “Inaccessible RAM” (only by Windows) is a reserved space in the physical memory for the Operating System to proceed to the translation from Virtual to Physical addresses.
Joanna Rutkowska paper entitled “Defeating Hardware Based RAM Acquisition” is a good reading if you want to know more about “Red blocks”.

Figure above comes from meminfo tool which display Memory Manager physical memory blocks. These entries describe how the physical memory is “splitted” in the physical address space which interpreted by the CPU. For the remind, DMA Access provides access to physical memory and not to the physical address space.

We firstly notice the highest physical page is 0x120000 (1179648) which correspond to size of the physical address space and NOT to the size of physical memory.
Secondly we notice physical addresses are above 4GB even if the machine has only 4GB installed. To retrieve the size of installed/detected physical memory we have to add the size of each block as follows:
(0x9F000 – 0x1000) + (0xDFE6D000 – 0x100000) + (0x120000000 – 0x100002000) = 0xFFE09000 (~4GB)

#1 Bug HBGary is talking about only concerns the RAW memory dump generation with windd (v1.3.0.x <= Version < v1.3.0.20091113 (fixed version)).
The bug was the following: Windd was reading blue blocks and wrote them directly in a raw dump file like the DMA-way, then it means red-blocks were missing. Impact was the PFN database was invalid which means Virtual to Physical address translation was impossible. BUT windd DOES acquiere all available physical memory. Present version of Windd produces a “CPU-like” memory dump (physical memory address space) and fills red blocks with null pages.

#2 Second question was about HBGary’s Responder. I don’t know this product and I never used it. But it would mean HBGary does not support DMA-style memory dump.

#3 For the third question, please refer to #1 and #2.

#4 Regarding the last question about the fact that I claimed that windd was the first tool support physical memory acquisition I do not remember saying that. I just remember I claimed several times windd was a great tool because it can produce Microsoft crash dumps which has great advantages mainly because of Windbg. Then, windd also aims at being used by troubleshooters and/or kernel developpers and not only by forensics investigators.

For instance in your blogpost I can read “NOTE: HBGary’s Responder does not yet fully support the automatic analysis of Windows 7 which is why HBGary had elected to not publicly advertise Windows 7 acquisition support” — The difference between windd and average memory acquisition tools is this point: This problem does not exist with WinDbg. Windbg supports Microsoft Crash Dump since Microsoft started to work on Windows.
Analysis is very important, if someone produces a dump and is unable to analyse it this is more or less like if someone would say “I have a new car but I do not know how to drive it”.

Thanks again to HBGary for helping me to improve windd utility and I hope they like the new version.

Undocumented Windows Vista and later registry secrets

In fact, this new key category appearred for the first time in Windows XP, formely called Whistler, in early 2001. Yes, almost 9 years ago. But its structure CM_BIG_DATA had been removed from Microsoft Windows XP public symbols but not from Windows Vista and later symbols.

Basicaly, this “secret” registry key had been briefly introduced in Windows XP Kernel Enhancements changelog as the following:

Windows XP improves the way the registry handles big data. In versions before Windows XP, if an inefficient application constantly increased a value with a small increment, it created a sparse and wasteful registry file. Windows XP solves this problem with a big cell implementation where cells larger than 16K are split into increments of 16K chunks. This reduces fragmentation when the data length of a value is increased within a certain threshold.

If we take a closer look to CmpGetBootValueData() or CmpGetValueData() functions which handles big data keys we can notice CMHIVE.Version must greater or equal to 4. I guess, this is the Whistler registry version.

To be validated as big data key pointer, CM_KEY_VALUE cell must respect the following conditions:
– CM_KEY_VALUE.DataLength must be greater than 0x3fd8 and smaller than 0x80000000

Then CM_BIG_DATA key first chunk is retrieved using CM_KEY_VALUE.Data as cell offset.

To be validated as big data key, the CM_BIG_DATA cell must respect the following conditions:
CM_BIG_DATA.Signature must be equal to 0x6264 (“bd”)
CM_BIG_DATA.Count must be greater than 0
CM_BIG_DATA.List must be different from 0

According to these information Windows do assinity check to avoid buffer overflow and re-compute CM_KEY_VALUE.DataLength for assinity check like the following:
ASSERT(CM_KEY_VALUE.DataLength < = (CM_BIG_DATA.Count * 0x3fd8))

Then, each CM_BIG_DATA.List entry are read CM_BIG_DATA.Count times as cell index, and 0x3fd8 bytes maximum are copied each time into the output buffer.

It means data chunk are not exactly 16K bytes (0x4000) but 0x3fd8. The difference of 0x28 bytes is in fact the cell header.

If you want to read further information about Windows Registry format, I suggest you to refer to Tim Morgan, Peter Norris documents and moyix blog.

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.

X-Ways Forensics Beta 2 and hibernation file. (coincidence?)

X-Ways (WinHex editor) Forensics Beta 2 now includes hibernation file(hiberfil.sys) support for Windows XP 32-bit only. Please notice, Sandman library/framework is an open-source project under GNU General Public License v3 to read and write the hibernation file released 2 months ago…

Posted on Friday, Mar 28, 2008 – 1:05:
* Ability to decompress Windows XP 32-bit hiberfil.sys files, whether
active or inactive, to get a dump of physical memory with all in-use
pages from a previous point of time when the computer entered into
hibernation, as well as individually carved xpress chunks from
hiberfil.sys files, including xpress chunks located in the “slack” of
hiberfil.sys that are even older. This feature is available in Edit |
Convert. (forensic license only)

(PS: I’m not beta-tester)