Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

PreviousGenerate custom profile using btf2jsonNextVolatility2 core commands

Last updated