Memory Analysis is the science of using a memory image to determine information about running programs, the operating system, and the overall state of a computer. Because the analysis is highly dependent on the operating system, it has been divided into the following pages:
Different programming languages provide different primitive data types, e.g. in C it is common to have "char", "int", "long", "float", "double". The size of these primitive data types is dependent on multiple factors like the CPU, the programming language, the compiler, etc. 1 e.g. on 64-bit system the size of an "int" can vary based on the data-model 2.
Note that some memory analysis resources and tools are known to completely disregard this aspect of 64-bit computing and claim incorrectly an integer is always 32-bit on 64-bit systems or claim the size of the integer is operating system dependent.
When reading primitive data types from a byte stream the endianness specifies how the least and most significant parts of the data are stored 3.
Composite data types (also referred to as data structures) consists of primitive and/or composite data types.
When reading data structures from memory note that data structure alignment 4 can be applied.
Character and string data types
Note that this subject could fill books by itself and the following information is a very brief overview of some of the characteristics of character and string data types.
A programming language can distinguish between Unicode, non-Unicode and binary strings 5.
- Unicode strings typically are stored in a Tranform format 6
- There are multiple versions of Unicode
- A predecessor to Unicode is Universal Character Set (UCS) 7
- non-Unicode strings can be stored in various encodings e.g. ASCII 8
- typical the encoding is identified by a codepage e.g. for CP1252 for Windows 9
- In Windows the supported set of non-Unicode strings is referred to as ANSI-strings, which is technically incorrect but a too widely used term to be ignored.
- In other texts or contexts non-Unicode strings can be referred to as extended ASCII or ASCII with codepage strings, which, dependent on the context, can also be technically incorrect since non-Unicode strings can be stored in non-ASCII methods as well, e.g. EBIDIC or the codepage in which the string is stored has no historical relation to ASCII.
- There are multiple variants of non-Unicode strings sometimes divided in single byte character (SBC) and multi byte character (MBC) strings. Note that character here refers to the primitive data type used, not a textual character of the string.
- Binary strings can contain bit- or byte streams. Since bitstreams are often stored in bytes the endianess of the bits within the byte is relevant when reading or writing the string.
Another distinction made in some programming languages is to have a default (or narrow) character type, e.g. in C "char", and a separate wide character type, e.g. in C "wchar_t". The "wchar_t" is typically associated with Unicode strings. Note that this should be taken as a very loose association, since the "char" can be used to store Unicode strings in UTF-8 and wchar_t can be used to store non-Unicode strings. The typical size of char is 8-bits where the MSB is the sign bit. The typical size of wchar_t varies per "platform", e.g. it is common to see wchar_t to be 32-bit of size on Linux with gcc and 16-bit of size on Windows with MSC.
At the IEEE Security and Privacy conference in May 2011, Brendan Dolan-Gavitt presented a novel system, Virtuoso, that was able to perform operating-system independent memory analysis. Using virtual machine introspection accompanied by a number of formal program analysis techniques, his system was able to monitor the machine-level instructions and behavior of application actions (listing processes, network connections, etc) and then automatically generate Volatility plugins that replicated this analysis.
Various types of encryption keys can be extracted during memory analysis.
- AESKeyFinder extracts 128-bit and 256-bit AES keys and RSAKeyFinder and private and public RSA keys from a memory dump 10.
- cryptoscan.py which is a plugin for the Volatility framework, scans a memory image for TrueCrypt passphrases
- Memory Imaging
- Memory Imaging Tools
- Memory Analysis Tools
- Linux Memory Analysis
- Virtualization Memory Analysis
- Windows Memory Analysis
- YobiWiki: RAM analysis
- RAM is Key - Extracting Disk Encryption Keys From Volatile Memory, by Brian Kaplan, May 2007
- Forensics Examination of Volatile System Data Using Virtual Introspection, by Brian Hay and Kara Nance, 2008
- Discovering ephemeral evidence with Live RAM analysis by Oleg Afonin and Yuri Gubanov, 2013
- An Evaluation Platform for Forensic Memory Acquisition Software by Stefan Voemel and Johannes Stuettgen, DFRWS 2013
- Integrating Volatile Memory Forensics into the Digital Investigation Process, by AAron Walters, Nick Petroni, Blackhat 2007
- Forensic Analysis of Anti-Forensic Activities, by Jack Crook, January 29, 2014
- ADD: The Next Big Threat To Memory Forensics....Or Not, by Michael Hale Ligh, February 3, 2014
- Anti-forensics and memory analysis, by Michael Cohen, February 7, 2014
- Memory Forensics: Still Aborted, by Takahiro Haruyama, April 21, 2014
- Wikipedia: 64-bit computing
- Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture, by Intel, May 2011
- 64-Bit Programming Models: Why LP64?, The Open Group, 1997
- Wikipedia: Primitive data type
- Wikipedia: Integer
- Wikipedia: 64-bit computing
- Wikipedia: Endianness
- Chapter 4. Programming with Cygwin
- Wikipedia: Data structure alignment
- Type Systems, by Luca Cardelli
- MoVP 1.4 Average Coder Rootkit, Bash History, and Elevated Processes
- MoVP 1.5 KBeast Rootkit, Detecting Hidden Modules, and sysfs
- MoVP 2.4 Analyzing the Jynx rootkit and LD_PRELOAD
- MoVP 2.5: Investigating In-Memory Network Data with Volatility
- MoVP 3.5: Analyzing the 2008 DFRWS Challenge with Volatility
- MoVP 4.2 Taking Screenshots from Memory Dumps
- MoVP 4.3 Recovering Master Boot Records (MBRs) from Memory
- Phalanx 2 Revealed: Using Volatility to Analyze an Advanced Linux Rootkit
- Solving the GrrCon Network Forensics Challenge with Volatility
- OMFW 2012: Analyzing Linux Kernel Rootkits with Volatility
- OMFW 2012: Datalore: Android Memory Analysis
- MoVP for Volatility 2.2 and OMFW 2012 Wrap-Up
- Reverse Engineering Poison Ivy's Injected Code Fragments
- TrueCrypt Master Key Extraction And Volume Identification, by Michael Hale Ligh, January 14, 2014