Skip to content

Memory analysis

Memory analysis is the practice of determining information about running programs, the operating system, and the overall state of a computer from a memory image.

While volatile memory acquisition provides a critical, real-time snapshot of running processes, network connections, and decrypted credentials, it remains just one piece of a comprehensive investigation. Overarching forensic methodologies must actively account for the inherent shortcomings of memory analysis, such as the risk of data smearing during live acquisition, the transient nature of volatile data, and anti-forensic techniques designed to evade detection.

Relying solely on RAM analysis creates dangerous blind spots; therefore, sound investigative frameworks must seamlessly integrate memory artifacts with traditional disk forensics, network logs, and timeline analysis to ensure findings are defensible, validated, and holistic.

Memory analysis, by its nature, is highly dependent on the operating system, most of its techniques are described on the per-platform pages:

This article describes the techniques that apply across platforms:

The tools used to apply these techniques are gathered in Memory analysis tools.

Data types

Per https://en.wikipedia.org/wiki/Integer_(computer_science):

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.

Per https://en.wikipedia.org/wiki/64-bit_computing:

on a 64-bit system the size of an "int" can vary based on the data-model

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.

Per https://en.wikipedia.org/wiki/Endianness:

When reading primitive data types from a byte stream the endianness specifies how the least and most significant parts of the data are stored.

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 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 (or byte) strings.

  • Unicode strings typically are stored in a Transform format
  • There are multiple versions of Unicode
  • A predecessor to Unicode is the Universal Character Set (UCS)
  • 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 endianness 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.

Memory analysis frameworks

Most memory analysis is done through a framework - Volatility is the leading example - which pairs generic analysis plugins with profiles that describe the data structures of a specific operating system and version. Because a plugin is written against the profile rather than against one particular system, the same analysis can be applied to images of many operating systems, and the results - processes, handles, network connections, encryption keys - are comparable across systems.

See also Volatility Framework, Rekall profiles, List of Volatility plugins and Memory analysis tools: memory analysis frameworks.

OS-Independent Analysis

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.

See also Platform independent tools.

Encryption Keys

Various types of encryption keys can be extracted during memory analysis, including symmetric keys such as AES keys, asymmetric keys such as RSA private and public keys, and passphrases for TrueCrypt volumes.

See also List of Volatility plugins and Memory analysis tools: memory analysis frameworks.

Browser and email artifacts

Web-mail and e-mail clients keep session state in memory - message bodies, attachments and account data - that may never be written to disk, and that can be recovered from a memory image even when the on-disk store is unavailable or corrupted.

See also Memory analysis tools: browser and email artifacts.

Instant messenger artifacts

Instant messenger clients cache conversations, contacts and account information in memory, and those artifacts can be recovered from a memory image without contacting the messaging service.

See also Memory analysis tools: instant messenger artifacts.

Memory analysis support

Executables extracted from memory are generally left in a state that cannot be executed, diffed, or hash-validated: their relocations are not yet applied, so they must be restored to their original state before comparison or verification is meaningful.

See also Memory analysis tools: memory support.

See Also

Rekall Forensics blog

Anti-forensics

Computer architecture

Data types

Volatility Labs