NAME¶

SYNOPSIS¶

volatility [option]
volatility -f [image] --profile=[profile] [plugin]

DESCRIPTION¶

Currently, Volatility (version 2.6) supports several versions of the MS Windows, Linux and MAC OSX:

The memory formats supported are:

The supported address spaces (RAM types) are:

There are RAM images for tests at https://github.com/volatilityfoundation/volatility/wiki/Memory-Samples.

OPTIONS¶

-h, --help

List all available options and their default values. Default values may be set in the configuration file (/etc/volatilityrc).

--conf-file=/root/.volatilityrc

User based configuration file.

-d, --debug

Debug Volatility.

--plugins=PLUGINS

Additional plugin directories to use (colon separated).

--info

Print information about all registered objects.

--cache-directory=/root/.cache/volatility

Directory where cache files are stored.

--cache

Use caching.

--tz=TZ

Sets the (Olson) timezone for displaying timestamps using pytz (if installed) or tzset.

-f FILENAME, --filename=FILENAME

Filename to use when opening an image.

--profile=WinXPSP2x86

Name of the profile to load. (Use --info to see a list of supported profiles)

-l LOCATION, --location=LOCATION

An URN location from which to load an address space.

-w, --write

Enable write support.

--dtb=DTB

DTB Address.

--shift=SHIFT

Mac KASLR shift address.

--output=text

Output in this format (format support is module specific).

--output-file=OUTPUT_FILE

Write output in this file.

-v, --verbose

Verbose information.

--physical_shift=PHYSICAL_SHIFT

Linux kernel physical shift address.

--virtual_shift=VIRTUAL_SHIFT

Linux kernel virtual shift address.

-g KDBG, --kdbg=KDBG

Specify a specific KDBG virtual address. (Note: for 64-bit Windows 8 and above this is the address of KdCopyDataBlock)

-k KPCR, --kpcr=KPCR

Specify a specific KPCR address.

--force

Force utilization of suspect profile.

--cookie=COOKIE

Specify the address of nt!ObHeaderCookie (valid for Windows 10 only).

PLUGINS AND PROFILES¶

Profiles are maps used by Volatility to understand the operational systems. The allowed MS Windows profiles are provided by the Volatility.

You must create your own profiles for Linux and MAC OSX. For this, on Debian systems, read the README.Debian file provided by volatility-tools package.

On MS Windows, to determine the OS type, you can use:

    $ volatility -f <image> imageinfo
    or
    $ volatility -f <image> kdbgscan

ENVIRONMENT VARIABLES¶

Other plugin flags may be utilized in this way, for example KPCR, DTB or PLUGINS. When exporting variables, simply prefix VOLATILITY_ before the flag name (e.g. VOLATILITY_KPCR). Otherwise, the flag name remains the same when adding it to the configuration file.

If you have a path with a space or more in the name, spaces should be replaced with %20 instead (e.g. LOCATION=file:///tmp/my%20image.img).

Example:

    $ export VOLATILITY_PROFILE=Win7SP0x86
    $ export VOLATILITY_LOCATION=file:///tmp/myimage.img
    $ export VOLATILITY_KDBG=0x82944c28

CONFIGURATION FILES¶

    [DEFAULT]
    PROFILE=Win7SP0x86
    LOCATION=file:///tmp/myimage.img
    KDBG=0x82944c28

If you have a path with a space or more in the name, spaces should be replaced with %20 instead (e.g. LOCATION=file:///tmp/my%20image.img).

EXTRA PROCEDURES¶

   Timestamps extracted from memory can either be in system-local time, or in Universal Time
   Coordinates (UTC). If they're in UTC, Volatility can be instructed to display them in a time zone
   of the analyst's choosing. To choose a timezone, use one of the standard timezone names
   (such as America/Sao_Paulo, Europe/London, US/Eastern or most Olson timezones) with the --tz=TIMEZONE flag.
   Volatility attempts to use pytz if installed, otherwise it uses tzset.
   Please note that specifying a timezone will not affect how system-local times are displayed. If you identify
   a time that you know is UTC-based, please file it as an issue in the issue tracker. By default the _EPROCESS
   CreateTime and ExitTime timestamps are in UTC.

   The DTB (Directory Table Base) is what Volatility uses to translate virtual addresses to physical addresses.
   By default, a kernel DTB is used (from the Idle/System process). If you want to use a different process's DTB
   when accessing data, supply the address to --dtb=ADDRESS.

   Volatility scans for the '_KDDEBUGGER_DATA64' structure using hard-coded signatures "KDBG" and a series of sanity
   checks. These signatures are not critical for the operating system to function properly, thus malware can overwrite
   them in attempt to throw off tools that do rely on the signature. Additionally, in some cases there may be more
   than one '_KDDEBUGGER_DATA64' (for example if you apply a major OS update and don't reboot), which can cause confusion
   and lead to incorrect process and module listings, among other problems. If you know the address
   add '_KDDEBUGGER_DATA64', you can specify it with --kdbg=ADDRESS and this override the automated scans. For more
   information, see the kdbgscan plugin.

   There is one KPCR (Kernel Processor Control Region) for each CPU on a system. Some Volatility plugins display
   per-processor information. Thus if you want to display data for a specific CPU, for example CPU 3 instead of
   CPU 1, you can pass the address of that CPU's KPCR with --kpcr=ADDRESS. To locate the KPCRs for all CPUs, see
   the kpcrscan plugin. Also note that starting in Volatility 2.2, many of the plugins such as idt and gdt
   automatically iterate through the list of KPCRs.

   Write support in Volatility should be used with caution. Therefore, to actually enable it, you must not only type
   --write on command-line but you must type a 'password' in response to a question that you'll be prompted with.
   In most cases you will not want to use write support since it can lead to corruption or modification of data in
   your memory dump. However, special cases exist that make this feature really interesting. For example, you could
   cleanse a live system of certain malware by writing to RAM over firewire, or you could break into a locked workstation
   by patching bytes in the winlogon DLLs.

   Volatility's plugin architecture can load plugin files from multiple directories at once. In the Volatility source
   code, most plugins are located in volatility/plugins. However, there is another directory (volatility/contrib)
   which is reserved for contributions from third party developers, or weakly supported plugins that simply aren't
   enabled by default. To access these plugins you just type --plugins=contrib/plugins on command-line. It also enables
   you to create a separate directory of your own plugins that you can manage without having to add/remove/modify files
   in the core Volatility directories.

   On Debian systems, the contrib/plugins directory is at /usr/share/volatility/contrib/plugins.
   Subdirectories will also be traversed as long as there is an __init__.py file (which can be empty) within them.
   The parameter to --plugins can also be a zip file containing the plugins such as --plugins=myplugins.zip.
   Due to the way plugins are loaded, the external plugins directory or zip file must be specified before any
   plugin-specific arguments (including the name of the plugin). Example:


    $ volatility --plugins=contrib/plugins -f XPSP3x86.vmem example

   By default, plugins use text renderers to standard output. If you want to redirect to a file, you can of course
   use the console's redirection (i.e. > out.txt) or you could use --output-file=out.txt. The reason you can also
   choose --output=FORMAT is for allowing plugins to also render output as HTML, JSON, SQL, or whatever you choose.
   However, there are no plugins with those alternate output formats pre-configured for use, so you'll need to add
   a function named render_html, render_json, render_sql, respectively to each plugin before using --output=HTML.

   Many plugins accept arguments of their own, which are independent of the global options. To see the list of
   available options, type both the plugin name and -h/--help on command-line.


    $ volatility dlllist -h

   If something isn't happening in Volatility the expected way, try to run the command with -d/--debug.
   This will enable the printing of debug messages to standard error. To more debug levels, as in using
   pdb debugger), add -d -d -d to command.

   Although its possible to use Volatility as a library, (there are plans to support it better in the future).
   Currently, to import Volatility from a python script, the following example code can be used:


    $ python
    >>> import volatility.conf as conf
    >>> import volatility.registry as registry
    >>> registry.PluginImporter()
    <volatility.registry.PluginImporter object at 0x7f9608f3ac10>
    >>> config = conf.ConfObject()
    >>> import volatility.commands as commands
    >>> import volatility.addrspace as addrspace
    >>> registry.register_global_options(config, commands.Command)
    >>> registry.register_global_options(config, addrspace.BaseAddressSpace)
    >>> config.parse_options()
    >>> config.PROFILE="WinXPSP2x86"
    >>> config.LOCATION = "file:///media/memory/private/image.dmp"
    >>> import volatility.plugins.taskmods as taskmods
    >>> p = taskmods.PSList(config)
    >>> for process in p.calculate():
    ...   print process

EXAMPLES¶

    $ volatility --info

    $ volatility -f win8.raw --profile=Win8SP0x86 pslist

    $ volatility -f win8.raw --profile=Win8SP0x86 pslist --tz=America/Sao_Paulo

    $ volatility -f mem.dd --profile=Linux_3_2_63_x64 linux_dmesg

NOTES¶

• http://www.volatilityfoundation.org
• https://github.com/volatilityfoundation/volatility/wiki

AUTHOR¶

This manual page was written by Joao Eriberto Mota Filho <eriberto@debian.org> for the Debian project (but may be used by others).