Studying memory with the Volatility memory dump analyzer

Volatile Traces

© Lead Image © spleen87, photocase.com

© Lead Image © spleen87, photocase.com

Article from Issue 157/2013
Author(s): , Author(s):

The Volatility forensic tool helps admins analyze what went wrong on a system. When you need to draw conclusions about malware, or even compromised services, peer into memory with Volatility.

The fact that information remains in the memory of a computer for some time, even after disconnecting the power supply, is an open secret [1]. This is especially true if you press the reset button, because that does not even interrupt the power supply. If you then reboot from a minimal operating system – using a USB stick, for example – you can dump large parts of the memory without any changes, almost as if you had full access to the previously running system.

You could dig a few things out of this memory dump with on-board Linux tools like strings and grep, but a full-blown memory dump analyzer such as Volatility [2] gives you much more  – and the open source project is still expanding.

When we first looked at the Volatility memory analyzer in 2008, the framework could only analyze RAM images from Windows machines [3]. Now, version 2.2 or later is also available for Linux, and the upcoming 2.3 will handle Mac OS computers and Android devices. Linux admins can look forward to a large number of new tools and programs that can extract much information from a supposedly dead machine.

Volatility primarily proves useful for users who want to find out what a computer has been up to – for example, if the hard drive has died or if a cunning hacker has left no trace on the disk but possibly on the running system.

Practicing for the Real Thing

Tools such as LiME [4] can help you grab an image from a running system before rebooting or shutting down potentially removes all the evidence. For admins who want to learn how to use Volatility, the project members have posted a large number of memory dumps [5] for training purposes; if you prefer to create your own image, you can do so with a USB stick.

To follow the steps described in this article, you need only three things: an installation of a recent version of Volatility, a downloaded sample dump, and a Linux kernel to match its profile. The examples in this article refer to Ubuntu 13.04 (the 64-bit version). If you want to investigate an existing system, you need to create your own individual dump using a tool such as LiME.

Creating Memory Dumps

You can easily generate a memory dump for the Windows operating system. Products such as the Helix CD [6] typically are used for this purpose; they include a variety of programs. However, creating a memory dump on Linux is much more complex: For each kernel version, you need to create a suitable driver – for example, on an identical, virtualized system.

Volatility recommends LiME (available as a .tgz file) [7], and this tool collection worked well in our tests. To begin, you need to create a new folder and extract the lime-forensics-1.1-r17.tar.gz file into it. After calling make, you will find the lime-3.2.0-49-generic.ko module in the folder. You can identify the matching kernel version by the filename.

The driver is loaded by insmod so that the following command creates a memory dump in /tmp/ubuntu1204.dump:

insmod lime-3.2.0-49-generic.ko "path=/tmp/ubuntu1204.dump format=lime"

If you have already installed Volatility, you can now check the dump:

vol.py -f ubuntu1204.dump --profile=LinuxUbuntu1204_3_2_0_49x64 linux_ifconfig

In this example, the user relies on one of the Volatility commands described later in this article; here, linux_ifconfig was used to list the IPs and NICs last used. The result should contain lines like the following:

Interface IP MAC Promiscuous Mode
lo 127.0.0.1 00:00:00:00:00:00 False
eth0 192.168.2.2 00:00:00:00:00:00 False
sit0 0.0.0.0 00:00:00:00:00:00 Falseme"

Error messages such as No suitable address space mapping found or errors on trying to open the image indicate a defective image or an incorrect profile file. You can also check out some of the alternatives that are available for Linux. (See the box titled "Fmem, Coldboot, and Msramdump.")

Fmem, Cold Boot, and Msramdump

Fmem [8] replaces the typical method of creating memory dumps on kernel 2.4 using dd and /dev/mem or /dev/kmem. However, LiME ensures optimum cooperation with Volatility.

Another very interesting alternative is a cold boot attack, described by scientists at Princeton University [1]. The McGrew Security RAM Dumper (Msramdump) [9] uses the properties mentioned in the form of a bootable USB stick. It contains a FAT16 partition, which uses Syslinux to boot and automatically retrieves a memory dump. However, the stick needs to be sufficiently large, because the Msramdump tool writes the RAM image to a second partition on the stick by default.

Installing Volatility

Because Volatility is officially still beta, you need to pick up the source code from Subversion. The following command

svn checkout http://volatility.googlecode.com/svn/trunk Volatility

installs the framework from the source code repository. At this stage, you can install additional plugins; for details, see "Full Installation" on the project website  [10] .

For a first test, run ./vol.py -h. The message should confirm that you have the current version 2.3 beta:

Volatile Systems Volatility Framework2.3_beta

Using ./vol.py --info provides a lot of information, and it makes sense to reduce this with grep commands (Listing 1). The vol.py --info | grep Win command provides information about Windows support, which the developers have also greatly expanded since 2008.

Listing 1

vol.py --info | grep Win

Volatile Systems Volatility Framework 2.3_beta
VistaSP0x64                 - A Profile for Windows Vista SP0 x64
VistaSP0x86                 - A Profile for Windows Vista SP0 x86
VistaSP1x64                 - A Profile for Windows Vista SP1 x64
VistaSP1x86                 - A Profile for Windows Vista SP1 x86
VistaSP2x64                 - A Profile for Windows Vista SP2 x64
VistaSP2x86                 - A Profile for Windows Vista SP2 x86
Win2003SP0x86               - A Profile for Windows 2003 SP0 x86
Win2003SP1x64               - A Profile for Windows 2003 SP1 x64
Win2003SP1x86               - A Profile for Windows 2003 SP1 x86
Win2003SP2x64               - A Profile for Windows 2003 SP2 x64
Win2003SP2x86               - A Profile for Windows 2003 SP2 x86
Win2008R2SP0x64             - A Profile for Windows 2008 R2 SP0 x64
Win2008R2SP1x64             - A Profile for Windows 2008 R2 SP1 x64
Win2008SP1x64               - A Profile for Windows 2008 SP1 x64
Win2008SP1x86               - A Profile for Windows 2008 SP1 x86
Win2008SP2x64               - A Profile for Windows 2008 SP2 x64
Win2008SP2x86               - A Profile for Windows 2008 SP2 x86
Win7SP0x64                  - A Profile for Windows 7 SP0 x64
Win7SP0x86                  - A Profile for Windows 7 SP0 x86
Win7SP1x64                  - A Profile for Windows 7 SP1 x64
Win7SP1x86                  - A Profile for Windows 7 SP1 x86
WinXPSP1x64                 - A Profile for Windows XP SP1 x64
WinXPSP2x64                 - A Profile for Windows XP SP2 x64
WinXPSP2x86                 - A Profile for Windows XP SP2 x86
WinXPSP3x86                 - A Profile for Windows XP SP3 x86
WindowsCrashDumpSpace32     - This AS supports windows Crash Dump format
WindowsCrashDumpSpace64     - This AS supports windows Crash Dump format
WindowsHiberFileSpace32     - This is a hibernate address space for windows hibernation files.

Although Listing 2 shows the Linux modules, users trying to follow these examples are in for a bitter disappointment: Most of the information provided is not very helpful. Volatility offers a wide variety of Windows profiles, but these kinds of profiles are completely missing for Linux, so users need to create them.

Listing 2

vol.py --info | grep Linux

Volatile Systems Volatility Framework 2.3_beta
LinuxDebian5_26x86          - A Profile for Linux Debian5_26 x86
LinuxEvo4GARM               - A Profile for Linux Evo4G ARM
LinuxUbuntu1204_3_2_0_23x64 - A Profile for Linux Ubuntu1204_3_2_0_23 x64
LinuxUbuntu1204_3_2_0_32x64 - A Profile for Linux Ubuntu1204_3_2_0_32 x64
LinuxUbuntu1204x64          - A Profile for Linux Ubuntu1204 x64
LinuxUbuntu1304_3_8_0_25x64 - A Profile for Linux Ubuntu1304_3_8_0_25 x64
Linuxdfrws-profilex86       - A Profile for Linux dfrws-profile x86
linux_yarascan              - A shell in the Linux memory image

Although this process is not rocket science, you should remember that a profile will only work for a single kernel version or architecture. Even the distribution plays a role: A profile of Debian with kernel 3.2.x does not match a 3.2.x kernel on Ubuntu.

When this article went to press, Ubuntu 12.04 had already delivered 24 LTS kernels. Linux versatility sometimes has its disadvantages, and this clearly illustrates why professional Volatility users maintain a large number of virtual systems with a large number of kernels to have a profile ready quickly when the need arises.

If you have a memory dump but do not know the appropriate kernel version, a strings command against the dump with a grep for the vmlinuz string will uncover the secret. You can quickly find the appropriate kernel version and then create the profile on a virtual system.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Memory Analysis

    In computer forensics, memory analysis is becoming increasingly important as a means for investigating security incidents. In this article, we provide an overview of the various memory dumping options on Linux and introduce the support in Linux for the Volatility Analysis Framework.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95

News