Memory analysis
- As WFA points out on p. 88, extensive memory analysis is a relatively new field.
- 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 hacks. As recounted in the WFA book, use of Firewire (IEEE 1394) protocol makes a machine vulnerable to rampant memory scanning.
- Crash dumps: if everything works out, you might even get useful information.
- Virtualization is having an effect. Many ISPs have widely deployed virtualization, and getting a snapshot of a virtual machine is usually not difficult.
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.
- Rootkits (Blue Pill?).
- Terminated process data.
- But remember the Exchange Principle: if you are starting 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:
- Metadata (such as network connections) that malware or other malefactors might have associated with a process.
- Executable code, such as the above-mentioned decrypted executables.
- Real data, such as passwords, encryption keys, and usernames.
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.
Processes in the Windows world
- What are the steps in creating a Windows Process? WFA gives a summary as:
- Open the executable and figure out what subsystem it needs to into. (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))
- Create an EProcess object. Set up a KProcess (kernel process block), the PEB (the process environment block), and an initial address space.
- Create the initial thread for the process.
- Alert the Windows subsystem as to this process.
- Begin execution of the initial thread.
Parsing processes
- WFA goes into long exegeses about the following Perl scripts: ptfinder.pl, lsproc.pl, lspd.pl, lspm.pl, and lspi.pl.
- ptfinder.pl by Andreas Schuster, which walks through memory trying to enumerate processes and threads from memory dumps.
- lsproc.pl by the author of WFA, Harlan Carvey, which similarly tries to enumerate processes (but not threads)
- lspd.pl also by Carvey, which allows you to list details of a particular process
- lspm.pl also by Carvey, which allows you to paste together the memory pages for a particular process from a dump. The author notes that this is particularly useful for matching found strings against the process they were found in.
- lspi.pl also by Carvey, lets you parse out the executable image. However, executables are not exactly the same each time since relocation information can interpolated into the excecutables, as well as other load-time and execution time information.
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.
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
- Don't forget: the mid-term is on Thursday. You are responsible for everything in chapters 1-3 of both texts, for anything in the notes or mentioned in class, and for the readings.
-
-
