# The Evolution of Volatile Memory Forensics
## 4 Memory Analysis
### Tooling
#### 4.1.1 Volatility  
In discussing volatile memory forensic tools, one cannot neglect to mention _Volatility_--an open source, Python-based framework for analyzing memory dumps [37]. _Volatility_ is capable of analyzing memory dumps from Windows, Linux, or Macintosh machines, supports many different types of file dump formats, and has an extensible application program interface (API). It also has excellent feature-creating functionality and is reasonably efficient in its implementation. _Volatility_ has emerged as the largest and best-supported framework because of its large base of contributors and independently authored plugins, many of which are geared toward platform-specific forensics [38]. The framework and many of the plugins, especially the plugins for analyzing Windows systems, are mature and stable enough to pass fuzz testing attempts [39]. Fuzz testing is a software testing method that injects invalid or unexpected inputs into a program to reveal defects and vulnerabilities. Most of the novel memory forensic tools discussed in later sections of this paper are implemented as a _Volatility_ plugin or utilize the _Volatility_ code base.  
A main drawback of _Volatility_ is that it is typically run from the command line interface, which makes it inaccessible to some potential users. In order to flatten the learning curve associated with using _Volatility_, a graphical user interface (GUI) has also been developed by [PERSON] et al. [40] that allows inexperienced memory forensic investigators to use basic _Volatility_ commands via a plugin in the software _Autopsy_.  
While _Volatility_ contains many different modes and commands, a typical invocation takes the following form:  
python3 vol.py -f <dumpfile> windows.pslist  
In this example, _Volatility_ extracts the Windows process list at the time of the memory image dump.  
Performance  
_Volatility_ developers claim it to be more efficient than other memory forensic software, including _Rekall_[37, 41], although an independent assessment of the software's performance was not found. _Volatility_ developers assert that _Volatility_2 was capable of \"list[ing] kernel modules from an 80 GB system in just a few seconds\" [37]. Furthermore, during the public release of the _Volatility_3 beta, developers claimed major performance improvements over _Volatility_2 and _Rekall_, in many instances [41].  
Here, we describe some of the basic capabilities of _Volatility_ that are widely used for memory forensics. [PERSON] et al. [42] provided a more thorough discussion and tutorial with an example code for all major architectures.  
Using _Volatility_, one can extract the current and previous process handles running on a system, a process's loaded dynamic-link libraries (DLLs), any commands an attacker entered through a console shell, memory resident pages, and process executables. It can also extract information about the process's virtual address descriptor (VAD) nodes, including the addresses of the VAD structure in kernel memory, the VAD tag, the VAD flags, control flags, and the name of the memory mapped file if one exists. It can obtain data about the kernel drivers loaded on the system, including those hidden in physical memory or in files on a disk. Likewise, it finds process thread objects in physical memory with pool tag scanning. Lastly, _Volatility_ is capable of obtaining information about the connections the system has made. Specifically, it extracts TCP connections that were active at the time of memory acquisition, listening sockets for any protocol, residual data and artifacts from previous sockets, and network artifacts, including TCP endpoints, TCP listeners, UDP endpoints, and UDP listeners.