Push the Red Button

When I first released the registry tools for Volatility , I discussed the possibility of interoperating with Harlan Carvey's excellent RegRipper . Now, thanks to Inline::Python and a bit of hackery, you can now run RegRipper against a memory image! Unfortunately, since Inline::Python only seems to work on Linux, you'll need to have a working Linux box around to use this (if anyone knows of a cross-platform way to use Python code from Perl, please let me know!). I'll get to the details of how this works later, but for now let's talk about how you actually use this stuff. First of all, since we depend on Inline::Python to manage the unholy union of Perl and Python, you'll need to get it from CPAN or your distribution's package manager. No need to install Parse::Win32Registry ; I've replaced it with my own registry code that will run against memory. Next, you should download the latest version of the registry tools [ tarball , zip ] (side note: I updated the...

Throughout our previous discussions of registry keys, hives, and so on, we have run into the concept of a cell index several times. They appear in kernel memory in places such as the KeyCell member of the _CM_KEY_CONTROL_BLOCK structure; likewise, all of the structures representing portions of the hive itself ( _CM_KEY_NODE , _CM_KEY_VALUE , and so on) have members that point to other structures by cell index rather than by virtual address. The reason for this is that registry hives live two lives: one, as on-disk files, stored in %WINDIR%\system32\config\ , and another, as an in-memory structure that the Configuration Manager uses in memory. In the former, cell indices can be thought of essentially as simple offsets from the start of the file; in the latter, however, the situation is more complicated. When registry hives are represented in memory, they must account for the fact that new keys and values may be added at any time. Since space for the hives is allocated out of paged po...

Last time , we found out how to find information about loaded registry hives in Windows memory dumps. However, just knowing what hives are loaded may not be particularly useful. To fill out our view of the state of the system's registry, we will also want to get information about registry keys currently open in the Configuration Manager. To start, though, we will need to know a little bit more about how the Configuration Manager represents keys in memory. Each open key is represented by a Key Control Block. Key Control Blocks, or KCBs, store a number of pieces of metadata about the key, such as the name, last write time, pointers to the cached values contained in the key (recall that the registry is essentially a filesystem, where keys act as folders and values are the files). To see precisely what information we can get about a key from its KCB, we can look at the _CM_KEY_CONTROL_BLOCK structure in Windbg: lkd> dt nt!_CM_KEY_CONTROL_BLOCK +0x000 RefCount : Uint2B ...

As I mentioned last week, I moved to a new apartment this week, and as a result I didn't have a lot of time to do any serious work. Still, I didn't want to let the entire week go to waste, so I decided to try and tackle a problem that I thought would be relatively simple: extracting a copy of the binary registry hives out of memory. As it turned out, this was actually a bit more difficult than I expected, and I'll have to get back to the problem at a later date, but I thought in the meantime I'd write about what steps I took, where I ran into trouble, and describe the approach I hope to take when I revisit the issue. There were several reasons to suspect that one might find at least partial copies of the registry in memory: the registry stores all of the configuration data for the Windows operating system, and its contents are referred to and updated quite often during normal operation (let Sysinternals' Regmon run for few minutes and look at the output if you hav...

I've just had my first paper accepted to a conference! The paper, titled The VAD Tree: A Process-Eye View of Physical Memory, describes how to use the Virtual Address Descriptor structure of the Windows kernel to do a variety of nifty things, including list DLLs loaded by the process and categorize a process's memory allocations into shared regions, mapped files, and private allocations. I'll be presenting it at the 7th annual Digital Forensics Research Workshop in Pittsburgh this August. Here's the abstract: This paper describes the use of the Virtual Address Descriptor (VAD) tree structure in Windows memory dumps to help guide forensic analysis of Windows memory. We describe how to locate and parse the structure, and show its value in breaking up physical memory into more manageable and semantically meaningful units than can be obtained by simply walking the page directory for the process. Several tools to display information about the VAD tree and dump the memory re...

Despite my earlier bold claims that I'd be doing more analysis of "Big Yellow," I'm going to have to renege for now. At work, we recently came across a user who was trying to connect to an external IP upwards of a thousand times per day; some investigation showed that his machine had been compromised by a trojan, and so we started in on incident response. This has left me with very little time to look at Big Yellow, but it did give me something new to write about--Windows memory forensics. Our first response was to get the user to run a cool little bundle that my friend Andy and I have been working on that collects as much forensically important information from the user's system as possible and uploads it to a server using Webjob . The package includes a bunch of Sysinternals tools, ftimes to get file hashes and search for specific strings, and a version of dd from the Forensic Acquisition Utilities that can dump physical memory. This last bit is what we'l...