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 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 0×120000 (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 – 0×1000) + (0xDFE6D000 – 0×100000) + (0×120000000 – 0×100002000) = 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.

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:

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 0×00000000. (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 (=0×00001000). 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.

In November 2007 at PacSec'07, Tokyo, Japan, Nicolas Ruff and I (Matthieu Suiche) presented how to create a readable physical memory dump from the undocumented Microsoft hibernation file.

Last month, I published an open-source public version of this project called SandMan Framework. This framework allows manipulating the hibernation file for offensics (malicious) or forensics uses.

Today, I am going to release a Proof of Concept of the sandman attack using SandMan Framework. This PoC consists in elevating a user CMD shell to SYSTEM level under Windows XP SP3 RC1.

Sandman Framework offers a wide range of possibilities, both offensive and defensive. Like cryptographic keys retrieving in popular encryption software (e.g. TrueCrypt, GPG), privilege
escalation (cf. PoC), login without any password, and so on.

All Windows versions are concerned, from Windows 2000 up to Windows 2008, Windows Vista SP1 included (and possibly Windows Seven).

The following video shows how the system can be subverted in a few minutes. The following points are highlighted:

* Deactivating hibernation feature does not solve the problem.
* The sandman attack affects every Windows version, from Windows 2000 to Windows 2008, 32- and 64-bit alike.
* We can read and write everything everywhere in the physical memory (RAM).
* This attack is feasible in real life on every computer with no hardware requirements.
* The attack has no time limitation. If a computer has been hibernated one
week ago, extracting his physical memory is still possible.

This is far more powerful than other recently demonstrated attacks against physical memory, like Cold Boot and FireWire attacks.

“keep you free from sin, till the sandman he comes”
(Enter SandMan — Metallica)

The hibernation file opens two valuable doors: The first one is (live?) forensics analysis for defensive computing. Hibernation is an efficient and easy way to get a physical memory dump. But the main issue about it was: How to read the hiberfil.sys? That’s how the idea of SandMan born. The second one is a new (ou pas) concept we will be introduced and called “offensics” which is a portmanteau from “offensive” and “forensics”. If we can read hiberfil.sys, can we rewrite it? The answer is: Yes, with SandMan you can.

SandMan was firstly introduced at PacSec, Japan in November 2007, slides are available in the SandMan section.

* SandMan provides a C Library and a Python portage.

Here is a sample of implementation in Python.

* Furthermore, SandMan is open-source and released under GNU General Public License v3, you can have further information on the Google SVN at the following link:
http://code.google.com/p/sandmanlib/.

* Actually, SandMan supports 32bits version of the hibernation file from Windows XP to Windows 2008 Server

To download SandMan, go to the section dedicaced to SandMan here:
http://sandman.msuiche.net/.

Download it from the following link:
Windows_Vista_32bits_and_unexported_kernel_symbols.pdf

Cheers,

I’m gonna published my (the?) first paper of the year 2007 !! :)

This article is talking about Windows Vista 64bits and its system structures which are proteged against rootkit. I also explain how these structures can be authentified without Pathguard.

Windows Vista 64bits and unexported kernel symbols.pdf

Happy New Year !!!

C:\Windows\System32\ntdll.dll
C:\Windows\System32\wow64.dll
C:\Windows\System32\wow64win.dll
C:\Windows\System32\wow64cpu.dll

You know, I’m a very curious person that’s why I decided to disassemble these dlls. But when I opened the C:\Windows\System32\ I didn’t see any wow*.dll files except a wow32.dll which is a PE32 file format. I didn’t get what was going on, then I asked a friend about this problem. He kindly redirected me toward a Mark Russinovich’s post about a Windows 64bits article where is saying :
However, I raninto a mechanism called folder redirection: when a 32-bit image accesses the \Windows\System32 directory theWow64 subsystem redirects it to \Windows\Syswow64 (think about that for a second: 64-bit binaries are in System32while 32-bit binaries are in Syswow64).
Ohh ! Merci Mark ! My issue was solved but I wanted to know from where the hell this redirection is from. So I disassembled all wow*.dll then I found out the following functions in the wow64.dll :

Wow64LdrpInitialize (where are referenced “%s\\syswow64\\ntdll.dll”)
Wow64pInitializeFilePathRedirection
RedirectObjectName

For people who are unfamiliar with x64 assembly please check that link : http://sandpile.org/aa64/reg.htm.
Plus, we can see a debugging dll called wow64log.dll and very interesting references for system path and registry path :

.text:0000000078C320D8 dq offset aSystem32_0 ; “\\system32″
[...]
.text:0000000078C320E8 dq offset aSyswow64 ; “\\SysWOW64″
[...]
.text:0000000078C320F8 dq offset aLastgoodSystem ; “\\lastgood\\system32″
[...]
.text:0000000078C32108 dq offset aLastgoodSyswow ; “\\lastgood\\SysWOW64″
[...]
.text:0000000078C32118 dq offset aRegedit_exe ; “\\regedit.exe”
[...]
.text:0000000078C32128 dq offset aSyswow64Regedi ; “\\SysWOW64\\regedit.exe”
[...]
.text:0000000078C32138 dq offset aKnowndlls ; “\\KnownDlls”
[...]
.text:0000000078C32148 dq offset aKnowndlls32 ; “\\KnownDlls32″
[...]
.text:0000000078C32158 dq offset aSysnative ; “\\sysnative”

We also have a kind of user-land SSDT, where the NtQueryDirectoryFile function is present.

.data:0000000078C66340 sdwhnt32JumpTable dq offset whNtMapUserPhysicalPagesScatter
.data:0000000078C66340 ; DATA XREF: .data:sdwhnt32
.data:0000000078C66348 dq offset whNtWaitForSingleObject
.data:0000000078C66350 dq offset whNtCallbackReturn
.data:0000000078C66358 dq offset whNtReadFile
[...]
.data:0000000078C664D0 dq offset whNtQueryDirectoryFile

I don’t really did a full analysing of the DLL. As you see it was more an on the fly analyse, just to get a possible idea about the way uses by WoW to identify the redirection scheme.