Andreas has posted a couple of new Volatility plugins recently that look really interesting, in that he provided the capability to link file objects to processes, as well as scanning a memory dump for driver objects.

It's been a while since I've blogged on memory analysis, I know. This is in part due to my work schedule, but it also has a bit to do with how things have apparently cooled off in this area...there just doesn't seem to be the flurry of activity that there was in the past...

However, I could be wrong on that. I had received an email from someone telling me that certain tools mentioned in my book were not available (of those mentioned...nc.exe, BinText, and pmdump.exe, only BinText seems to be no longer available via the FoundStone site), so I began looking around to see if this was, in fact, the case. While looking for pmdump.exe, I noticed that Arne had released a tool called memimager.exe recently, which allows you to dump the contents of RAM using the NtSystemDebugControl API. I downloaded memimager.exe and ran it on my XP SP2 system, and then ran lsproc.pl (a modified version of my lsproc.pl for Windows 2000 systems) against it and found:

0 0 Idle
408 2860 cmd.exe
2860 3052 memimager.exe
408 3608 firefox.exe
408 120 aim6.exe
408 3576 realsched.exe
120 192 aolsoftware.exe(x)
1144 3904 svchost.exe
408 2768 hqtray.exe
408 1744 WLTRAY.EXE
408 2696 stsystra.exe
244 408 explorer.exe

Look familiar? Sure it does, albeit the above is only an extract of the output. Memimager.exe appears to work very similar to the older version of George M. Garner, Jr's dd.exe (the one that accessed the PhysicalMemory object), particularly where areas of memory that could not be read were filled with 0's. I haven't tried memimager on a Windows 2003 (no SPs) system yet. However, it is important to note that Nigilant32 from Agile Risk Management is the only other freely available tool that I'm aware of that will allow you to dump the contents of PhysicalMemory from pre-Win2K3SP1 systems...it's included with Helix, but if you're a consultant thinking about using it, be sure to read the license agreement. If you're running Nigilant32 from the Helix CD, the AgileRM license agreement applies.

I also wanted to followup and see what AAron's been up to over at Volatile Systems...his Volatility Framework is extremely promising! From there, I went to check out his blog, and saw a couple of interesting posts and links. AAron is definitely one to watch in this area of study, and he's coming out with some really innovative tools.

One of the links on AAron's blog went to something called "Push the Red Button"...this apparently isn't the same RedButton from MWC, Inc. (the RedButton GUI is visible in fig 2-5 on page 50 of my first book...you can download your own copy of the "old skool" RedButton to play with), but is very interesting. One blogpost that caught my eye had to do with carving Registry hive files from memory dumps. I've looked at this recently, albeit from a different perspective...I've written code to locate Registry keys, values, and Event Log records in memory dumps. The code is very alpha at this point, but what I've found appears fairly promising. Running such code across an entire memory dump doesn't provide a great deal of context for your data, so I would strongly suggest first extracting the contents of process memory (perhaps using lspm.pl, found on the DVD with my book), or using a tool such as pmdump.exe to extract the process memory itself during incident response activities. Other tools of note for more general file carving include Scalpel and Foremost.

So...more than anything else, it looks like it's getting to be a good time to update processes and tools. I mentioned an upcoming speaking engagement earlier, and I'm sure that there will be other opportunities to speak on Windows memory analysis in the future.

Andreas recently released a new tool called poolgrep.pl. This lets you run searches across memory pools, looking for things such as timestamps, IP addresses, etc. You need to start by using poolfinder.pl to develop an index, and from there you can search through various pools for specific items.

This is definitely a start in the right direction. As Andreas has pointed out, the pool header contains a size value, so we know how many bytes the pool occupies. He has also shown that some pool contents can reveal network connections. From here, IMHO, we should focus on "interesting" pooltags, and attempt to understand their structure. Once we do, then this can be added to tools such as poolfinder.pl, and the data parsed and presented accordingly. In addition to network connections, for example, the contents of the clipboard (pool tag = Uscb) may be interesting, as well. MS provides a listing of pooltags in the pooltags.txt file that's part of the Debugger Tools. You can see an online version of the file here.

Also, there's been an update to the SANS ISC Malware Analysis: Tools of the Trade toolkit listing...and it looks like I'd better get cracking on finishing up the tools I've been putting together to address not just Windows 2000 RAM dumps! ;-)

I received an email from Andreas today, and one of the things he mentioned is that the offset for the Vista kernel in memory is 0x81800000...this could be added to my os detection script. So I made the change to my script and ran it against a memory dump that I had from a Vista machine. Nothing. Nada. No impact, no idea. I opened up the memory dump in UltraEdit and saw that there was nothing at the offset...well, at least no PE header.

I then fired up my Vista RC1 VMWare session, and ran LiveKD to see what it reported the kernel base address as (0x81800000), and then I suspended the session. I opened up the resulting .vmem file and ran the script against it...and saw the following:

File Description : NT Kernel & System
File Version : 6.0.5600.16384 (vista_rc1.060829-2230)
Internal Name : ntkrpamp.exe
Original File Name :
Product Name : Microsoft« Windows« Operating System
Product Version : 6.0.5600.16384
File Description : Boot Man╕╝ ç(╝ ç
File Version : 6.0.5600.16384╜ çp╝ çsta_rc1.060829-2230)
Internal Name :
Original File Name :
Product Name : Microsoft« Winh╛ ç╪╜ ç« Operating System
Product Version :

Very cool. To make this change yourself, just add '0x81800000 => "VistaRC1"' to the %kb hash.

Addendum 24 Oct: Sent by Andreas, and confirmed this morning...add '0x82000000 => "VistaBeta2"' (remove outer single quotes) to the %kb hash in kern.pl.

Andreas released his poolfinder tool the other day, a Perl script for locating pool tags in a memory dump. This script accompanies a paper he wrote for IMF 2006 (here's his paper from DFRWS 2006).

So, what's a pool tag, and why is it important? According to Andreas, the kernel allocates what's referred to as a "pool" of memory, so that if an application requests some memory that is less than a 4K page, rather than wasting all of that space, only what is required will be allocated. The pool tag header is a way of keeping track of this pool.

The pool header specifies the size of the pool, but there isn't any publicly available method for parsing that pool into something usable. I've used this technique to locate the contents of the Clipboard in the DFRWS 2005 memory challenge dumps, and Andreas has used this to locate network socket activity. Perhaps someone with experience in developing drivers for Windows can assist in developing a methodology for revealing the format of the various structures.

Additional Resources:
Who's using the pool?
How to use PoolMon.exe

Addendum, 23 Oct: I've made some comments to Andreas's blog, and we've gone back and forth a bit. What I'd like to try to do is identify various pool tags that are of interest to forensic examiners (ie, TCPA for network connections, clipboard, etc.). Thanks to Andreas's work, finding the pool tags and their sizes is relatively easy...deciphering them into something readable is something else entirely.