Monthly Archives: August 2008

Sandman shell. Your hibernation file in a nutshell. – Part I

I’d like to introduce a new tool I plan to release later. This tool aims at providing a local shell to explore the windows hibernation file like windbg, or livekd can do with crash dump using SandMan framework.

The most interesting point regarding the usage is the loading of Microsoft Debugging Symbols to retrieve critical structure like EPROCESS, ETHREAD on every target file version — and also unexported functions and variables offset. Moreover, Symbols are downloaded automatically if they aren’t found on the local host.
Another interesting point is: we behave like if we were the kernel or a kernel debugger like Windbg, then we can retrieve a lot of information. Only a little bit of them are actually implemented!

For instance, this mean we can list process from a Windows XP hibernation file, as well as from a Windows 2008 hibernation file. And also print additional information regarding critical system tables like Interrupt Descriptor Table (IDT), or System Service Dispatch Table (SSDT) which can be use to detect anormal modification from third-part drivers like a Rootkits.

We can also imagine a new way to unpack executables like malwares.

Here are some screenshots of the current commands.

Of course, you can still generate a raw dump from the shell to make an interoable dump with existing framework like volatility.

I plan to integrate my disassembling library to detect anormal patching, or give a quick view of a process stack to detect if a shellcode is present or not. And I’d also like to extend it to Microsoft Crash dump files generated by a more advanced version of win32dd :-).

If you want to become a beta tester, or if you know a pretty single girl to introduce to me feel free to mail me at: matt (pouet)

Random notes:

Black Hat USA 2008 – Slides and Demos.

As I said in my previous post, this year I gave a talk at BH USA. For people who attended (or not) to my talk you can here find my presentation [PDF, PPTX], demos [ZIP], new version of SandMan version 1.1.20080804 [ZIP]! (black hat release).

   * Offensive
      - Bypassing Windows Login Prompt
         + msvp.c
      - Local privilege escalation
         + lpe.c
   * Defensive
      - Hibernation 2 Memory dump
         + hib2mem.c
         + hib2mem.exe
      - Kernel Analyze
         + kernelanalyze.exe Kernel Analyze is a tool I wrote to dump main kernel table and information including: IDT,GDT,IAT,EAT,HAL Dispatch Table, HAL Private Dispatch Table, SSDT and Symbols GUID FROM Windows hibernation file.

   - 2008-04-08
   1.1.20080804: Xpress algorithm reimplemented, including compression and decompression.

If you have any questions feel free to ask me at matt (at) [this domain name].net

SMM Rootkit limitations. (and how to defeat it :-))

Today (I mean meanwhile :-)) at Blackhat US 2008, Shawn Embleton and Sherri Sparks presented their research concerning the CleanHatConsulting SMM Rootkit.

* The first and main limitation concerns the D_LCK bit. BIOS Vendors enables this bit for some years (maybe like 2/3 years), few times after Loic Duflot first lecture. It means that “new computers” are not vulnerable to this. This limitation has been highlighted by Sherri during her talk. BTW, this limitated had previously been highlighted by a friend.

* The second point I’m going to talk about is how to defeat SMM Rootkit without any external tools or any programming/hardware knowledge.

The main notable point regarding SMM rootkit is the SMRAM can only be accessed if D_LCK is set to 0. But after having infecting the SMRAM the Rootkit, if D_LCK is previously equal to 0, SMM Rootkit locks the SMRAM by setting D_LCK bit to 1 to empeach access to it including from the Kernel.
Then, Windows Kernel cannot access it. Yeah and?
This mean if you hibernate the infected system the saved hibernation file with contains a clean memory snapshot because the infected SMRAM is not copied. REMEMBER! We cannot access it if D_LCK is equal to 1!
When, the computer will boot again (REMEMBER: Hardware reset is the only way to clear the SMRAM, include SMRAMC control register which contains the D_LCK bit), BIOS will rewrite the SMRAM during its initialization. Moreover, while the Windows OS Boot loader will be executed it will read the saved hibernation file wich DO NOT contains the infected SMRAM and the system will resume normaly. Your system is now virgin!

BTW, if you are at Blackhat. I’m giving a talk entitled “Windows hibernation file for fun and profit” tomorrow! Hopin’ to see you!