Saturday, July 14, 2007

Thoughts on RAM acquisition

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.

7 comments:

Anonymous said...

I'm starting to feel as though this is a conversation between only the two of us! :-) I, too, would like to hear from others.

Tool criteria include[sic]...

Not on point, but I have to suggest that the "[sic]" shouldn't have been added to the quote. There is no error in usage in the preceding phrase. I'm being anal, but that's part of what makes me suitable for our profession. Hey, blogs are kind of informal, anyway. I'll have to edit in Word and then paste!

My point was that RAM/live acquisition is relatively new to our community, and we must first be sure that what we acquire actually existed in RAM. Kind of like testing to be sure that File.txt in the image acquired by FTK Imager actually was on the drive. Basic, but essential, stuff.

As we've said, repeatability is an issue. We can't dump RAM twice to the same result. That's why I want to be sure that my tool accurately acquired what was there at the time. Again, I'll defer to your wisdom here, but maybe we can test a tool by starting the system, opening a Word file, (close it?), image RAM, and see whether and how much of the file is recovered. Do that with a variety of tools. Please criticize my idea if it's not valid. Too simplistic?

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

Yes. This is a given. We overwrote something (evidence?) in RAM and on the drive. It can be a no-win situation. Your opponent can argue that you destroyed evidence (in RAM) when you pulled the plug, without even doing a live acquisition. I can't wait for the other side to argue that I should have acquired RAM!

H. Carvey said...

I'm starting to feel as though this is a conversation between only the two of us!

But it is! I, too, would like to hear from others, but unfortunately, I don't believe that will be the case.

My point was that RAM/live acquisition is relatively new to our community, and we must first be sure that what we acquire actually existed in RAM.

As you say, basic stuff, but also relatively simple, don't you think? I mean, wouldn't we simply need to work with the author of the tool? I mean, how would one run tests of this?

Too simplistic?

No, not at all, but I am curious as to your reasoning that such a test will show that our acquisition method did not add something to the data we collected. Or is that not the point?

I do think data carving of RAM is entirely possible...after all, at a very basic level, it's not entirely different from unallocated space, is it? One major difference is block size, but that can be addressed via the tool.

This is a given. We overwrote something (evidence?) in RAM and on the drive.

I agree that "something" gets overwritten, and because it is overwritten by our acquisition method, we cannot see what it was. However, I was asking about overwriting evidence, exculpatory or otherwise. If the data collected reveals a significant amount of evidence, why can't it be used?

Take the Trojan Defense for example. When you collect the contents of physical memory, active process information is not overwritten. Therefore, if you do not find the existence of a Trojan running in active memory, and you can't locate any evidence of a Trojan residing on the hard drive, then what is the likelihood that you overwrote something that showed that there was, in fact, a Trojan running in active memory at the time that it was acquired?

It can be a no-win situation.

Perhaps...perhaps not.

Your opponent can argue that you destroyed evidence (in RAM) when you pulled the plug, without even doing a live acquisition.

I think that's the tarpit that many in the community are getting stuck in...your opponent (re: the defense) can argue anything, and potentially say anything. However, really think that what's being missed is this...no case hangs on a single piece of evidence, particularly if it's "new", untried, or dubious. I strongly doubt that if a prosecutor had case that went to trial, he or she would hang that case on a single string (potential password) found in a memory dump.

While it is possible your opponent could say or argue just about anything, with the right work done before hand, I don't see why something like RAM acquisition could not be used in court. Say, if a law enforcement officer (or someone acting as an agent for, or "under color of" the law) determined, based on her training, that it was pertinent to collect the contents of RAM, and she did so using accepted "best practices", then why couldn't that be used in court? After all, wouldn't it also be part of discovery? Wouldn't the defense have an opportunity to review the documentation on the collection method, as well as the data itself?

I really think too many within the community are getting themselves bogged down in ifs, thens, and maybes...sorry, just my opinion.

Anonymous said...

Well, I guess I'll carry on our one-on-one discussion! At least I'll respond to you questions.

...I am curious as to your reasoning that such a test will show that our acquisition method did not add something to the data we collected. Or is that not the point?

You're inference is correct, as that will not prove that we didn't add something. It may show that the tool collected data that we new was in memory. So, the tool works; it gathered the data that we knew was in RAM. It may be more complex to determine whether our tool acquired everything in memory. Maybe I'm overly anxious about this. Would a tool have gathered everything if it acquired a dump of 4,294,967,296 bytes of 4GB of RAM? (There will be some blocks of memory that will/can not be acquired.)

I'm not sure that there's much to prove, insofar as advancing a position that we didn't add what we're offering as evidence. You have to narrow down your case objective. If I offer text from a Word file that I found in RAM, I should be able to state that I didn't palce the text there, if I folowed the most basic of forensic procedures, which are more critical in any facet of live acquisition. The text was not on my media nor created with my tool, so it didn't come from my stuff.

I agree that I could offer RAM-acquired evdience tomorrow, given that I would have tested my tool today and approached the case using commom sense. I also concur in your suggestion about bogging ourselves down, and I hoped to have implied that thought when I offered my opinion that we tend to beat ouselves up too much.

H. Carvey said...

It may be more complex to determine whether our tool acquired everything in memory.

Not necessarily. We know that Garner's dd.exe didn't get everything in memory from an XP system...but we also know why.

It's a matter of "best evidence". What is the process? Have the tools been tested and accepted? Can the responder justify his/her actions to collect physical memory, and can they explain what they found? Do they have thorough documentation?

..if I folowed[sic] the most basic of forensic procedures...

This is exactly right. In a murder investigation, how do we know that blood wasn't added to the scene? Or that a spent shell casing wasn't added to the evidence?

As for bogging ourselves down, I think that we're at a point where there are only a few willing/able to advance this area of study...we may not yet be at point where we have "critical mass" to move it forward, but I do think that we have enough interest in the topic that there is a need to show some improvement or advancement in what can be derived from a memory dump, as well as tools that can be used to retrieve it. I also see the need for some education (white paper, presentation, etc.) in order to bring all of those who are interested up to speed...

Unknown said...

I have just come across this thread and agree with both Jimmy and Harlan. I have more of a legal background than a technical one. While not from your legal jurisdiction, I struggle to see how a live acquisition would be inadmissible if validated forensic procedures were followed.

With the risk of flogging a dead horse....

Given that we are often talking about electronic documents,perhaps we should liken this issue to the seizure of a paper document found at a crime scene. The seizing officer finds a document at the scene. To find it he/she may have opened a filing cabinet (wearing gloves hopefully) and searched through the files. When he/she finds a relevant document he will remove it and photograph it, before placing it in a container of some description.

In handling the document carefully, he/she may add foreign material (hair, skin, sweat, powder from the gloves) and sometimes inadvertently destroy evidence (such as smudging fingerprints). The photograph he took was not an exact reproduction of the place where the document was found (Inside the filing cabinet) and would be difficult (if not impossible) to reproduce at a later date after the investigators have left the crime scene.

The document is then taken to the forensics laboratory. The Lab may recover boilogical material (including the investigators) and in examining the material destroy or alter it. The fingerprint examiner may soak the document in Ninhydrin; which will turn it pink and may cause the writing to run.

All these processes change the document, but documents subject to this process are admitted to courts around the world on a daily basis.

If the "standards" currently applied to digital forensics were applied to other branches of forensic science no physical evidence would be admitted.

I think the question to ask is, "Has the evidence gathering process used made the evidence I am seeking to have admitted unreliable?"

I've hand enough ranting for one day.

A Buffet-Lynch student said...

Maybe this is too late to add to this thread. But I would like to add few things...
When the investigator is about to investigate a live system, it may be very likely that the crime has not yet been proved. This can be typical example of internal threat within an organization. Investigator may not be able to collect enough data to prove the crime. But management wants her/him to investigate. Here, the subject being investigated may in return file suit against investigator or the employer, for compromise of her/his private information. This is quite a tricky situation...
It would be hard to draw guidelines for such situations?

H. Carvey said...

> When the investigator is about to
> investigate a live system, it may
> be very likely that the crime has
> not yet been proved.

This is true...and this is why an investigator "investigates"...because, as you've stated, a crime has not yet been proved. In order to prove that a crime has been committed and in order to identify who committed it, one needs to investigate.

> Investigator may not be able to
> collect enough data to prove the
> crime. But management wants
> her/him to investigate. Here, the
> subject being investigated may in
> return file suit against
> investigator or the employer, for
> compromise of her/his private
> information.

Most companies within the US *should* have an acceptable use policy, as well as documents that an employee signs when they're in HR, indicating that they understand things such as "consent to monitoring".

Besides that, storing private information on your employer's computer systems just is not a good practice to get into.

> It would be hard to draw
> guidelines for such situations?

Not at all. To be honest I really don't see where the issue is at all.