Writing Plugins For Volatility

In this post, I’ll be talking about how to write plugins for volatility.

The prime advantage with volatility is that it can be extended to any level depending on the needs and interests of the user. This feature of volatility is one of the main reasons why it is used in Incident Response and Malware Analysis. I have done my own research on the internet for the basics of writing a plugin for volatility. I literally spent 3 days just browsing the net.

After many difficulties, I finally succeeded in writing a basic plugin. The main motive of this blog is to explain the procedure to write a plugin from the very basics.

In this blog, I’ll be discussing how to write a blog similar to pslist. It’ll be pretty basic and hopefully, you’ll understand it.

So let’s do it!

I’ll discuss this on a stepwise basis so that I don’t miss anything crucial. The prerequisites for this will be pretty basic.

  1. You must know to script in python.
  2. How classes work in python. (Methods, Instances, objects etc.)

Well, that’ll mostly be enough to understand this.

Step 1: Create an MY PLUGIN folder

$ mkdir MyPlugins
$ cd MyPlugins
$ gedit testplugin.py


Step 2: Get the basics right

When learning about a new framework or something new which is actually really complex, you have approach it step by step and construct a very basic thing, which does not only work but makes your concepts clearer.

So let us do the same thing which we do with every new computing language that we learn. Yes, you are right! Let us write a Hello World! program for the volatility framework.

Screenshot from 2018-09-06 20-22-21

Okay, now let us run it!

Screenshot from 2018-09-06 15-37-55

Woah!! It actually worked. So now let me explain the above command.

  • –plugins=”/home/stuxn3t/Documents/MyPlugins”
    • It tells the framework to search for possible plugins from the above-mentioned directory.
  • -f  memorydump
    • The dumped memory file which is to be analyzed.
  • myplugin
    • The name of our plugin.

Some important points:

  • –plugins=”path/to/plugin/directory” must always come first.
    • Due to some limitations of the framework, it is mandatory to write “–plugins” immediately after volatility.
  • The path given in –plugins=”” must be absolute.

Now let us get on with the code.

import volatility.plugins.common as common

This is used to import the common library which is a part of the volatility framework.

class MyPlugin(common.AbstractWindowsCommand)

Every plugin in the volatility framework is actually a class. The name of the class becomes the name of the plugin. In this case, the name of the plugin will be myplugin.

If you observe, it is actually inheriting one of the Command classes. It is only by inheriting the command class which makes this script a plugin. Without importing the command class, volatility won’t recognize it as a plugin.

def render_text(self, outfd, data)

The framework is designed in such a way that Volatility will always look for a method named render_X where X matches the output parameter. By default, the output is of text format.

  • self
    • If you studied classes in python, you would know that self is the instance of the class and it is always the first parameter of any method in a class.
  • outfd
    • It is the output file descriptor. It actually specifies the output stream to which volatility will write the output. By default, it is always stdout.
  • data
    • This is actually the output of another method called calculate. The calculate method actually processes or generates the required output and passes it to render_X.


Step 3: A Step Higher

Let us proceed a bit further.

Screenshot from 2018-09-06 20-22-51

  • “”” This is your first plugin “””
    • This is a docstring. This is used by volatility to describe the plugin when we use -h or –help.
  • outfd.write(“Hello world!\n”)
    • Notice that we’ve replaced print with outfd.write(). So now our plugin will have a good extra functionality. Yes, now can you store the output in a file.

Step 4: Lets Spice It Up!

Now the interesting part. Let us get the processes running in the RAM. As mentioned earlier, we’ll be doing a basic pslist plugin. You can find the link for the plugin here.

So let us write the code.

import volatility.plugins.common as common
import volatility.utils as utils
import volatility.win32 as win32

class mynewplugin(common.AbstractWindowsCommand):
	""" Something similar to pslist """

	def calculate(self):

		addr_space = utils.load_as(self._config)
		tasks = win32.tasks.pslist(addr_space)
		return tasks

	def render_text(self, outfd, data):
		for task in data:

			outfd.write("{0}\t {1}\t {2}\n".format(task.UniqueProcessId, task.CreateTime, task.ImageFileName))

Now comes the explanation. I have purposefully written the code above so that you’ll at least think of something or else it’ll be just plain and simple spoon feeding.

If you notice there are 2 new libraries that have been imported

import volatility.utils as utils
import volatility.win32 as win32
  • def calculate(self)
    • Declaring the calculate method. It has self as its parameter so it becomes a method of the class.
  • addr_space = utils.load_as(self._config)
    • Declaring a variable which will contain the address space identified by self._config. 
    • self._config is an object which identifies various things about this run of Volatility.
    • addr_space is generated from the file passed via -f.
  • win32.tasks.pslist(addr_space)
    • This generates a list of process objects parsed from the address space.
  • return tasks
    • This is the “data” that is supplied to render_text.

Now I have to introduce you to something called _EPROCESS. There are a number of properties of processes we can use.

The ones that we’ve used are:

  1. UniqueProcessId
  2. CreateTime
  3. ImageFileName

That’s why I accessed these properties by tasks.UniqueProcessId, tasks.CreateTime, tasks.ImageFileName.

So let me just explain what the above-used properties are:

  • UniqueProcessId
    • This is a unique number that the system assigns to a particular process. No two processes have the same Id. It is also called as PID.
  • CreateTime
    • This is the time when the process started to run with respect to the latest boot time.
  • ImageFileName
    • It’s basically the name of the process.

So let us run our beautiful plugin:

Screenshot from 2018-09-06 20-08-39

Please keep in mind that you have to identify the correct profile to let the plugin work.

Without the correct profile, the address spaces will not be loaded.

So that’s it!! I hope you really like it. Follow me on the next blog to learn about Unified Output, TreeGrid etc which actually are the latest developments in the Volatility Framework.

2 thoughts on “Writing Plugins For Volatility

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

Create your website at WordPress.com
Get started
%d bloggers like this: