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.
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.