Notifications
Clear all

Hash debate

13 Posts
10 Users
0 Likes
1,137 Views
bntrotter
(@bntrotter)
Posts: 63
Trusted Member
Topic starter
 

My agency has a little discussion going on over Hashes in EnCase. A colleague of mine just returned from a class and they informed him that EnCase hashes both the original evidence (verification hash) and hashes the acquired data (acquisition hash) during the Acquisition process.

My agency's training and procedures have us doing a straight up Hash process first upon connecting to the original evidence, and only then can we acquire the data into a forensic image and record the acquisition hash value.

From what I remember from my EnCase classes and my agency's training,
the Hash function of Encase is a straight up hash of the original evidence,
the Acquisition hash is the hash of acquired or copied data, and
the Verification process and hash strictly verifies the CRCs and double checks the hash of the acquired data.

If the Forensic Image E01 files were to be changed or corrupted, it would throw a CRC error, and the Verification Hash would be different from the Acquisition Hash.

Anyone want to clarify this debate or has an article on exactly what is being hashed during acquisition.

 
Posted : 14/01/2016 2:15 am
hydrocloricacid
(@hydrocloricacid)
Posts: 37
Eminent Member
 

Agree with that.

My only concern with encase hashing is that Encase logical acquisitions (.L01 files) don't create an acquisition hash upon acquisition.
Be nice if they followed AD FTKImager in creating an acquisition hash that can be verified.

 
Posted : 14/01/2016 3:49 am
tracedf
(@tracedf)
Posts: 169
Estimable Member
 

The acquisition hash is the hash of the original data and is calculated as the data is read from the source drive.

The verification hash is the hash of the data stored in the evidence file. The verification hash is calculated as soon as an evidence file is added to your case (usually right after creation).

There's no reason to hash the original drive, then acquire/hash, then verify. In doing so, you would be reading the entire source drive twice for no reason.

 
Posted : 14/01/2016 11:03 am
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

There's no reason to hash the original drive, then acquire/hash, then verify. In doing so, you would be reading the entire source drive twice for no reason.

Very much agree with this. You have to read a sector/block of data to hash it so once it's in memory you might as well write it out to an image.

The only reason I can think of to hash a disk before (or after) imaging is to check that the second pass returns exactly the same data. This may not be the case on an SSD device.

So if you want to carry out this extra step then my suggestion would be to image and hash the drive as step one and then re-hash the drive. This way if the device does return different data then the copy you have is the older data.

 
Posted : 14/01/2016 4:54 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

That would be (as usually is) "on-the-fly hashing", see
http//www.forensicfocus.com/Forums/viewtopic/t=10433/

If you "serialize it", as in

  1. hash source
  2. image source to target
  3. hash target
  4. compare hashes
  5. [/listo]

    besides the fact it will take more time, there is the issue about the risk of "damaging" the source while hashing.

    In a nutshell, when you are doing hashing by itself you need anyway to read a whole hard disk, which basically means to have it spin at top speed for a noticeable amount of time, of course this is what the hard disk is supposed to do while in operation, but you are essentially putting some stress on it BEFORE actually making a copy of it as opposed to putting some stress on it WHILE making a copy of it.

    It won't ever happen, but it is more probable that a problem in a hard disk may develop when using it than that a problem will be automatically resolved when using it.

    See also
    http//www.forensicfocus.com/Forums/viewtopic/t=11739/
    http//www.forensicfocus.com/Forums/viewtopic/p=6573219/#6573219

    jaclaz

 
Posted : 14/01/2016 6:21 pm
Bulldawg
(@bulldawg)
Posts: 190
Estimable Member
 

Like the others here, you're likely wasting your time by hashing first, then acquiring, then verifying the hash. There's no reason to hash first since hashing and acquiring both require reading the same data, just acquire and hash at the same time. This is what EnCase does and how it calculates the acquisition hash.

Also, something could go wrong with the hardware while you're hashing it, and you'll end up getting a damaged image once you finally acquire it. In the case of an SSD, your initial hash will almost never match the acquisition hash.

The EnCase verification hash is the re-calculated hash value of the evidence files. It is then compared to the acquisition hash, which is stored in the evidence files. During verification, EnCase also checks the CRCs.

 
Posted : 14/01/2016 6:48 pm
mlerner
(@mlerner)
Posts: 3
New Member
 

Hi,

I'm curious about the comments made here that a hash of an SSD drive will almost never match the hash of the evidence acquired from it.

Can somebody please explain why that would be? Although SSD drives and spinning platter drives store files very differently, to the OS they seem to store files in the same way (as far as partitions and file systems are concerned).

And what are the implications for forensics? Could the opposing side in a court case succeed in getting your report thrown out because you cannot show that the copy of the evidence that you worked on is identical to the souce drive?

Thanks,

Michael

 
Posted : 21/01/2016 8:51 pm
athulin
(@athulin)
Posts: 1144
Noble Member
 

Can somebody please explain why that would be?

On a magnetic hard drive, something written on a disk remains there until it is overwritten by something else (except for magnetic decay and such).

On a SSD, that is not necessarily true. Read the description of the ATA TRIM command (there's a similar SCSI command that I can't recall the name of just now). And put on your black hat, and come up with scenarios where correct implementation of TRIM will change the contents of the drive.

The question has been asked before – you can find earlier postings if you search.

Could the opposing side in a court case succeed in getting your report thrown out because you cannot show that the copy of the evidence that you worked on is identical to the souce drive?

Could? Yes. If they argue that a SSD works 100% like a magnetic HD. But then the present side has failed to oppose that claim, and explain how a SSD device really works.

A case contested by ignorants can end up any way at all.

 
Posted : 21/01/2016 9:13 pm
twjolson
(@twjolson)
Posts: 416
Reputable Member
 

Hi,

I'm curious about the comments made here that a hash of an SSD drive will almost never match the hash of the evidence acquired from it.

I wouldn't say almost never. I have yet to have a SSD NOT match. We don't get too many in here, but still.

 
Posted : 21/01/2016 9:34 pm
mlerner
(@mlerner)
Posts: 3
New Member
 

Thanks for the replies.

From what I understand about TRIM, the timing of TRIM execution is determined by the drive's firmware - the OS issues the TRIM command but the drive's controller determines when to run it.

So now I see why a hash of the source drive might not match the hash of the imaged copy - because the TRIM command might be executed *while* the imaging is taking place. However, if no TRIMming occurred during the imaging process, then the hashes should match.

Thanks,

-Michael

 
Posted : 21/01/2016 9:49 pm
Bulldawg
(@bulldawg)
Posts: 190
Estimable Member
 

Forensics Wiki (search for SSD)
Forensic Focus article

I've liked a couple pages that explain it better than I will here.

In essence, an SSD contains an on-board controller that can and will modify the SSD without interference from the OS. Because of the way NAND flash storage works, it is very slow to write to an already-occupied cell. To address this issue, the SSD–independent of the OS–will erase unused cells. All you have to do is apply power to the drive and evidence is being changed and even deleted.

 
Posted : 21/01/2016 10:27 pm
thefuf
(@thefuf)
Posts: 261
Reputable Member
 

Thanks for the replies.

From what I understand about TRIM, the timing of TRIM execution is determined by the drive's firmware - the OS issues the TRIM command but the drive's controller determines when to run it.

So now I see why a hash of the source drive might not match the hash of the imaged copy - because the TRIM command might be executed *while* the imaging is taking place. However, if no TRIMming occurred during the imaging process, then the hashes should match.

Thanks,

-Michael

You should distinguish between Trim and Garbage Collection. A solid-state drive may perform Garbage Collection even when there are no Trim commands coming from an operating system by parsing a file system and searching for unallocated data. Such a file-system-aware operation of a solid-state drive is the problem.

Unfortunately, there are several articles about solid-state drives and forensic issues which ignore this problem (because the authors never saw a file-system-aware solid state drive). However, file-system-aware solid-state drives exist, as stated by Kingston and by independent researchers.

Moreover, there are USB flash drives that will return different data when you read it. However, the last issue has nothing to do with Trim or Garbage Collection.

 
Posted : 22/01/2016 12:02 am
mlerner
(@mlerner)
Posts: 3
New Member
 

Wow. Thanks for those links. I am not (yet) a digital forensics practitioner, but I wasn't aware of garbage collection being initiated by an SSD in the absence of a direct command from the OS.

The concluding paragraph of one of the links you mentioned troubles me

"The results found in this paper may have significant implications for legal matters involving digital evidence, most especially in those cases where digital data is alleged to have been deleted intentionally or deliberately permanently wiped by a defendant. Given the pace of development in SSD memory and controller technology, and the increasingly proliferation of manufacturers, drives, and firmware versions, it will probably never be possible to remove or narrow this new grey area within the forensic and legal domain. It seems possible that the
golden age for forensic recovery and analysis of deleted data and deleted metadata may now be ending."

This issue, as well as increasingly-pervasive encryption, certainly doesn't bode well for the future of digital forensics. Both issues appear to me to be major stumbling blocks to performing a successful digital forensics exam.

 
Posted : 24/01/2016 4:51 pm
Share:
Share to...