A script for dumping Linux memory and creating Volatility profiles

I have already written something about dump of volatile memory on Linux systems. Recently i have discovered this useful script developed by Hal Pomeranz, that automate all steps required to perform a memory analysis.

A lot of steps!

In order to perform a memory analysis on a Linux system, first need to be able to capture volatile memory, but you need to have a specific module compiled for the kernel of the system where you want to grab RAM.

After, in order to analyze the dump with Volatility, you need to create a profile that matches the system where the memory was captured: to make this, you need to compile a C program on the system and using dwarfdump to get the addresses of important kernel data structures.

This is not easy: there are a number of steps and some low-level Linux commands involved.

The “Linux Memory Grabber” script can automate all this steps.

ON FORENSIC PURITY
==================

If you're a stickler for forensic purity, this is probably not the
tool for you.  Let's discuss some of the ways in which my tool interacts
with the target system:

Removable Media -- The tool is designed to be run from a portable USB
  device such as a thumb drive.  You are going to be plugging a writable
  device into your target system, where it could potentially be targeted
  by malicious users or malware on the system.  The act of plugging the
  device into the system is going to change the state of the machine
  (e.g., create log entries, mtab entries, etc).  If the device is not
  auto-mounted by the operating system, the user must manually mount the
  device via a root shell.

Compilation -- lmg builds a LiME kernel module for the system.
  Creating a Volatility(TM) profile also involves compiling code on
  the target machine.  So gcc will be executed, header files read,
  libraries linked, etc.  lmg tries to minimize impact on the file
  system of the target machine by setting TMPDIR to a directory on
  the USB device lmg runs from.  This means that intermediate files
  created by the compiler will be written to the thumb drive rather
  than the local file system of the target machine.

Dependencies -- In order to compile kernel code on Linux, the target
  machine needs a working development environment with gcc, make, etc
  and all of the appropriate include files and shared libraries.
  And in particular, the kernel header files need to be present on
  the local machine.  These dependencies may not exist on the target.
  In this case, the user is faced with the choice of installing
  the appropriate dependencies (if possible) or being unable to
  acquire memory from the target.

Malware -- lmg uses /bin/bash, gcc, zip, and a host of other programs from
  the target machine.  If the system has been compromised, the applications
  lmg uses may not be trustworthy.  A more complete solution would be
  to create a secure execution environment for lmg on the portable USB
  device, but was beyond the scope of this initial proof of concept.

Memory -- All of the commands being run will cause the memory of the
  target system to change.  The act of capturing RAM will always create
  artifacts, but in this case there is extensive compilation, file system
  access, etc in addition to running a RAM dumper.

All of that being said, lmg is a very convenient tool for allowing
less-skilled agents to capture useful memory analysis data from
target systems.

Note that lmg will look for an already existing LiME module on the
USB device that matches the kernel version and processor architecture
of the target machine.  If found, lmg will not bother to recompile.
Similarly, you may choose to not have lmg create the Volatility(TM)
profile for the target in order to minimize the impact on the target system.

lmg uses relative path names when invoking programs like gcc and zip.
So if you wish to run these programs from alternate media, simply update
$PATH as appropriate before running lmg.

The usage is pretty simple:

When you wish to acquire RAM, plug the thumb drive into your target system. On most Linux systems, new USB devices will get automatically mounted under /media. Let’s assume yours ends up under /media/LMG.

Now, as root, run “/media/LMG/lmg”. This is interactive mode and the user will be prompted for confirmation before lmg builds a LiME module for the system and/or creates a Volatility(TM) profile. If you don’t want to be prompted, use “/media/LMG/lmg -y”.

Everything else is automated. After the script runs, you will have a new directory on the thumb drive named

“…/capture/-YYYY-MM-DD_hh.mm.ss"

lmg supports a -c option for specifying a case ID directory name to be used instead of the default “-YYYY-MM-DD_hh.mm.ss" directory.

Whatever directory name is used, the directory will contain:

-YYYY-MM-DD_hh.mm.ss-memory.lime -- the RAM capture  -YYYY-MM-DD_hh.mm.ss-profile.zip -- Volatility(TM) profile  -YYYY-MM-DD_hh.mm.ss-bash -- copy of target's /bin/bash  volatilityrc -- prototype Volatility config file The volatilityrc file defines the appropriate locations for the captured memory and plugin.

For more technical information, and installation instructions plese refer to github repository: