I had the following a question from Mr Anonymous about Matthieu Suiche's Sandman Shell Project:
“...the same happens with hibrshell. When I execute the command it crashes while "Retrieving Kernel Image base". I tried with 3 different hiberfil.sys files so I guess it's not the file. The bad thing is that I also tried with different pcs and it crashed too, this means that I have no idea of what it can be. Do I need any extra software? Has anyone the same problem?...”
I have had this problem too!!! I had the same errors because I didn't have the right Microsoft Symbols installed on my testing machine or I didn't define the environment variable _NT_SYMBOL_PATH everytime I opened a new command prompt to run Sandman Shell (ha.exe). So here is how to fix both problems.
First Make sure that you have the correct symbols installed on your test machine for the specific version of the Windows OS of the Hiberfil.sys you are testing. So if your Hiberfil.sys came from a Windows XP SP2 Machine make sure you have the Windows XP SP2 Symbols installed on your testing machine. Download symbols from Microsoft.
Second you have to make sure you define the path to the symbols everytime you open a command prompt. To help me I wrote the following two batch files:
__________________________________________
Batch File 1 Name: “CreateDD_HA.bat”
cmd /k _symbols_setup.bat
__________________________________
Batch File 2 Name: “_symbols_setup.bat”
set _NT_SYMBOL_PATH=SRV*C:\WINDOWS\Symbols*http://msdl.microsoft.com/download/symbols
echo %_NT_SYMBOL_PATH%
echo off
echo ****************************
echo ****************************
Echo FIRST
Echo To Obtain a DD Image of a Hiberfil.sys File...
Echo Type "ha.exe " and drag and drop your HiberFil.sys
Echo in the command lineto look like
Echo Example "ha.exe C:\dumpfiles\Hiber\hiberfil.sys"
echo off
echo ****************************
Echo Second
Echo Once you Hiberfil.sys file is loaded
Echo And you are at the Green Prompt just type
Echo Example "create output.dd"
__________________________________
Place the two batch files in the same directory as HA.exe
And run CreateDD_HA.bat.
If this doesn't help check with M Suiche. That guy is wicked smart and very helpful!
Rick
Thursday, April 16, 2009
Saturday, February 21, 2009
VMWare Running? Better Check for Different Windows Operating System's EPROCESS Blocks
Identify Multiple Windows OS Versions in a Single RAM Capture if the Host Machine is Running VMWare Machines.
I often run VMWare Machines, on my host machine,so I can easily grab the machine's RAM contents by suspending the machine and analyzing the VMEM file. Nothing new there. But what is cool is when you run several VMWare machines (or just one) and grab the RAM of the host machine. If you use other tools to determine which OS is running they will only identify what OS is running on the “Host” machine and not what OS(s) are being running on VMWare machines.
So to find out which different Windows OSs were running in your captured RAM use the following GREP search across your RAM acquisition
\x4E\x00\x54\x00\x20\x00\x4B\x00\x65\x00\x72\x00\x6E\x00\x65\x00\x6C\x00\x20\x00\x26\x00\x20\x00\x53\x00\x79\x00\x73\x00\x74\x00\x65\x00\x6D\x00\x00\x00\x00\x00[\x00-\xFF]\x00[\x00-\xFF]\x00\x01\x00\x46\x00\x69\x00\x6C\x00\x65\x00\x56\x00\x65\x00\x72\x00\x73\x00\x69\x00\x6F\x00\x6E\x00\x00\x00\x00\x00
The GREP expression loosely translates to,
“N.T. .K.e.r.n.e.l. .&. .S.y.s.t.e.m........... F.i.l.e.V.e.r.s.i.o.n.....”.
This is the same GREP Expression in the RAM Enscript I created. (In the enscript the” \” is “\\”). The GREP expression is the magic number needed to find the metadata contained in the NTOSKRNL.exe. The following bytes after this GREP is the Windows OS File Version Number The file version can then be converted to the Specific Windows OS. The following is an example from the RAM Acquistion with the HOST OS (WinXPSP2) and Two VMWARE Machines (Vista and Win200) ________________________________________
Comment Operating System: Windows XPSP2 Internal Version Number = 5.1.2
File Offset 7209948
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····r·)···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows Vista Internal Version Number = 6.0.6
File Offset 445911836
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····n·'···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows 2000 Internal Version Number = 5.00.
File Offset 712069132
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····8·····F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
During my testing I also shutdown the VMWare Machines for approximately 10 minutes and re-acquired the RAM. I still found the OS Metadata, of one of the Machines in the second RAM acquisition. Showing there is some persistence of VMWARE' Machine's RAM in the HOST Memory. (No additional programs were started by the user during the ten minute waiting period-except the RAM acquisition tool).
Once you have the different OSs inside your RAM you can also use the same RAM Enscript to find the running/exited processes (EPROCESS Blocks) of each OS along with the other remnants. The Second RAM Acquisition did not contain the OS Metadata for the Vista VM but I still found 20 unique Vista EPROCESS Blocks. I also found about 7 unique EPROCESS Blocks from he Win2000 VM. Showing a little persistence in the RAM
So yeah... this is cool in the lab... but not sure how often anyone will need this information in the “Real World”.
Thanks to Eric at Digital Intelligence for idea of checking for this...
I often run VMWare Machines, on my host machine,so I can easily grab the machine's RAM contents by suspending the machine and analyzing the VMEM file. Nothing new there. But what is cool is when you run several VMWare machines (or just one) and grab the RAM of the host machine. If you use other tools to determine which OS is running they will only identify what OS is running on the “Host” machine and not what OS(s) are being running on VMWare machines.
So to find out which different Windows OSs were running in your captured RAM use the following GREP search across your RAM acquisition
\x4E\x00\x54\x00\x20\x00\x4B\x00\x65\x00\x72\x00\x6E\x00\x65\x00\x6C\x00\x20\x00\x26\x00\x20\x00\x53\x00\x79\x00\x73\x00\x74\x00\x65\x00\x6D\x00\x00\x00\x00\x00[\x00-\xFF]\x00[\x00-\xFF]\x00\x01\x00\x46\x00\x69\x00\x6C\x00\x65\x00\x56\x00\x65\x00\x72\x00\x73\x00\x69\x00\x6F\x00\x6E\x00\x00\x00\x00\x00
The GREP expression loosely translates to,
“N.T. .K.e.r.n.e.l. .&. .S.y.s.t.e.m........... F.i.l.e.V.e.r.s.i.o.n.....”.
This is the same GREP Expression in the RAM Enscript I created. (In the enscript the” \” is “\\”). The GREP expression is the magic number needed to find the metadata contained in the NTOSKRNL.exe. The following bytes after this GREP is the Windows OS File Version Number The file version can then be converted to the Specific Windows OS. The following is an example from the RAM Acquistion with the HOST OS (WinXPSP2) and Two VMWARE Machines (Vista and Win200) ________________________________________
Comment Operating System: Windows XPSP2 Internal Version Number = 5.1.2
File Offset 7209948
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····r·)···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows Vista Internal Version Number = 6.0.6
File Offset 445911836
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····n·'···F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
Comment Operating System: Windows 2000 Internal Version Number = 5.00.
File Offset 712069132
N·T· ·K·e·r·n·e·l· ·&· ·S·y·s·t·e·m·····8·····F·i·l·e·V·e·r·s·i·o·n·····
________________________________________
During my testing I also shutdown the VMWare Machines for approximately 10 minutes and re-acquired the RAM. I still found the OS Metadata, of one of the Machines in the second RAM acquisition. Showing there is some persistence of VMWARE' Machine's RAM in the HOST Memory. (No additional programs were started by the user during the ten minute waiting period-except the RAM acquisition tool).
Once you have the different OSs inside your RAM you can also use the same RAM Enscript to find the running/exited processes (EPROCESS Blocks) of each OS along with the other remnants. The Second RAM Acquisition did not contain the OS Metadata for the Vista VM but I still found 20 unique Vista EPROCESS Blocks. I also found about 7 unique EPROCESS Blocks from he Win2000 VM. Showing a little persistence in the RAM
So yeah... this is cool in the lab... but not sure how often anyone will need this information in the “Real World”.
Thanks to Eric at Digital Intelligence for idea of checking for this...
Wednesday, January 28, 2009
Using Volatility (1.3_Beta), Volatility Plugin from Moyix, a test RAM Image (xp-laptop-2005-06-25.img) and a Windows Hash/Password Finder (SamInside or Cain and Abel) identify the passwords for the following users: Sarah, phoenix and the Administrator.
1. Run hivescan to get hive offsets
command: python volatility hivescan -f "C:\Dump\xp-laptop-2005-06-25.img"
Offset (hex)
42168328 0x2837008
42195808 0x283db60
47592824 0x2d63578
207677272 0xc60e758
207736840 0xc61d008
207759192 0xc622758
207822 ***** Truncated to save some space
2.Run hivelist with the first hivescan offset
command: python volatility hivelist -f "C:\Dump\xp-laptop-2005-06-25.img" -o 0x2837008
Address Name
0xe1ecd008 \Documents and Settings\Sarah\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1eff758 \Documents and Settings\Sarah\NTUSER.DAT
0xe1bf9008 \Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c26850 \Documents and Settings\LocalService\NTUSER.DAT
0xe1bf1b60 \Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c2a758 \Documents and Settings\NetworkService\NTUSER.DAT
0xe1982008 \WINDOWS\system32\config\software
0xe197f758 \WINDOWS\system32\config\default
0xe1986008 \WINDOWS\system32\config\SAM
0xe197a758 \WINDOWS\system32\config\SECURITY
0xe1558578 [no name]
0xe1035b60 \WINDOWS\system32\config\system
0xe102e008 [no name]
3. Find Password Hash (-y System Hive Offset)(-s SAM Hive Offset) and Send to Text File.
Command: volatility hashdump -f "C:\Dump\xp-laptop-2005-06-25.img" -y 0xe1035b60 -s 0xe1986008>Password_Hash.txt
Administrator:500:08f3a52bdd35f179c81667e9d738c5d9:ed88cccbc08d1c18bcded317112555f4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:ddd4c9c883a8ecb2078f88d729ba2e67:e78d693bc40f92a534197dc1d3a6d34f:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:8bfd47482583168a0ae5ab020e1186a9:::
phoenix:1003:07b8418e83fad948aad3b435b51404ee:53905140b80b6d8cbe1ab5953f7c1c51:::
ASPNET:1004:2b5f618079400df84f9346ce3e830467:aef73a8bb65a0f01d9470fadc55a411c:::
Sarah:1006:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
4.Import Password_Hash.txt into a Password Finder (SamInside, Cain and Abel...).
User: Sarah Password: Empty
User: phoenix Password: Neon96
User: Administrator Password: Neon1996
1. Run hivescan to get hive offsets
command: python volatility hivescan -f "C:\Dump\xp-laptop-2005-06-25.img"
Offset (hex)
42168328 0x2837008
42195808 0x283db60
47592824 0x2d63578
207677272 0xc60e758
207736840 0xc61d008
207759192 0xc622758
207822 ***** Truncated to save some space
2.Run hivelist with the first hivescan offset
command: python volatility hivelist -f "C:\Dump\xp-laptop-2005-06-25.img" -o 0x2837008
Address Name
0xe1ecd008 \Documents and Settings\Sarah\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1eff758 \Documents and Settings\Sarah\NTUSER.DAT
0xe1bf9008 \Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c26850 \Documents and Settings\LocalService\NTUSER.DAT
0xe1bf1b60 \Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1c2a758 \Documents and Settings\NetworkService\NTUSER.DAT
0xe1982008 \WINDOWS\system32\config\software
0xe197f758 \WINDOWS\system32\config\default
0xe1986008 \WINDOWS\system32\config\SAM
0xe197a758 \WINDOWS\system32\config\SECURITY
0xe1558578 [no name]
0xe1035b60 \WINDOWS\system32\config\system
0xe102e008 [no name]
3. Find Password Hash (-y System Hive Offset)(-s SAM Hive Offset) and Send to Text File.
Command: volatility hashdump -f "C:\Dump\xp-laptop-2005-06-25.img" -y 0xe1035b60 -s 0xe1986008>Password_Hash.txt
Administrator:500:08f3a52bdd35f179c81667e9d738c5d9:ed88cccbc08d1c18bcded317112555f4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:ddd4c9c883a8ecb2078f88d729ba2e67:e78d693bc40f92a534197dc1d3a6d34f:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:8bfd47482583168a0ae5ab020e1186a9:::
phoenix:1003:07b8418e83fad948aad3b435b51404ee:53905140b80b6d8cbe1ab5953f7c1c51:::
ASPNET:1004:2b5f618079400df84f9346ce3e830467:aef73a8bb65a0f01d9470fadc55a411c:::
Sarah:1006:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
4.Import Password_Hash.txt into a Password Finder (SamInside, Cain and Abel...).
User: Sarah Password: Empty
User: phoenix Password: Neon96
User: Administrator Password: Neon1996
Labels:
Moyix,
Passwords,
RAM Analysis,
Registry,
Volatility
Thursday, June 5, 2008
Winen.exe - RAM Imaging Tool Included in New Version of Encase
Today when I downloaded the latest version of Encase (6.11.0.43) I discovered winen.exe in the Encase Program Folder. Apparently winen.exe is the new RAM Acquisition Tool Provided by Guidance. Winen.exe is suppose to work on all variations of Windows higher then 2000.
A search of Guidance Support Portal and I was able to down Winen.pdf. (Guidance Forum Access Required - 3 pages).
The Winen Executable can run as a command line tool, user prompt or from a configuration file. You can run Winen.exe from a USB drive that you plug into the Target Machine. You do need Local Administrator Privilege (which can be difficult to get- sometimes!).
If you can run Winen.exe from a USB Drive and it will prompt you for the required information needed to create the image file.
If you set up a configuration (Config) file you can speed things up.
Setting Up a Configuration File.
I created the following Config File:

As you can see I really placed the name of the image(Evidence Name)in the Evidence Path. In the Evidence Name Path I also put in the Evidence Name. This is so when I run the program it will automatically save my image file to the USB Device I am running it from.
In my example I will create a RAM_ACQ.e01 file in the same directory as I have Winen.exe installed on.
Batch File
I then created a batch file with the following line:
winen -f winen.config
“winen” is the executable to run
“-f” is the option for a Config File
“winen.config” is the name of my Config File (Must be in same path as Winen.exe)
Run the Batch file from your USB and you will automatically save you image file to your USB Drive.
Final Tweak
You can also change the name of winen.exe to something benign sounding (e.g. “sys32.exe”) to make it more difficult to identify by your target.
Using your RAM Acquisition e01 File.
Once the RAM image is created you can get information out of it by Using my RAM Enscript.
You can also use PtfinderFE on the RAM Image but you have to strip the embedded e01 data from your image file. My favorite way is by opening the image up in FTK Imager and export the unallocated space out. You could do the same thing in Encase.
FootPrint
Winen.exe will use approximately 2.8 Mb of RAM which might also be found in the PageFile.
The following keys will be created or altered:
HKEY_LOCAL_MACHINE\SYSTEM\ \Enum\Root\ LEGACY_WINEN_
HKEY_LOCAL_MACHINE\SYSTEM\ \Services\ winen_
(Acording to the Winen.pdf)
Changes regarding adding a USB would also apply (e.g. USBStor in the Registry).
The batch file(cmd.exe) and Winen.exe (in the picture) as they appear in a PtfinderFE Graphic.
KntTools is still my RAM Acquisition tool of choice.
A search of Guidance Support Portal and I was able to down Winen.pdf. (Guidance Forum Access Required - 3 pages).
The Winen Executable can run as a command line tool, user prompt or from a configuration file. You can run Winen.exe from a USB drive that you plug into the Target Machine. You do need Local Administrator Privilege (which can be difficult to get- sometimes!).
If you can run Winen.exe from a USB Drive and it will prompt you for the required information needed to create the image file.
If you set up a configuration (Config) file you can speed things up.
Setting Up a Configuration File.
I created the following Config File:
As you can see I really placed the name of the image(Evidence Name)in the Evidence Path. In the Evidence Name Path I also put in the Evidence Name. This is so when I run the program it will automatically save my image file to the USB Device I am running it from.
In my example I will create a RAM_ACQ.e01 file in the same directory as I have Winen.exe installed on.
Batch File
I then created a batch file with the following line:
winen -f winen.config
“winen” is the executable to run
“-f” is the option for a Config File
“winen.config” is the name of my Config File (Must be in same path as Winen.exe)
Run the Batch file from your USB and you will automatically save you image file to your USB Drive.
Final Tweak
You can also change the name of winen.exe to something benign sounding (e.g. “sys32.exe”) to make it more difficult to identify by your target.
Using your RAM Acquisition e01 File.
Once the RAM image is created you can get information out of it by Using my RAM Enscript.
You can also use PtfinderFE on the RAM Image but you have to strip the embedded e01 data from your image file. My favorite way is by opening the image up in FTK Imager and export the unallocated space out. You could do the same thing in Encase.
Winen.exe will use approximately 2.8 Mb of RAM which might also be found in the PageFile.
The following keys will be created or altered:
HKEY_LOCAL_MACHINE\SYSTEM\
HKEY_LOCAL_MACHINE\SYSTEM\
(Acording to the Winen.pdf)
Changes regarding adding a USB would also apply (e.g. USBStor in the Registry).
The batch file(cmd.exe) and Winen.exe (in the picture) as they appear in a PtfinderFE Graphic.
KntTools is still my RAM Acquisition tool of choice.
Monday, May 19, 2008

I am presenting a two-day course on RAM Acquisition and RAM Analysis at Digital Intelligence. The course is June 10-12, 2008 and is FREE.
The following is a quick synopsis of the training:
RAM Analysis – Vista and Beyond
Everything run on a computer passes through the RAM at one time or another. The trick is being able to identify data found in a RAM capture and relate it back to the item that originally created it. This two day training session includes a very "hands-on" lab to train on different tools and using various methods for collecting RAM from a running machine.
For more Information.
Labels:
Digital Intelligence,
Enscript,
Guillotine,
RAM,
RAM Analysis,
Speaker
Saturday, May 3, 2008
BIOS Magic Numbers in RAM (Beta)
A colleague of mine approached me after teaching a class on finding information in RAM. He asked me to prove a particular RAM acquisition came form a particular machine. My first thought was to run to the remnants from the registry. But do to paging of the registry and many false positives this proved a little more difficult then I originally thought... But as you guessed by the title I then found the information from the machine’s BIOS.
1. Using Encase create the following GREP Expression:
\x00\x14\x00\x00\x01\x02..\x03
2. Run against the DFRWS Dump and review your findings:

The information contained in the BIOS is pretty substantial often including make, model and serial number of the computer the data was collected
So far the BIOS Magic Numbers have found the BIOS Information on every RAM Acquisition I have tested it on. (Win2000 to Vista).
Future Work:
1. Find the Length of the BIOS Information or a Good Footer.
2. Place in RAM Enscript
1. Using Encase create the following GREP Expression:
\x00\x14\x00\x00\x01\x02..\x03
2. Run against the DFRWS Dump and review your findings:
The information contained in the BIOS is pretty substantial often including make, model and serial number of the computer the data was collected
So far the BIOS Magic Numbers have found the BIOS Information on every RAM Acquisition I have tested it on. (Win2000 to Vista).
Future Work:
1. Find the Length of the BIOS Information or a Good Footer.
2. Place in RAM Enscript
Friday, May 2, 2008
RAM Enscript Version 1.0
RAM ENSCRIPT UPDATED!!! Download
The new RAM Enscript contains:
OS Identification
Processes (Exited / Running)
Registry Remnants (UserAssist)
MSHTML Remnants
MFT Parser.
Runs against RAM Dumps from Windows 2000 to Vista.
Many Thanks to the First RAM Analysis Advance Class at IACIS- Thanks for the Hard Work.
The new RAM Enscript contains:
OS Identification
Processes (Exited / Running)
Registry Remnants (UserAssist)
MSHTML Remnants
MFT Parser.
Runs against RAM Dumps from Windows 2000 to Vista.
Many Thanks to the First RAM Analysis Advance Class at IACIS- Thanks for the Hard Work.
Subscribe to:
Posts (Atom)
