• It is useful to operators that want all traces of the server to disappear on powerdown. This includes the private SSL keys which can be housed externally.
• The environment can be hardened in a manner specific to the limited needs of Tor.
• It has the usual speed advantages of diskless systems and can run on older hardware.

As a follow-on to my previous post regarding OMFW, there have been some developments in the area of memory dumping and parsing (ie, collection and analysis) that have occurred over the past couple of months.

Lance Mueller posted on the new standalone memory dumping tool that is part of EnCase 6.11. Interesting tool as it apparently dumps the contents of physical memory from Windows (Windows 2000 through Vista) to an EnCase .E0x file format, for inclusion in a case. According to the documentation, there's functionality to extract that memory dump from the .E0x file format to something usable by HBGary's Responder product. Note: Initial testing indicates that FTK Imager will successfully convert the resulting .E0x files to a dd-style format for use with other tools.

Jesse Kornblum referred mdd to me. This one looks promising...captures memory from Windows versions through Vista and 2008. Jesse posted some clarifications about this tool on his blog. As it stands, this appears to be the first free tool to dump RAM from Windows 2000 through 2008, inclusive, in a dd-style format. Note: Updated version 1.1 was released on 17 June.

So available tools for collecting the contents of physical memory are becoming more available. From an analysis standpoint, I really think that you want to keep your eyes on the guys over at Volatility Systems, though.

Addendum: win32dd is available from Matthieu Suiche. I just found out about this so I haven't had an opportunity to try it...but I am looking forward to adding it to the list of tools to test!

Andreas blogs on the new tools...great stuff, very comprehensive view of where this all stands at the moment.

There are some interesting events coming up this summer (and beyond) that I wanted to point out to folks...

DFRWS is this summer (11-13 Aug), but the Open Memory Forensics Workshop (OMFW) will be held just prior (info here, update here). OMFW looks like a great opportunity...it's a half-day event, but looking at the list of speakers and panelists...wow! If you haven't already, grab books off of your bookshelf (I *know* most of you recognize author names...) and get your copies signed! OMFW is brought to you by the letters M and S, and these guys.

If anything, this really shows how the interest in analysis of physical memory is really picking up. More than anything, I'd have to say that the interest is really been driven by the guys over at Volatile Systems, along with a host of other names. There is a great deal of extremely valuable information available in physical memory (RAM), and these guys are leading the way in showing us what's there, and providing tools for getting at it and making it available, but more importantly, useful to analysts.

As a side note, if you look around the community/industry, there is a big piece that's missing right now...collection. That's right...there are open source and commercial tools (from Mandiant and HBGary...and HBGary is apparently partnering with GSI) that provide the ability to parse, comb through and analyze a physical memory dump, but very few that provide the ability to extract the contents of RAM from Windows 2003 SP1 and above (e.g., Vista, Win2K8) systems. I even received an email from a friend at MS yesterday asking me if I knew of any such tools. One would naturally assume that we'd eventually see such a tool from MS/SysInternals. One way to go about changing this...buy more F-Response!

Note: Paraben is having an Innovations Conference in Utah in Nov, 2008. They also let you vote for a company or product that you feel is most innovative for 2008...I voted for F-Response.

Okay, back on track...what was I talking about? Oh, yeah...

Looking at the program for DFRWS 2008...yet another impressive line-up. I'm hoping to go...working for a large corporate (think "glacial") entity (think Borg cube), these requests are always in limbo. However, I'm very interested in Timothy Morgan's talk, as well as a couple of others. It also looks as if some of the speakers from OMFW are going to be on deck for DFRWS, as well. Maybe a good opportunity to ply familiar faces and famous names with some of the locally brewed beverages.

Interestingly enough, the local RCFG conference (which overlaps with DFRWS this year) has been cancelled. That's too bad...this conference is held on the GMU campus and for the most part is a nice, smaller conference. However, with the right leadership, it has the potential to really be a premier conference...not just for local LE, but in general. In fact, an interesting thought would be that since some folks are going to be in the area anyway, talking about the same topic...

Also, in Jan 2009, there is the DoD CyberCrime Conference...Jesse mentioned the CfP here. It's too early to list the speakers, but I had an opportunity to visit the conference in 2007 and it was a good one...lots of attendees, lots of events, lots of really great speakers.

The Scientific Working Group on Digital Evidence (SWGDE) has released some new documents, the most notable of which are the Vista Technical Notes, and the document on "Live Capture".

The document on Live Capture was very interesting! At only 5 pages in length (the first page is formal disclaimer stuff...), there isn't a whole lot of detail, and the timeliness of the document may be questionable, but the point is that the document does reference the benefits of performing "live capture"...a term which encompasses three different activities. The document spends only a small paragraph discussing RAM dumps, and in that paragraph refers to "DD" as a software tool that can be used for collecting the contents of memory...on Windows systems, this is no longer the case (unless you have an old copy of the version of dd.exe sitting around). Further, this article in the Forensic Magazine mentions the use of dcfldd (version 1.3.4 was reportedly used when writing the article) to dump RAM from a Windows system...however, the command line listed in the article no longer seems to work (although for some odd reason, on a Windows XP SP2 system, replacing "\\.\PhysicalMemory" with "/dev/mem" seems to get something). Oddly enough, the document doesn't mention ProDiscover (which had the ability to collect RAM and volatile data before EnCase), nor does it mention Nigilant32.

The section of the document that addresses live acquisition is also extremely short and bereft of any real content...I'd love to know what "careful planning" they are referring to, just as I'm sure others reading the document who've never done a live acquisition must be wondering.

But hey...don't get me wrong...I think it's a great thing that the document is out. The more these techniques and methodologies are discussed and presented, the more likely they are to be used and then become part of standard procedures.

As a follow-on to the tool testing posts, I wanted to throw something else out there...specifically, I'll start with a comment I received, which said, in part:

Tool criteria include[sic] whether the data the tool has acquired actually existed.

This is a slightly different view of RAM acquisition (or "memory dumping") than I've seen before...perhaps the most common question/concern is more along the lines of, does exculpatory evidence get overwritten?

One of the issues here is that unlike a post-mortem acquisition of a hard drive (ie, the traditional "hook the drive up to a write-blocker, etc."), when acquiring or dumping RAM, one cannot use the same method and obtain the same results...reproduceability is an issue. Because you're acquiring the contents of physical memory from a running system, at any given point in time, something will be changing; processes process, threads execute, network connections time out, etc. So, similar to the live acquisition of a hard drive, you're going to have differences (remember, one of the aspects of cryptographic hash algorithms such as MD5 is that flipping a single bit will produce a different hash). I would suggest that the approach we should take to this is to accept it and document it.

That being said, what are some of the questions that we can anticipate addressing, and how would/should we answer them? I'll take a stab at a couple of basic questions (and responses), but I'd really like to see what others have to say:

1. Did you acquire this data using an accepted, validated process?

In order to respond to this question, we need to develop a process, in such a way as to validate it, and get it "accepted". Don't ask me by whom at this point...that's something we'll need to work on.

2. Did this process overwrite evidence, exculpatory or otherwise?

I really think that determining this is part of the validation process. In order to best answer this question, we have to look at the process that is used...are we using third-party software to do this, or are we using some other method? How does that method or process affect or impact the system we're working with?

3. Was this process subverted by malware running on the system?

This needs to be part of the validation process, as well, but also part of our analysis of the data we retrieved.

4. Did you add anything to this data once you had collected it, or modify it in any way?

This particular question is not so much a technical question (though we do have to determine if our tools impact the output file in anyway) as it is a question for the responder or examiner.

As you can see, there's still a great deal of work to be done. However, please don't think for an instant that I'm suggesting that acquiring the contents of physical memory is the be-all and end-all of forensic analysis. It's a tool...a tool that when properly used can produce some very valuable results.

Ever wondered what the legal definition of "RAM" is? I was perusing the Computer Forensics and Incident Response blog this morning and found an interesting post regarding RAM and the US Courts. In short, a court document (judge's decision) from the case of Columbia Pictures Industries, et al, vs Justin Bunneli, et al, was posted on the web, and contains some interesting discussion regarding RAM.

In short, the document illustrates a discussion in which RAM constitutes "electronically stored information", and can be included in discovery. The document contains statement such as "...Server Log Data is temporarily stored in RAM and constitutes a document...".

Interestingly enough, there is also discussion of "sploilation of evidence" due to the defendant's failure to preserve/retain RAM.

The defendants claimed that, in part, they could not produce the server log data from RAM due to burden of cost...which the judge's decision states that they failed to demonstrate. There are some interesting notes that address issues of RAM as "electronically stored information" from which key data would otherwise not be available (ie, the document states that the server's logging function was not enabled, but the requests themselves were stored in RAM).

Ultimately, the judge denied the plaintiff's request for evidentary sanctions due to the defendant's failure to preserve the contents of RAM, partially due to a lack of prior precedence and a specific request to preserve RAM (the request was for documents).

The PDF document is 36 pages long, and well worth a read. I will not attempt to interpret a legal document here...I simply find the judge's decision that yes, RAM constitutes electronically stored information, however temporary, to be very interesting.

What are your thoughts? How do you think this kind of issue will fare given that there are no longer any freely available tools for dumping the contents of Physical Memory from Windows systems?

Addendum: An appeal brief has been posted by the defendant's lawyers.

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 posted this on his blog, and I took a look at it...very cool. This is a front-end for running PTFinder, and even allows you to choose which operating system you want to run it against. This makes things a little easier to use.

If you have a RAM dump and don't remember which OS it is, as long as it's between Win2k and Win2K3SP1, you can use my OS detection script.

The neat thing is that you can get output that looks like this. Very cool!