1. Overview
Memory forensics plays a crucial role in digital investigations and incident response. It involves the collection and analysis of memory image dump to gain insights into system activities, identify malicious processes, and recover valuable artifacts.
In this tutorial, we’ll explore how to dump a memory image from a Linux system, enabling investigators to examine and extract vital information for forensic analysis.
2. Process of Memory Dumping
The process to dump memory image involves capturing and creating a snapshot of the volatile memory (RAM) of a computer system.
The steps typically include preparing the environment by using a dedicated forensic workstation, enabling write protection mechanisms, and obtaining the necessary tools like LiME (Linux Memory Extractor).
Let’s take a detailed look at these steps.
2.1. Preparing the Environment
Before proceeding with the process to dump a memory image, it’s essential to create a stable and controlled environment to ensure the integrity of the investigation.
We can perform memory analysis on a separate system or a forensic workstation dedicated solely to this purpose. We have to ensure that write protection mechanisms are in place to prevent accidental modifications to the target system’s memory during the dumping process.
For this purpose, we can install memory analysis tools such as Volatility or Rekall on the forensic workstation.
2.2. Dumping Memory Using LiME (Linux Memory Extractor)
LiME is a popular open-source tool used to create a memory image of a running Linux system. We’ll now take a look at the steps involved while we dump a memory image using LiME.
We must first obtain the latest version of LiME from the official repository or project website:
$ git clone https://github.com/504ensicsLabs/LiME.git
Once we’ve obtained it, we can build its kernel module appropriate for the target Linux system. This involves compiling the source code using the provided Makefile:
$ cd LiME; make
We’re then required to copy the compiled LiME module to the target system securely. Once copying is complete, we load the LiME module on the target system using the appropriate command. For example, we can use the insmod command to load the module into the Linux kernel:
$ sudo insmod /path/to/module.ko
Finally, we execute the necessary command to dump the memory into a file. For example, we can use the imageinfo command in Volatility, specifying the path to the memory image, to determine the appropriate profile:
$ volatility -f /path/to/memory/image.raw imageinfo
2.3. Analyzing the Memory Image
Once we’ve successfully dumped the memory image, we can proceed with its analysis using memory forensics tools like Volatility or Rekall. Let’s look at the steps to get started.
We must first install Volatility or Rekall on our forensic workstation. Using the appropriate command in Volatility or Rekall, we can identify the profile, denoted by PROFILE, of the memory image.
Using the various plugins and commands provided by Volatility or Rekall, we then extract information of interest from the memory image:
#Volatality
#Extract Process Listing:
$ volatility -f /path/to/memory/image.raw --profile=PROFILE pslist
#Retrieve Network Connections:
$ volatility -f /path/to/memory/image.raw --profile=PROFILE connections
#Analyze Loaded Modules:
$ volatility -f /path/to/memory/image.raw --profile=PROFILE modlist
#Investigate Open Files:
$ volatility -f /path/to/memory/image.raw --profile=PROFILE filescan
#Rekall:
#Extract Process Listing:
$ rekall -f /path/to/memory/image.raw --profile PROFILE pslist
#Retrieve Network Connections:
$ rekall -f /path/to/memory/image.raw --profile PROFILE connections
#Analyze Loaded Modules:
$ rekall -f /path/to/memory/image.raw --profile PROFILE modules
#Investigate Open Files:
$ rekall -f /path/to/memory/image.raw --profile PROFILE handles
Carefully analyzing the extracted information, we can identify any malicious activities, indicators of compromise, or relevant artifacts. In order to analyze specific aspects of the memory image, we can, for example, execute Volatility commands like pslist, connscan, filescan, etc. with the appropriate plugins.
3. Other Methods
In addition to the use of LiME, there are alternative methods involved in the process to dump a memory image. One commonly employed method is creating a crash dump file using the kdump utility. k**dump uses a dedicated kernel to capture, for example, a copy of the crashed kernel’s memory.
A few other methods discussed further in this section, involve accessing raw physical memory via kernel device files.
3.1. Read the Contents of Physical Memory Using /dev/mem
Reading the contents of physical memory from the device file /dev/mem requires careful handling and proper permissions due to the sensitive nature of system memory.
First, let’s open a terminal or command prompt on our Linux system and use the id command to check if we’re logged in as root. We must at the same time verify that /dev/mem exists. Consequently, we execute the following command to check if we have sufficient permissions to access /dev/mem:
$ ls -l /dev/mem
If not, we may need to log in as root or use the sudo command for the subsequent steps.
The next step involves determining the size of the physical memory we want to read. We can obtain this information using the free or cat /proc/meminfo commands.
We then have to decide on the offset and length of the memory region we want to read. The offset represents the starting address, and the length specifies the number of bytes to read. We must ensure that we select a valid memory range within the available physical memory.
Executing the following command, thereby replacing offset and length with the appropriate values, would help us read the contents of physical memory:
$ sudo dd if=/dev/mem of=mem_dump bs=1 count=<length> skip=<offset>
It may take some time to finish depending on the size of the memory region being read. So, we must wait for the command to complete. In this example, the command reads length bytes starting from the offset address and saves the data to a file named mem_dump in the current directory.
Once the command finishes, we can examine the contents of the mem_dump file using various tools, such as a hex editor or memory analysis software.
We must always exercise extreme care when accessing and analyzing memory contents because, if we don’t, then it can have severe implications. As a matter of fact, it can lead to system instability, crashes, or security vulnerabilities.
3.2. Raw Physical Memory Access via /dev/crash
Loading the crash driver to create a pseudo-device /dev/crash for raw physical memory access involves several steps. This process requires advanced knowledge and should be cautiously performed.
First, we need to ensure that the Linux kernel is built with support for the crash driver. We can check the kernel configuration file (usually located in /usr/src/linux/.config). This is to ensure that the necessary configuration options are enabled, specifically, options like CONFIG_CRASH_DUMP and CONFIG_CRASH_CORE.
If the crash driver isn’t already built as a module, we need to compile it from the kernel source code. To achieve this, we’ll execute the make command to build the module. We can follow the instructions provided in the crash driver source directory to build the driver module. Once the crash driver module is built, we can load it into the kernel using the modprobe command:
$ sudo modprobe crash_driver
We must then verify that the crash driver module has loaded successfully without any errors by checking the kernel log using the dmesg command.
Let’s use the mknod command to create the /dev/crash device file:
$ sudo mknod /dev/crash c <major> <minor>
We need to adjust the permissions of the /dev/crash device file to allow access for authorized users. For instance, we can set the permissions to 0600 (read and write only for the owner) using the chmod command:
$ sudo chmod 0600 /dev/crash
With the crash driver and /dev/crash device set up, we may attempt to access raw physical memory. This may involve using specialized tools or writing custom programs that utilize the crash driver’s capabilities.
3.3. Raw Physical Memory Access via /dev/fmem
We’ll now take a look at how a custom kernel module can create a device file like /dev/fmem for accessing physical memory. The procedure that follows is a simplified overview and the actual implementation may vary depending on the specific module and its purpose.
Here, we want to develop a custom kernel module that provides the functionality to access physical memory.
Within the kernel module, we have to define the file operations for the device file (/dev/fmem) we want to create. These operations include functions such as file open, read, write, and release, which handles the interactions between user-space programs and the device file.
Using the appropriate kernel APIs, we can register the character device with the specified major and minor numbers. This step associates the file operations implemented in the module with the device file.
When the module is loaded or initialized, typically during system boot or when explicitly loaded, we create the device file using the mknod command or the kernel API calls:
$ sudo mknod /dev/fmem c <major> <minor>
After creating the device file, we have to set the appropriate permissions to restrict access and ensure proper security. This involves using the chmod command or kernel APIs to modify the file permissions:
$ sudo chmod 0600 /dev/fmem
With the kernel module and the associated device file (/dev/fmem) in place, we can use user-space programs or tools to read from or write to physical memory through the device file. These programs interact with the file operations implemented in the kernel module to perform the desired memory operations.
4. Conclusion
In this article, we learned how to dump the memory image on a Linux system. Dumping memory from a Linux system is a crucial step in memory forensics, allowing investigators to extract valuable information and artifacts for analysis.
We can also utilize specialized tools to uncover insights, detect malicious activities, and support incident response efforts. However, we must remember to maintain the integrity of the investigation by working in a controlled environment. We must also keep in mind leveraging write protection mechanisms to prevent certain unintended modifications.