Jack Wengerandikelos 53c36d91c3 added hashdump
Added documentation and logging

added cachedump and lsadump

Fixed requested issues

fixed encoding issues

added requirement

Framework: Move cache_clear function to the framework

Documentation: Document self.config slightly better

Linux/Mac: Refactor *nix Utilities classes

Automagic: Fix issue in recent refactor

Add elf parsing and symbol retrieval for linux kernel modules

Fixes on coding style

Linux: Restore accidentally dropped kobject definition

Core: Rerun yapf across the codebase.

First attempt and better DTB and ASLR validation. Debugging statements left in.

Mac: Stash the verified ASLR shift and improve logging

Linux: Support stashing the KASLR

Remove extra debug prints

added hashdump

Added documentation and logging

Linux - stash the Linux kernel virtual address

Hashdump: Reformat and convert to proper byte handling

Registry: Fix error message

Caching: Only cache remote files

Yarascan: Move most of yarascanning into a versionable plugin

This refactors common yara tasks, so we can use the plugin versioning to
keep track of changes to the YaraScanner class.

Core: Refactor versioning and associated requirements

Configuration: Improve the VersionableInterface documentation

Plugins: Remove unnecessary dependency for yarascan

Objects: Add a convenience function for validating enum values

Objects: Update enumeration method to is_valid_choice

Core: Maintain 3.5.3 compatibility

created tty_check.py; edited automagic/linux.py to add kernel tracking abilities

fixed some formatting for tty_check.py

Fixed tty_check not finding the ttyhook module

added some documentation

Removed unnecessary code from tty_check.py

added docs to automagic methods, fixed missing return types, changed parameters to be more specific

added kernel string to linux constants file; changed automagic methods so that they reconstruct the kernel object within the method for consistancy with other methods

added parameter type to generate_kernel_handler_info

Updated imports to reflect new location of utility class; plugins are no longer outputing anything so commiting for Andrew to take a look at

removed debugging print statements

fixed bug causing no output when tty_check is run

Windows.info: Refactor windows.info as classmethods

Linux: Fix plugin case and re-run yapf

created keyboard_notifiers

removed extra whitespace

Yapf: Minor reformats for recent plugins

Codebase: Ensure all conversions to bytes handle unicode

All conversions using `latin-1` have been converted to
`raw_unicode_escape` which is like `latin-1`, but handles unicode
characters appropriately (with a `\u` prefix).

Since this is like `latin-1` it should have no impact on things that ran
previously, but those that would fail with a unicode error now will
present an encoded unicode string.  There may be situations where the
binary representation of unicode would be better (timeliner file
output?), but those can be changed when/if it's determined necessary.

Fixes #274.

Linux: Fix keyboard_notifiers copyright year

Renderers: Fix the pretty renderer when no rows are emitted

Timeliner: Sort results and provide a filter

Sorts the results (as stated).  Note that user interfaces may decide to
sort their results in an order of their choosing.

Also added a parameter that can be provided multiple times to only allow
plugins that match (any of) the parameters provided.

Timeliner: Actually make use of the TextIoWrapper

Windows: Add a version to the info plugin now its got classmethods

CLI: Add additional help about 'vol.py plugin --help'

created linux_check_idt; plugin currently is not finding the module names for each entry in idt table

fix copyright year

fixed poor variable name, removed unnecessary code

added address mask to fix issue with kernel tracking

CLI: Revert epilog changes

Update lsadump.py

I'm not sure why your are getting this error since it works fine for me, but this may fix it
2020-08-23 21:32:27 +01:00
2020-08-23 21:32:27 +01:00
2019-10-14 22:07:28 +01:00
2019-09-25 21:44:05 +01:00
2019-10-09 22:57:22 +01:00
2019-10-09 22:57:22 +01:00

Volatility 3: The volatile memory extraction framework

Volatility is the world’s most widely used framework for extracting digital artifacts from volatile memory (RAM) samples. The extraction techniques are performed completely independent of the system being investigated but offer visibility into the runtime state of the system. The framework is intended to introduce people to the techniques and complexities associated with extracting digital artifacts from volatile memory samples and provide a platform for further work into this exciting area of research.

In 2019, the Volatility Foundation released a complete rewrite of the framework, Volatility 3. The project was intended to address many of the technical and performance challenges associated with the original code base that became apparent over the previous 10 years. Another benefit of the rewrite is that Volatility 3 could be released under a custom license that was more aligned with the goals of the Volatility community, the Volatility Software License (VSL). See the LICENSE file for more details.

Requirements

Optional Dependencies

Downloading Volatility

The latest stable version of Volatility will always be the master branch of the GitHub repository. You can get the latest version of the code using the following command:

git clone https://github.com/volatilityfoundation/volatility3.git

Quick Start

  1. Clone the latest version of Volatility from GitHub:

    git clone https://github.com/volatilityfoundation/volatility3.git
    
  2. See available options:

    python3 vol.py —h
    
  3. To get more information on a Windows memory sample and to make sure Volatility supports that sample type, run python3 vol.py -f <imagepath> windows.info

    Example:

    python3 vol.py —f /home/user/samples/stuxnet.vmem windows.info
    
  4. Run some other plugins. The -f or —-single-location is not strictly required, but most plugins expect a single sample. Some also require/accept other options. Run python3 vol.py <plugin> -h for more information on a particular command.

Symbol Tables

Symbol table packs for the various operating systems are available for download at:

https://downloads.volatilityfoundation.org/volatility3/symbols/windows.zip
https://downloads.volatilityfoundation.org/volatility3/symbols/mac.zip
https://downloads.volatilityfoundation.org/volatility3/symbols/linux.zip

The hashes to verify whether any of the symbol pack files have downloaded successfully or have changed can be found at:

https://downloads.volatilityfoundation.org/volatility3/symbols/SHA256SUMS
https://downloads.volatilityfoundation.org/volatility3/symbols/SHA1SUMS
https://downloads.volatilityfoundation.org/volatility3/symbols/MD5SUMS

Symbol tables zip files must be placed, as named, into the volatility/symbols directory (or just the symbols directory next to the executable file).

Windows symbols that cannot be found will be queried, downloaded, generated and cached. Mac and Linux symbol tables must be manually produced by a tool such as dwarf2json.

Please note: These are representative and are complete up to the point of creation for Windows and Mac. Due to the ease of compiling Linux kernels and the inability to uniquely distinguish them, an exhaustive set of Linux symbol tables cannot easily be supplied.

Documentation

The framework is documented through doc strings and can be built using sphinx.

The latest generated copy of the documentation can be found at: https://volatility3.readthedocs.io/en/latest/

Copyright (C) 2007-2020 Volatility Foundation

All Rights Reserved

https://www.volatilityfoundation.org/license/vsl-v1.0

Bugs and Support

If you think you've found a bug, please report it at:

https://github.com/volatilityfoundation/volatility3/issues

In order to help us solve your issues as quickly as possible, please include the following information when filing a bug:

  • The version of Volatility you're using
  • The operating system used to run Volatility
  • The version of Python used to run Volatility
  • The suspected operating system of the memory sample
  • The complete command line you used to run Volatility

For community support, please join us on Slack:

https://www.volatilityfoundation.org/slack

Contact

For information or requests, contact:

Volatility Foundation

Web: https://www.volatilityfoundation.org

Blog: https://volatility-labs.blogspot.com

Email: volatility (at) volatilityfoundation (dot) org

Twitter: @volatility

Languages
Python 99.9%