Steps to add new x86 OS Support

[kesullivan]

I have a 32-bit x86 OS that is close to Linux, BSD based, and I was wondering what some high level steps I will need to take to add support for that OS in PyREBox3?

I have started to add support for this OS in Volatility 3 and can do some basic things with a dump like pslist and will continue to work on more but my end goal is to have it working in the python3 version of pyrebox. I know so far I will have to support a pyrebox.py script in volatility/volatility/framework/plugins/os and add some functions to volatility/volatility/framework/symbols/os/extensions/__init__.py
And am wondering what other steps like that I will need to take inside the pyrebox code to start to support a new os?
#105 Will probably be my best reference for adding support but other bullets I will need to hit or any tips would be greatly appreciated

[xabiugarte]

Hi kesullivan,

I am glad you are willing to add support to another OS! :-) That's great news :-).

A few points:

VMI is done part in C/C++ and part in Python, for efficiency. If you look under pyrebox/ you will see some genetic clases: (vmi.h, vmi.cpp, vmi.py), that implement generic classes and redirect the function calls to the appropriate functions located in OS specific files: (see windows_vmi.h, windows_vmi.cpp, windows_vmi.py. / linux_vmi.h, linux_vmi.cpp, linux_vmi.py).

You will need to start by adding a new OS to this enum:

• https://github.com/Cisco-Talos/pyrebox/blob/master/pyrebox/vmi.h#L88

• And update some functions here to include your OS: https://github.com/Cisco-Talos/pyrebox/blob/master/pyrebox/vmi.cpp#L135

  • There is an init function that sets the appropriate OS based on the "prof" (profile) string that comes from pyrebox's configuration file.
  • There are a couple of callback functions for context-change and tlb-callbacks that redirect the call to the corresponding O.S. specific callback function (see windows_vmi.h, windows_vmi.cpp, windows_vmi.py. / linux_vmi.h, linux_vmi.cpp, linux_vmi.py).

• You will need to create the .h/.cpp and .py files for VMI for your O.S. Given your OS is quite based on Linux as you say, you can take the linux ones as a template as they will be closer to yours. linux_vmi deals with finding and updating the kernel offsets and updating the list of kernel/userland modules, by using volatility. The CPP file, deals with obtaining certain offsets from volatility by calling functions in Python (you shouldn't need to code that from scratch, just adapt it to your needs), and also implements the function to obtain the process list, which is triggered on VMI TLB callbacks (initialize_init_task).

Hope this information is useful to understanding the bigger picture. I hope I am not missing anything, but if that's the case and you get stuck in something, please let me know and I will try to answer.

Thanks again for adding support for your OS, this can be a good contribution :-).

[kesullivan]

@xabiugarte In volatility3 my os relies on the config.json to skip some automagic analysis for things like the linux_banner my os does not have a linux_banner so I hard code a value to look for in the config.json and also put that in the symbols.json so it can make the correlation on which symbols file to use

Is there a way to have pyrebox also use the config.json when dealing with volatility commands?

[kesullivan]

Never mind I reworked some of my volatility code to get automagic to work and grab the linux_banner and also the CR3 value for the DTB

[xabiugarte]

Hi Kesullivan,

It is fine to make changes under the volatility/ directory. As a good practice, try to make them as decoupled as possible from the original volatility code so that it is easier to merge upstream releases. Also, it would be great if you talk with the volatility team to include these changes in their upstream repository (if you have not done so already).

Thanks,