Banners, isfinfo, and custom profiles
How to force Volatility3 to use a specific (albeit mismatching) Linux kernel profile
Let's explore a couple of concepts to ensure we're using the correct terminology.
Volatility uses the 'banners' plugin to identify the operating system, kernel version, compilation information, etc. This is critical to ensure the correct profile is used when attempting to parse the memory dump. The correct profile ensures that kernel is correctly identified, and the correct memory structures are mapped correctly.
The Intermediate Symbol Format (ISF) is a JSON-based file which Volatility uses (as the 'isfinfo' plugin) to store specific memory structures to ensure they're mapped correctly, allowing execution of other plugins.
As I highlighted here, you can use the banners plugin to identify the operating system if it was previously unknown. The banners plugin also aids in troubleshooting and debugging when building custom profiles.
I recently helped a person on Discord to build a custom kernel profile for a memory sample which was collected during a CTF. We can approach this in a simple manner. 1) Run banners, and 2) run strings
Identify banner information
$ python3 vol.py -f dump.raw banners
Volatility 3 Framework 2.20.0
Progress: 100.00 PDB scanning finished
Offset Banner
0x77a00200 Linux version 5.15.0-43-generic (buildd@lcy02-amd64-076) (gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #46-Ubuntu SMP Tue Jul 12 10:30:17 UTC 2022 (Ubuntu 5.15.0-43.46-generic 5.15.39)
0x78dc3718 Linux version 5.15.0-43-generic (buildd@lcy02-amd64-076) (gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #46-Ubuntu SMP Tue Jul 12 10:30:17 UTC 2022 (Ubuntu 5.15.0-43.46-generic 5.15.39)9)We can see that the kernel Ubuntu 5.15.0-43 is being used in this sample. Ubuntu docs suggest that it was published on/around 9th May 2023 and was released in Jammy (22.04).
Because you can use different releases with different kernels (20.04 with 5.15.0-43, 22.04 with 5.15.0-43, etc), we want to confirm which release this sample came from. This makes it easier when attempting to locate relevant debugging symbols.
Confirm operating system release
We know that Ubuntu stores its release information in the following locations (examples included)
/etc/issue
/etc/os-release
/etc/lsb-release
We can use these locations (with strings/grep) to gather more information. This command will print 4 the matching line, plus the previous 4 lines.
So now we have the release version and kernel version. You can follow the guide here to generate a kernel profile before you continue.
Inspecting custom profile JSON
Following the previous guide, we've generated a custom profile for our memory sample. We've moved it into our default symbols directory, so let's try and use it to process our memory sample.
First step is to run isfinfo to make sure it's a registered/cached profile.
Good start, let's run linux.pslist to identify processes.
But we downloaded the correct release, installed the correct kernel (5.15.0-43-generic) and installed the relevant debugging symbols (5.15.0-43-generic-dbgsym). So what's wrong?
We can see there's a slight mismatch between the output from isfinfo (our custom profile) and the string which banners has produced.
Open the .json file for the kernel profile you created (Ubuntu20.04-5.15.0-43-generic.json)
You'll also find a field called 'constant_data' which is base64 encoded
Take your banners output and convert it into base64 (echo, cyberchef, etc)
Replace the original base64 value in the kernel profile with your new value
Save this as a new profile (Ubuntu.5.15.0-43-generic-modified.json), clear your volatility cache, then attempt to run the plugin again.
Last updated