MD5/SHA of volatile data

We do frequently collect volatile data for various cases, but more often than not do not hash this data (I'm referring to malware investigations, botnets etc). However, if we are collecting live data from systems that we know may end up as evidence (an example is the collection of RAM from a suspected encrypted system), then we would likely hash this. We also sometimes take screenshots of live illegal web activity (as shown on the display) and would normally hash the images immediately as a safeguard.

Trouble is (and I guess this is the point of your question) who is to say that we haven't injected some incriminating data in the file and then hashed it? For this reason, we do the hashing contemporaneously and either record it immediately in the handwritten log of events at the time, or as an alternative, we do have access to Wetstone's time-stamping service (if Internet access is available) which is a quite effective method. We've never had to use that in court though so far…

Ultimately though, it pretty much comes down to the integrity of the examiner. Just like at a physical crime scene, with volatile data you could argue that there is an opportunity to "plant" evidence. However, if anyone tried that argument in legal proceedings they'd better have good grounds for doubting the integrity of the one doing the analysis!!

Jonathan,

if you do not hash the volatile data while it is imaged, how can you prove at a later date it hasn't been altered?

I would say hash regardless. At least then as the examiner, you are able to prove you have not altered the evidence.

Thanks for the replies.

Andy - hashing would be useful if you are later going to make copies of the volatile data for other people to look at, as it would ensure that you are all looking at the same thing. What it doesn't do, IMHO, is to prove that it is an exact copy of the 'orginal' data from the suspect machine, as by it's nature volatile data can change by the second so you do not have an 'orginal' to go back and compare the hash to. (Unlike when you have a hard drive whose power has been pulled.)

I think I agree with phius's view - in order to show the authenticity of your extracted volatile data it's down to processes and integrity.

> What it doesn't do, IMHO, is to prove that it is an exact copy of
> the 'orginal' data from the suspect machine, as by it's nature
> volatile data can change by the second so you do not have an
> 'orginal' to go back and compare the hash to.<

It is a popular misconception that hashes are able to establish the accuracy of a forensic acquisition. At best you can show that two acquisitions are consistent; but they might be consistently erroneous (due to errors in the drive firmware, errors in the os, etc.) Hashes are useful for establishing chain of custody. Their value is no different for volatile vs. non-volatile evidence.

&gt; What it doesn't do, IMHO, is to prove that it is an exact copy of
&gt; the 'orginal' data from the suspect machine, as by it's nature
&gt; volatile data can change by the second so you do not have an
&gt; 'orginal' to go back and compare the hash to.&lt;

It is a popular misconception that hashes are able to establish the accuracy of a forensic acquisition. At best you can show that two acquisitions are consistent; but they might be consistently erroneous (due to errors in the drive firmware, errors in the os, etc.) Hashes are useful for establishing chain of custody. Their value is no different for volatile vs. non-volatile evidence.

Hmmmm…with non-volatile acquisitions you compute the hash value of a file/folder/volume or drive. Then you acquire it. Then you hash your acquisition - enabling comparison to the original; something which isn't possible with volatile acquisitions.

Heya,

In that job that you know about, I hashed the live data aquired, not so much for being able to confirm the image, like you say that isn't really possible* but for the fact that when I made a working copy from the USB drive used for the aquisiton I _could_ verify the working copy was identical to the aquired copy. The tools that were used automagically made the sums in any case, so it wasn't exactly a problem -)

Azrael

* well, it is provided that nothing happens to the file/folder/volume or drive during the process … Something the probability of which decreases rapidly the further along that list you move …

> Hmmmm…with non-volatile acquisitions you compute the
> hash value of a file/folder/volume or drive. Then you acquire
> it. Then you hash your acquisition - enabling comparison to the
> original; something which isn't possible with volatile
> acquisitions. <

No doubt. But what have you proved by this process? Suppose, for example, you acquired the drive on Linux using a version of DD that is susceptible to the problem reported by Barry Grundy. http//tech.groups.yahoo.com/group/ForensicAnalysis/message/82; http//tech.groups.yahoo.com/group/ForensicAnalysis/message/83. Supposing also that the hashing program (md5sum?) is susceptible to the same problem. The hashes would be the same but the image inaccurate. Similarly, you might have used a commercial imaging tool that relies on the drive's statement of its capacity (which is not always accurate). Then there are drives that are failing, which consistently may yield the same inaccurate data. Consistency and accuracy are not the same.

The examples you give of erroneous hashes being produced due to mechanical errors, amateurish imaging techniques or imaging application shortcomings doesn't take away the value of hashing non-volatile data in the vast majority of cases where such conditions don't exist – that is, both proving the accuracy of the image in relation to the original as well as showing the consistency of the image.

Which to return to my first post in the thread can't be done with volatile data!