Image for post
Image for post
The RIT Computing Security Lab

Updating RIT System Forensics’ Volatility Lab

In RIT’s Computer System Forensics class, students learn basic incident response procedures as well as methods to uncover and investigate the activities of computer users. Students also learn to employ activities needed to gather and preserve evidence to be presented in court cases. Some of the concepts discussed in class are incident response reporting, forensic imaging, Linux and Windows file systems and steganography.

While the class is well-designed and the concepts presented are highly applicable, assignments and labs can grow a bit stale because the two professors that regularly teach the class are actively involved in research. Such was the case for Spring 2019's memory acquisition and analysis lab, which instructs on how to use the Linux Memory Extractor (LiME) and the Volatility Framework to analyze memory images for system information and malware infections.

Image for post
Image for post
Computer System Forensics’ Lab 5 on the Volatility Framework

Issues with the lab

The memory acquisition lab is conducted on SANS’ SIFT Workstation, an Ubuntu virtual machine for digital forensic examinations. Provided as an Open Virtualization Format (.ova) file, the VM can be easily set up on a hypervisor in a few minutes. Importantly, it includes many common forensic tools pre-installed — including Volatility. Volatility does have many built-in profiles of various Linux distros that could be used, but this lab also aims to teach how to create such profiles. This is where the problems occur.

The original instructions

The instructions to create a Volatility profile were given as follows:

The steps to build Ubuntux64 profile on SIFT:1. Install dwarfdump package and kernel headers$sudo apt-get update$sudo apt-get install dwarfdump linux-headers-generic --fix-missing2. Download the Volatility repository from https://github.com/volatilityfoundation/volatilitycd into tools > linux folder of the downloaded repo$cd ~/Downloads/volatility-master/tools/linux3. Generate the module.dwarf file using make$make4. Find the System.map version$ls /boot5. Create the profile zip (sift.zip) and place it in volatility overlays/linux folder where volatility looks for all profiles, given the System.map file's (from step 4) for the kernel version.$sudo zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/Ubuntu.zip module.dwarf /boot/System.map-4.4.0-31-generic6. Run vol.py --info | grep Profile to make sure the profile "LinuxUbuntux64" is in the profiles list.7. Run vol.py -f ‘/home/sansforensics/Desktop/ yourusername_memory_dump.bin’ --profile=LinuxUbuntux64 VolatilityLinuxCommand (Note: replace VolatilityLinuxCommand with the volatility Linux commands from https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference)

When my section began this lab, we were cautioned by our professor and via the lab instructions that creating a valid Volatility profile for memory analysis can be difficult and yield inconsistent results. This isn’t the way it should be — Volatility profiles should be simple to generate consistently and validly. In addition, by following the lab instructions as-is, running Volatility commands often resulted in Python errors or an output of random characters.

Image for post
Image for post
Getting the CPU information from a memory image with the previous lab instructions

Indeed, class averages for Lab 5 were at least 10% lower than for each other lab completed last semester. While speaking to other students, I found that this was because they were unable to create a valid Volatility profile to provide the deliverable. Many assignments were turned in with this section of the lab incomplete.

Image for post
Image for post
Class averages per lab. Note the drop in score on Lab 5.

After realizing the problems with running Volatility, I sought to identify the errors and produce an updated version of the lab with corrected instructions.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
My friends and I discussing problems with the lab

Making Volatility run properly

I spent some time researching the lab instructions and identified several problems. Many of the issues were due to differences with the provided version of Volatility in SIFT not containing the prerequisites to build Volatility profiles, so additional instructions were provided on how to clone and compile Volatility from GitHub as well. I was able to correct the problems and provide a new version of the lab.

Missing dependencies

I first checked the recommended dependencies listed on the Volatility project page and compared them against the lab instructions. There were many discrepancies. These are the packages that the lab instructions state to install:

1. Install dwarfdump package and kernel headers$sudo apt-get update$sudo apt-get install dwarfdump linux-headers-generic --fix-missing

Volatility operates much more reliably with the recommended packages installed. Some (such as linux-headers, build-essential, python-dev, and python-pip) are already installed in SIFT. In addition, -y can be added so that a confirmation isn’t needed when installing the packages. These are the correct instructions:

1. Install dwarfdump package and kernel headers$sudo apt-get update$sudo apt-get install dwarfdump pcregrep libpcre++-dev yara -y$sudo -H pip install pycrypto Distorm3 OpenPyxl ujson pillow

Using old kernel versions

The lab instructions include a hardcoded kernel version (System.map-4.4.0-31-generic) in the command when building the profile. Some students failed to change this version.

4. Find the System.map version$ls /boot5. Create the profile zip (sift.zip) and place it in volatility overlays/linux folder where volatility looks for all profiles, given the System.map file's (from step 4) for the kernel version.$sudo zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/Ubuntu.zip module.dwarf /boot/System.map-4.4.0-31-generic

In addition, since there could be many different kernel header file versions to choose from in /boot, the more reliable method would be to build the profile with $(uname -r) specified in place of the kernel version in the map file, to pick the correct version currently in use by the operating system. Step 4 (and the likelihood of manually picking an incorrect kernel version) can now be completely eliminated. The file name in the description also isn’t the same as the command, so that can be updated.

4. Create the profile zip (Ubuntu.zip) and place it in volatility overlays/linux folder where volatility looks for all profiles, given the System.map file's for the kernel version.$sudo zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/Ubuntu.zip module.dwarf /boot/System.map-$(uname -r)

Command syntax

The command to run Volatility uses a strange version of the backtick () instead of the quotation mark (). Using a backtick to specify a path isn’t supported. There is also a space between Desktop/ and yourusername_memory_dump.bin which is most likely inadvertent, but makes the path incorrect.

7. Run vol.py -f ‘/home/sansforensics/Desktop/ yourusername_memory_dump.bin’ --profile=LinuxUbuntux64 VolatilityLinuxCommand (Note: replace  VolatilityLinuxCommand with the volatility Linux commands from https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference)

Both of these issues are easily fixed.

6. Run vol.py -f '/home/sansforensics/Desktop/yourusername_memory_dump.bin' --profile=LinuxUbuntux64 VolatilityLinuxCommand (Note: replace  VolatilityLinuxCommand with the volatility Linux commands from https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference)

Running Volatility

Image for post
Image for post
Getting the CPU information from a memory image with the corrected lab instructions

Volatility now runs successfully across multiple systems and kernel versions. Modules previously requiring specific packages and the current kernel version now run properly. Here are the corrected lab instructions:

1. Install dwarfdump package and kernel headers$sudo apt-get update$sudo apt-get install dwarfdump pcregrep libpcre++-dev yara -y$sudo -H pip install pycrypto distorm3 openpyxl ujson pillow2. Download volatility repo:$cd ~/Downloads$git clone https://github.com/volatilityfoundation/volatility.git$cd volatility/tools/linux3. Generate the module.dwarf file using make$make4. Create the profile zip (sift.zip) and place it in volatility overlays/linux folder where volatility looks for all profiles, given the System.map file's for the kernel version.$sudo zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/Ubuntu.zip module.dwarf /boot/System.map-$(uname -r)5. Run vol.py --info | grep Profile to make sure the profile "LinuxUbuntux64" is in the profiles list.6. Run vol.py -f /home/sansforensics/Desktop/yourusername_memory_dump.bin --profile=LinuxUbuntux64 VolatilityLinuxCommand (Note: replace  VolatilityLinuxCommand with the volatility Linux commands from https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference)

I’ve found the Volatility framework very interesting to work with since being introduced to it in this lab, having used it and many plugins in a few personal projects and CTFs to date. I felt that improving the lab instructions would be helpful to my professors and also make this handy program less complex for students taking the class. The new lab will be in use next semester!

Written by

DFIR, CTFs, disinformation, STEM education, and pretty much anything else that comes to mind. RIT Computing Security ’22. wyatttauber.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store