SandMan 1.0.080226 is out!

Since Windows 2000, Microsoft provides a feature called Hibernation also know as suspend to disk that aims to save the system state into an undocumented file called hiberfil.sys. This file contains all the physical memory saved by the Operating System and aims to be restored by the user the next time the computer is powered on. Live forensics analysis is used to use physical memory dump to recover information on the targeted machine. One of the main problems is to obtain a readable physical memory dump, hibernation is an efficient way to save and load physical memory. Hibernation analysis has notable advantages. System activity is totally frozen, therefore coherent data is acquired and no software tool is able to block the analysis. The system is left perfectly functional after analysis, with no side effects.

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.

1. #!/usr/bin/python
2. #
3. #
4. #Module Name:
5. #
6. #    sample1.py
7. #
8. #Abstract:
9. #
10. #    - Display target version.
11. #    - Build a physical memory dump from a hibernation file.
12. #
13. #Environment:
14. #
15. #    - Python
16. #
17. #Revision History:
18. #
19. #    - Matthieu Suiche
20. #
21.  
22. import sys
23. import sandman
24.  
25. if len(sys.argv) != 3:
26.   print "Matthieu Suiche – http://sandman.msuiche.net/"
27.   print "Usage: sample.py hiberfil.sys physical_dump.vmem"
28.   sys.exit(1)
29.  
30. s = sandman.hiber_open(sys.argv[1])
31.  
32. ver = sandman.hiber_get_version(s);
33.  
34. print "Windows version %d.%d.%d\n" % (ver & 0xFF, (ver & 0xFF00) >> 8, ver >> 16)
35.  
36. print "Generate physical memory dump…"
37.  
38. sandman.hiber_dump(s, sys.argv[2])
39.  
40. print "Done."
41.  
42. sandman.hiber_close(s)

* 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/.

Windows Vista and unexported kernel symbols (Part II, 32bits version)

This paper exposes part II of my previous article about Windows Vista and internals structures. This one is talking about the 32bits version and aims to show new authencity tricks.

Download it from the following link:
Windows_Vista_32bits_and_unexported_kernel_symbols.pdf

Cheers,

Windows Vista 64-bits and unexported kernel symbols.

Hi,

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 !!!

Vista’s WoW Path Redirection

Windows Vista x64, is my first 64bits Operating System before it I never had been interested about 32-64bits compabilities. It started when I used the Daniel Pistelli’s tool called “Explorer Suite”,which is available at the following link : http://ntcore.com/download.php, I noticed that Windows Live Messenger, which is a x86 binary, is just linked by four dlls :

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.