Linux Volatile Memory Forensics: Key Caveats in Acquisition and Analysis [PART 2 Final]

Background:

In our previous article, we discussed and compared various tools that facilitate the acquisition of volatile memory . In this article we are going to cover final part of our challenge to analyze already acquired volatile memory file .

Steps:

1. Prepare volatility3 tool
2. Prepare linux distro Symbol Tables file
3. Analyze it

Prepare volatility3 tool : You can find the installation package for Volatility 3 on their official GitHub repository. However, keep in mind that this tool is designed only for analyzing already acquired memory. It does not come with a preinstalled Symbol Tables package for Linux distributions. The Volatility team only provides the analyzer with some pre-built plugins, such as linux.bash.Bash, linux.boottime.Boottime and so on.

Prepare linux distro Symbol Tables file: A symbol table is a special map for each Linux distribution that allows Volatility 3 to understand exactly where specific components are stored in memory. As a result, it can correctly allocate them during plugin execution. This is one of the most challenging aspects of volatile memory analysis. The difficulty arises because, in many Linux distributions, symbol table files are stored in a compressed format, but for Volatility 3 to work properly, they need to be in an uncompressed form. Let's review one example on most distros this compressed file exists in compressed view inside /boot folder . And from name you can see that it contains "Z" letter (vmlinu/Z-6.8.0) which mean that this file will not be useful for us because it is compressed ./usr/lib/debug/boot/vmlinux-6.8.0-40-generic

After running a special command such as apt-get install linux-image-6.8.0-40-generic-dbgsym, the system downloads a file to /usr/lib/debug/boot/vmlinux-6.8.0-40-generic. Notice the file name uses “vmlinux” (not “vmlinuz”); the letter “X” in our example signifies that the file is uncompressed.

This uncompressed kernel image can be used by analyzer plugins to correctly allocate space and interpret kernel symbols.

However, before feeding this data to your analyzer, we need to transform the file into JSON format.

We need to convert this data using dwarf2json convertor .

After this process, we need to create a folder named Linux inside volatility3/volatility3/symbols, and place the newly created JSON file into it. This allows the Volatility analyzer to automatically find the reference to the Symbol Tables and analyze it.

Analyze it: On final part just running command "python3 vol.py -f ./memory.dmp linux.boottime.Boottime "

The argument -f specifies the path to the volatile dump, and the next argument is the plugin name. This allows us to see the result of the forensic action.

Conclusion:

Analyzing volatile memory is not an easy task, especially when it comes to scaling during the Incident Response analysis stage. For this reason, all toolsets should be prepared in advance during the preparation stage, before any incident occurs.