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.")

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.

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.

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.