Memory Analysis Background

Please read the two Kornblum papers referenced on the class home page, Identifying almost identical files using context triggered piecewise hashing and Using Every Part of the Buffalo in Windows Memory Analysis

Memory analysis

• As WFA points out on p. 88, extensive memory analysis is a relatively new field, though mature enough to be useful divided into "Old School" and more recent versions (following MFFG, pp. 96-97.)
• Microsoft has predictably dragged its feet on this. WFA gives accounts of what the field has tried to improved the situation, but it's still a travesty. To quote WFA from page 100:

"However, the one thing to keep in mind is that the only thing consistent between versions of the Windows operating system regarding these structures is that they aren't consistent. You heard right: The size and even the values of the structures change not only between operating system versions (for example, Windows 2000 to XP) but also between service packs of the same version of the operating system."

• Now consider the long list of systems and service packs for them: Windows NT history.

Memory analysis

• Firewire/Thunderbolt hacks. As recounted in the WFA book, use of Firewire (IEEE 1394) protocol and its follow-on, Thunderbolt, makes a machine vulnerable to rampant memory scanning.
• Crash dumps: if everything works out, you might even get useful information — certainly it seems that the NSA is using this.
• Virtualization is having an effect. Many ISPs have widely deployed virtualization, and getting a snapshot of a virtual machine is usually not difficult. Tools such as ZRam can make it even faster to look through swap space, for instance, on virtual instances from the hypervisor.

Why look into memory?

As WFA summarizes,

• Oldest answer: passwords. As we will discuss ad infinitum, passwords are the bane of the investigator's existence. Other simple flat data include network data and email addresses.
• More modern answers: Processes as such; for instance, malware investigators trying to find decrypted versions of encrypted/obfuscated malware.
• History: trying to find out what a malefactor may have been doing and how he was doing it.
• Rootkits (Blue Pill?).
• Terminated process data.
• But remember the Exchange Principle: if you are starting a process such as dd on the machine, you are changing the state of the machine. Also, bear in mind that if you are on a live machine that memory pages are changing both before and after you hit any given page.

Why look into memory?

MF on page 124 gives three primary reasons for memory analysis:

1. Metadata (such as network connections) that malware or other malefactors might have associated with a process.
2. Executable code, such as the above-mentioned decrypted executables.
3. Real data, such as passwords, encryption keys, and usernames.

MFFG in chapter 2 brings up:

1. Filesystem data (particularly MFT entries)
2. Hidden and obfuscated process data
3. Registry information

How do we usefully look into a memory dump?

• The oldest technique is to just look for interesting strings. WFA mentions grep family tools; there is also a dedicated program called strings which is quite useful for looking for these. MF suggests using options such as -t x to get memory offsets for particular strings. MF also mentions that by default, strings only looks for ASCII encodings (7-bits), but Windows dumps should be examined for Unicode strings also (see sysinternals version, for instance, includes such support as do most modern versions of Linux strings (-e l option, for instance, for little-endian 16 bit strings).
• Better parsing of memory dumps has been advancing in the last few years. However, a good "block-matching" tool seems to be lacking even now. With the randomization of memory layout, mapping out a memory dump's pedestrian areas, even when they are intentionally spattered about in memory, would be a useful analysis tool.

Processes in the Windows world

• What are the steps in creating a Windows Process? WFA gives a summary as:
1. Open the executable and figure out what subsystem it needs to run under. (Very likely, of course, it will be in the Windows subsystem (Win32/WoW64 — if it's not in the Windows subsystem, the process may be worth investigating))
2. Create an EProcess object. Set up a KProcess (kernel process block), the PEB (the process environment block), and an initial address space.
3. Create the initial thread for the process.
4. Alert the Windows subsystem as to this process.
5. Begin execution of the initial thread.

Parsing processes

• Various tools have been created to parse Windows processes.
• ptfinder.pl by Andreas Schuster, which walks through memory trying to enumerate processes and threads from memory dumps.
• A large number by the author of WFA, Harlan Carvey.
• Powershell tools: Get-Process

ssdeep

• To combat the problem that reconstructed executable images from programs such lspi.pl are not consistently the same, programs such as ssdeep by Jesse Kornblum can be used to perform "fuzzy matching."

Volatility

Another tool that MF brings up on pp. 122-124 and pp. 132-144 is volatility, which attempts to analyze memory. One nonobvious and interesting facet to such tools is that they are sometimes able to find old data from processes that have already terminated.

Hibernation is almost as useful as virtualization

• One interesting area of memory analysis has become of that of hibernation files. A hibernation file holds enough state to accurately reload memory — and thus enough state to be highly interesting to an investigator.

Memory layout

• MF gives a succinct description of Windows memory layout pp. 145-146 and how to parse a given entry.
• Windows uses a page directory/page table. Parsing the two is an annoying process at best, and it's remarkable that such an awkward virtual memory architecture can provide reasonable speed. Microsoft has a decent presentation at http://technet.microsoft.com/en-us/library/cc736309%28WS.10%29.aspx about issues and structure in Windows memory layout.
• An example of translating virtual addresses to physical memory is available at http://computer.forensikblog.de/en/2006/03/converting_virtual_into_physical_addresses.html.

MF's take on memory analysis methodology

MF proposes on pp. 124-125 a simple methodology for memory analysis:

• Reifications such as processes and network connections are studied as metadata to fit against known problems.
• Specific data associated with these (such as process executable code, process stack, and any process heap areas) are extracted.

Finding an executable, even if it's not in non-volatile storage

• http://computer.forensikblog.de/en/2006/04/reconstructing_a_binary.html outlines how to recover a binary from a memory dump. In section two, memdump.pl is advanced as a tool to help parsing memory dumps.
• Like all such ad hoc tools, it may (or may not) do what you need.