Unallocated images

The file details would not necessarily be lost, as the records may still exist and be recovered from unallocated space (e.g. the EnCase recover folders feature)

A hash is simply a checksum produced from a section of data, so if the data is still in the same state as when it was deleted, the hash will be the same. When you say "lose the hash" what exactly do you mean, because to the best of my knowledge a hash of the file is not stored in its $MFT entry etc.

Cheers,

If a image is recovered from the unallocated area of a disk, does it retain its original hash sum that it had when it was in the live data?

If comparing two duplicate images, one being live, other from unallocated space, would the hash be the same?

If a image is recovered from the unallocated area of a disk, does it retain its original hash sum that it had when it was in the live data?

If comparing two duplicate images, one being live, other from unallocated space, would the hash be the same?

Yes.
As already said, the hash is just a form of checksum on the DATA..
Since a "deleted" file is NOT "deleted", only pointers to it are, the actual DATA is unmodified, and thus checksums remain the same.

jaclaz

Yes, as jaclaz says, with the obvious caveat that no bit has been overwritten or changed, and you're just hashing the exact same portion/length of data.

Excellent, thanks for that all.

One note, that takes off on Rich's caveat beware that different carving tools might give you the exact same image, but you'll get two different hash values because they handle how they carve, or more precisely, how they terminate the carving of a file, slightly differently.

One note, that takes off on Rich's caveat beware that different carving tools might give you the exact same image, but you'll get two different hash values because they handle how they carve, or more precisely, how they terminate the carving of a file, slightly differently.

That might be a good lab experiment with different files compression formats - is what you see what you get when the 0's and 1's add up to produce an image on screen even within in the same file extensions.

Obviously unallocated images have lost all usual file details etc, but would this include the hash value of that image? We have a disagreement in the office!

What file system are you telking about? Hashes are not static attributes of files in any file system I can think of. If you treat them as attributes, it's important to note that they are calculated attributes.

It depends on what level of assurance you are looking for.

And also, perhaps, how you define 'image'. It seems as if you use it as synonymous to file. However, if the file is 'deleted', it ceases to be a file there is no longer that ordered set of sectors/clusters that constitute a file, nor is there a size attribute that indicates what parts of these sectors/clusters that is well defined.

Indeed, once a file is deleted, no file system I know of makes any promise about the contents of the sectors/clusters that once made up that file and its directory entry. They could, in principle, be used for internal or temporary purposes. Indeed, some file systems may even zero the deleted blocks for security reasons.

Thus, you have to ensure that you have recovered the necessary pieces of data, and that they haven't been changed since they were deleted, before you are able to calculate the hash sum with any assurance that you are performing a worthwhile calculation. How do you do that?

Matching the recovered file against the hash you are trying to retrieve doesn't quite smell right, does it?