Volatility 1.4

This is just an initial post about the beta availability of Volatility 1.4. I've been teaching 1.3 as part of my Advanced Live Forensics course for 18 months or so but it only supports XP SP2 and 3 RAM images. The new 1.4 version from the devs and helpers at www.volatilesystems.com have been toiling over this version for somewhile and its great to at last have a play with it.

First things first you can find proper 'how to' resources at http://code.google.com/p/volatility/ but downloads are currently limited to within svn. If this is new to you its easy enough. If you are using a Mac with Snow Leopard just open a terminal and type 'svn checkout http://volatility.googlecode.com/svn/branches/Volatility-1.4_rc1'. This will download the 1.4 version and put the Volatility files in your user root folder.

Once downloaded just 'cd Volatility-1.4_rc1'. Anyone used to the old version will see a small difference in the running of the commands. Instead of-

python volatility pslist -f [pathtoRAM]

..you have quite a different syntax. It breaks down like this-

python vol.py [plugin] --profile=[PROFILE] -f [image]

vol.py replaces the old volatility framework command
plugin is the command such as pslist, psscan2 etc
profile is completely new but a vital component of the new framework. For all RAM images except from Windows XPSP2 x86 should have the profile defined at the --profile switch. The BasicUsage document lists them as:-

PROFILES
--------
VistaSP0x86 - A Profile for Windows Vista SP0 x86
VistaSP1x86 - A Profile for Windows Vista SP1 x86
VistaSP2x86 - A Profile for Windows Vista SP2 x86
Win2K8SP1x86 - A Profile for Windows 2008 SP1 x86
Win2K8SP2x86 - A Profile for Windows 2008 SP2 x86
Win7SP0x86 - A Profile for Windows 7 SP0 x86
WinXPSP2x86 - A Profile for Windows XP SP2
WinXPSP3x86 - A Profile for windows XP SP3

So running a basic pslist against myram.dd imaged from a Windows SP3 box would look like this-

python vol.py pslist --profile WinXPSP3x86 -f myram.dd

In the previous version outputing the results to a file could be achieved by using '>' or '>>' to output to a text file etc such as -

python volatility pslist -f myram.dd >> pslist.txt

However, in 1.4 we have many more options, by adding -

--output= you can specify numerous output types if the module being invoked supports it. This includes -

--output=text
--output=html
--output=csv

To check what a module/plugin supports just check help - python vol.py pslist --h and look for the output section.

You can add -

--output-file=myoutputfile.csv to name your output file. So our previous command line could look like this -

python vol.py pslist --profile WinXPSP3x86 -f myram.dd --output=text --output-file=myfile.txt

That should get you started.

There are also some exciting new modules to play with such as bioskbd a plugin based on Andreas Schusters work. It enables the reading of input text from the BIOS area of memory which can include the BIOS password or even Full Disk Encryption passwords. Check out the link to Andreas site for more information. This plug in has apparently been around for a while but I'd completely missed it. If you do check it out take note that some RAM dumping tools dont image that area of RAM. For example if you are using Matthieu Suiches win32dd tool you need to add '-t 1' to grab page zero.

Also there are some exciting malware analysis plugins such as svcscan which can list Windows services from both usermode and kernelmode and also ldrmodules for detecting unlinked DLL's.

Anyway, thats all for now, I'll try and post more in due course once I've had a proper play.

Nick

Mac Ram Dumps

Well its finally happened, at last a tool to dump RAM from OSX. Big thanks to ATC-NY for their Mac Memory Reader which can be downloaded for free here.

The tool is very easy to use, simply unpack and open a terminal.

cd to the folder MacMemoryReader (For newbies something like - cd /Users/name/Desktop/MacMemoryReader

Run - sudo ./MacMemoryReader filename

..where the 'filename' is the path to a connected storage device

You will prompted for your admin password and off it will go.

Remember to check that your connected storage has enough space for the entire RAM dump.

If you want to feel part of the action you can throw a -g into the command line and it will provide a percentage notifier.

The program outputs a Mach-0 raw file which should respond well to data carvers and the like. Well I've only conducted a couple of tests but Photorec and Foremost do a cracking job of getting at the files. They both successfully retrieved HTML, jpg, zips and a whole variety of other files including web pages going back 3 months. My 8 Gig of Ram offered up over 38000 files. Many of them were fairly uninteresting txt files so you need to wade through to find the good stuff.

If you are trying Foremost just bear in mind the 3Gig limit, perhaps take a look at Scalpel.

The next step is to start looking for running process information, fairly critical in basic RAM analysis. I'm away teaching next week so will have some evening time to play.

I'll try and blog again soon

OSX RAM Acquisition

Acquisition of OS X RAM is a bit of a holy grail of memory analysis, quite simply because no-one has done it, or has admitted to it. It is always good form to realize that whatever we think of as secure has probably been undermined by Dark Forces working from bunkers under grassy fields, or desert, or tundra depending on your Government Agency of choice.

In Leopard there were some significant weaknesses in OS X RAM, well researched and documented by Dai Zovi (We're not worthy!) who demonstrated in 2009 a number of different attacks on the OS through the poorly implemented memory stack which enabled heap allocated memory to be executable, unlike Vista/7 etc - Windows more secure - who knew!!

Snow Leopard with its 64bit architecture has gone a long way to solve that. But with the incredible amount of information available from a Windows RAM dump it would be great to achieve the same from a Mac. Work has been done with DMA (Direct Memory Access) via Firewire which can theoretically work and some researchers had some success with Leopard but its all gone quiet with Snow Leopard. So where does that leave us?

Well, unless you are prepared to freeze the chips you need to acquire the RAM whilst the machine is live. On a Linux machine you can simply dd /dev/mem and /dev/kmem but no such luck with OS X.

For the time being our best bet is the OS X counterpart of hiberfil.sys. In Windows hiberfil is a file generated in the root of C when the PC is put into hibernate state. The resulting file can be converted into a raw RAM dump using either tools from Matthieu Suiche with the Sandman project or the version produced for Volatility. OS X has a similar file called sleepimage. You can see if your Mac has one at the moment by doing the following:-

Open terminal
Type - cd /var/vm
Type - ls

If your machine has been hibernated you should see a sleepimage file with a file size that is the same as your RAM.

If you come up against a running Mac and will be seizing it then it is possible to force the machine to create the sleepimage file.

Suggested 'Forensic' methodology:-

Open Terminal
Type - sudo pmset –a hibernatemode 1

When you shut the lid it now creates a hibernate file and shuts machine down rather than putting it into sleep mode. The problem is that it will likely ask for the admin password. You could run MacLockpick which will extract the Keychain and possibly give you the password you need.

Next, you need to set it back - sudo pmset –a hibernatemode 3

Shut the lid, take the machine.

Now simply image the drive as normal and extract the sleepimage file and analyze.

If you were doing a live data acquisition or search of the machine it is simply the case of plugging in a USB drive and typing:-

sudo cp /var/vm/sleepimage /Volumes/USBkey (Where USBKey is the name of your drive.)

Now the problems:-

Changing the hibernatemode makes a technical change to the machine.
The technique forces you to shut the machine down which is no good if you want the RAM live whilst leaving the machine running.
There are currently no tools available for the analysis of the sleepimage. The tools we use for Windows RAM analysis such as Volatility, Foremost, Memoryze etc do not work. Get coding!

This post is not desperately useful as it just explains how to get a pseudo-Ram dump out, what you then do with it is up to you. If you figure anything out I'd love to hear about it!

Skype Chat Carver from RAM - Skypeex

Well I was going to keep testing but it just seems to keep working, so here it is in version 0.5.

Download

I’ve been teaching my RAM analysis course for about a year now and enjoy working with Volatility and some other open source tools. I’ve been making use of Jeff Bryners cool little Python script (http://www.jeffbryner.com/code/pdgmail) to extract Gmail artifacts and was motivated to do the same for Skype chat and any other Skype stuff that might be hanging around in a RAM dump.

The only problem was that, although I’ve done a bit of programming in the past, Python was a long hissy thing you wouldn’t want to meet on a dark night. Having gone through the pain of programming ‘Hello, world’, simple Pokemon text games for my lad and tedious maths exercises, I’ve actually managed to produce something meaningful.

The idea is to extract Skype chat lines with their associated meta-data, which includes timestamps, the Skype names in the conversation and the author etc.

The complete Skype line in RAM starts with the magic value ‘INTO Messages” followed by column headers then the values of the chat line including the chat body.

This is very much work in progress but will simply do the following:-

1. Run Strings against your RAM dump
2. Run the Skypeex tool against the resulting Strings file
3. It will carve out all the Skype chat lines it can see as well as trying to find and extract all the Skype sessions and ‘orphan’ chats that have been created.

It’s interesting to note that the latter process even seems to find the ‘spam’ message sessions that you sometimes receive.

This has been tested on dump files from Windows XP2 and XP3 with Skype 3.8 through 4.2.
I don't currently have a Windows 7 box up and running, if anyone has one available please let me know.

Please do not hesitate to get in touch with ideas and improvements.

Usage:

There are 2 versions in the zip file.

skypeex.py is designed for use under Python 3.1.1 and above

skypeex26 is designed for use under Python 2.6

Due to changes with several commands between 2.6 and 3 they are not interchangeable, although the differences in this code are only in the input and print lines.
For best testing results, have several Skype IM chats with friends and then image your RAM. On a windows box, use any tool to grab RAM (tested on Win XP SP2/3):

I recommend Win32dd (or Win64dd) from Matthieu Suiche - http://windd.msuiche.net/

Run strings against the RAM image (e.g. Windows version can be found in Helix distro)
example: strings c:\ramdump.dd > c:\stringsout.txt

On linux box do:
strings ramdump.dd > stringsout.txt

Script usage -
from command shell - python skypeex.py - then, when prompted, simply provide the path to the strings output file.

The output files will be written to the folder where the script is run from. The output is a CSV file with chats (incl headers) and a txt file with extracted skype sessions and carved orphan chats. Please expect many duplicates and some false positives.

In the CSV file the 'Timestamp' column is the date and time of the message in UNIX time. Sorting on this column gives you a timeline of messages. I'm writing a UNIX time decoder but it doesn't work yet.

The primary message content is in the 'body_xml' column.

Code:

The key elements of the code are:-

if "INTO Messages" in line:
def extract(text, sub1):
return text.split(sub1)[-1]
str2 = extract(line, 'VALUES (')

This searches for the magic value, strips out the rubbish and returns the comma delimited values we are interested in. This includes:-

Chatname – the initiator and recipient of the session
Timestamp – The time and data the message was sent in UNIX time
Author – the sender of the message
From_dispname – the screen name being used by the sender
Body_xml – the body of the message, can slip into the chat_msg column
GUID – session identifier

Next:

if "#" and "/$" in line:
outfile.write(line)
nxt = next(data)
outfile.write(nxt)

This time we look for the existence of the # and /$ characters in the same line. This refers to the pattern written to RAM of each Skype session, which looks like this:

#nfurneaux/$bennyboy1982;810b0fd9ef04db08

This shows the 2 persons in the Skype session with the first name being the initiator of the conversation. I’m still trying to figure out the hex value at the end, but it seems to be a GUID session number, any ideas let me know.

Sometimes we recover session line like the following:

#bennyboy/$nfurneaux;9fa7c85b71354392Jd1bbennyboy1982Ben Brown
#andyw/$nfurneaux;9fa7c85b71354392Jd1TnfurneauxNick Furneaux

We are able to see the actual Skype name as well as the screen name being used during the session. The cool thing is that we also grab the next line with often includes actual chat associated with the recovered session. Hence we capture:-

#bennyboy/$nfurneaux;8f915423c984767aJ[VonfurneauxNick Furneaux
ok quite close
# bennyboy /$nfurneaux;8f915423c984767aJ[bennyboy Ben Brown
Aug 23
# bennyboy /$nfurneaux;8f915423c984767aJ[VQnfurneauxNick Furneaux
when are you presenting at HTCIA
# bennyboy /$nfurneaux;8f915423c984767aJ[bennyboy Ben Brown

Interestingly this conversation is carved in reverse. We can ascertain that bennyboy started the conversation but see the sender in the second part of the session line, followed by the chat.

I've never released a tool to the community before so be kind! Let me know how you get on.
Nick Furneaux

Download