SSHD hash calculati...
 
Notifications
Clear all

SSHD hash calculation

6 Posts
6 Users
0 Likes
759 Views
SilesianMan
(@silesianman)
Posts: 15
Active Member
Topic starter
 

Hello everyone,

We all can agree that we must be aware that calculated hash value of a SSD drive will change without us altering data. (data flow, garbage collection, etc.). No problem here.

But, what about SSHD, the "hybrid drive", where we have e.g. 1000 GB of a HDD and 8 GB of SSD space. Does this tiny chunk of SSD memory chip the same things as "normal" SSDs?

Regards,
Karol

 
Posted : 27/09/2015 11:41 pm
MDCR
 MDCR
(@mdcr)
Posts: 376
Reputable Member
 

Does this tiny chunk of SSD memory chip the same things as "normal" SSDs?

I am leaning towards no. The Hybrid SSD-HDD combos i have seen are sold with the SSD part as a speed cache with MLC memory (in case of Seagate). There are probably exceptions to this rule varying with other manufacturers.

(There is probably also ways for users to hack and disable the cache and install the OS on that part and regular files on the regular HDD - would not surprise me a bit).

If your question really is Should i image it as a whole? My answer is Yes - if you can get to it, but i would suggest generating 3 separate hashes on 1) the whole drive, 2) the SSD partition (if it shows up as a partition and not a separate drive - or shows up at all) and 3) the HDD partition.

Even if it is a cache, if you could get to it - it could be valuable for your investigation.

 
Posted : 28/09/2015 5:12 am
(@mscotgrove)
Posts: 938
Prominent Member
 

I tend to agree with MDCR - the issue is imaging, rather than hashing.

My personal view is that hashing is often overrated - it just means that nothing has changed. A single bit change and the hash is different, even though the image is 99.9999% the same.

The big value of a hash is if you send your image to a third party. You can then be sure you are both working with the same data - the physical drive (by now) may be different.

 
Posted : 28/09/2015 6:09 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I agree fully with the above, but I would like to add something to introduce some elements of fear/uncertainty/doubt 😯 .

Before wear leveling, trim, garbage collection etc. the hashing was besides the (actually intended original reason for hashing/checksumming which was developed in the field of data transmission) verification of the integrity of the image when copies were made, a way to verify that the first imaging process did not introduce any change.
Once upon a time, when using a read-only OS and/or a write-blocker, you could make an image of a hard disk device (providing a hash during the "making"), you could check the hash of the image (after the "making") but you could also re-image the original a second time and obtain the same hash (i.e. indirectly verifying that the OS/tools used were actually read only or that the write blocker/adater/interface etc. were actually working correctly).
Now with these new devices/hardware you cannot anymore in some (probably most) cases. (

It would IMHO be beneficial starting to think to a (practical enough to be actually usable in real life) "better" or "more accurate" hashing method, as mentioned here (just for the OP interest)
http//www.forensicfocus.com/Forums/viewtopic/p=6577347/
http//www.forensicfocus.com/Forums/viewtopic/t=11739/

jaclaz

 
Posted : 28/09/2015 9:17 pm
(@athulin)
Posts: 1156
Noble Member
 

But, what about SSHD, the "hybrid drive", where we have e.g. 1000 GB of a HDD and 8 GB of SSD space. Does this tiny chunk of SSD memory chip the same things as "normal" SSDs?

Perhaps. Perhaps not, as it's unlikely to be used for a file system, but as an internal cache. So probably no TRIM, for example. The hd firmware can do any write levelling, and once a block has 'worn down', you don't have a non-working cache, but a cache that is just a little bit smaller than before. There could even be a number of reserve blocks left unused until 'wear down' has occurred, just to ensure MTBF ratings don't drop.

But unless you can access it in some way, it's unlikely to be of any use. But you can't can you? A normal SSD is sector addressable by the host computer. That cache SSD is not.

(Unless it is …)

 
Posted : 28/09/2015 10:39 pm
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

I tend to agree with MDCR - the issue is imaging, rather than hashing.

My personal view is that hashing is often overrated - it just means that nothing has changed. A single bit change and the hash is different, even though the image is 99.9999% the same.

The big value of a hash is if you send your image to a third party. You can then be sure you are both working with the same data - the physical drive (by now) may be different.

+1. Really the best that you can do if you know that you are dealing with a drive that will give a different hash value each time you do a full disk image is drill down a bit more if possible e.g. to partition level as mentioned or if none of these will give the same hash each time because it's all on solid state memory then what choice do you have but to log this all in your contemp notes and accept that this is how SSDs work?

If you need to send the data to another party, send them your image, the hash that you got, and explain that the only way to get the same hash value is to hash the image that you made, not the original source, for the reasons covered here. If you're in court you have your notes to back up what was done and why the hash values would differ. If you can't explain this to non-technical people (i.e. Judge/Jury) then you maybe shouldn't be stood up in court, and if there is an opposing expert who tries to undermine your work because of differing hash values, well… he or she is not much of an expert. So ultimately, where's the issue?

tl;dr SSD full disk hashes change over time. Understand the W questions around it and deal with it.

 
Posted : 29/09/2015 12:24 am
Share: