CHANGE OF HASH SHA ...
 
Notifications
Clear all

CHANGE OF HASH SHA 256

7 Posts
4 Users
0 Likes
1,243 Views
(@krishna)
Posts: 45
Eminent Member
Topic starter
 

Hello Friends,

I had an issue with reference to hard disk image hash value of SHA256. The problem is the laptop hard disk (magnetic media) was imaged using SOLO4 and generated a hash of SHA256 by LEA at crime scene. (assume this hash as hash I)

subsequently the original hard disk was sent to laboratory for further analysis. the laboratory personnel again imaged the same original disk with Logicube Falcon and generated the hash of SHA256. (assume this hash as hash II). now on comparison, the Hash I and Hash II are not being matched with each other.

the hash value is calculated on the same original hard disk by SOLO4 again. (assume this hash as hash III). this hash III is matching with hash II, but not with the hash I.

subsequently various devices are used to calculate the hashes, but no hash is matching with the original hash I, but all of them are matching with Hash II and hash III. i hope i am clear in pointing out the issue.

now the problem is why there is a change in the hash value, what could be the probable reasons for this change in the hash value. what are the probable environments where such changes are possible.

pl give me suggestions and advises to report the matter soon.

thanks in advance, waiting for positive responses,
krishna m

 
Posted : 24/12/2016 1:41 pm
(@athulin)
Posts: 1156
Noble Member
 

now the problem is why there is a change in the hash value, what could be the probable reasons for this change in the hash value. what are the probable environments where such changes are possible.

Were hash I and hash III produced by the same device, i.e. same physical device, same cables, same everything? If they were, fine; if not, there scope for additional investigation into differences between those devices.

Were any logs kept from the acquiry? That is, citing nr of bad sectors or other problems?

Were SMART parameters logged? That is, nr of power cycles, etc. ? That could also help identify possible causes for a change.

As hash II and hash III are the same, differences in SHA-256 implementation can probably be discounted.

Were hash I and hash III done in exactly the same manner? That is, if there is scope for personal variation (other connectors, other configuration, treatment of bad sectors, etc…) that might be a possible explanation.

But if such variations can be ruled out, the content of the device clearly changed between hashing I and hashing II.

Hypothesis natural cause extra bad sectors developed due to mishandling or normal magnetic decay or the odd cosmic ray or whatever else.

Hypothesis other cause someone decided to take a look at the disk, and simply made a modification, deliberate or not.

If image I and image II/III has been preserved (which they should have been), it's easy to make additional test just do a sector-by-sector comparison. Any mismatches will identify the changed sectors.

Any explanation as to why the changes occurred will naturally have to take all such additional data into account. Was one single sector changed, or a contiguous sequence of sectors, or random sectors all over the disk? Are all changes in one area of the disk (say, one one platter?) Are all changes of file data or metadata? … and so on.

 
Posted : 24/12/2016 3:44 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I am not sure to understand the issue.

As Athulin stated, if you have "Hash I" you also have "Image I".
Then you have"Hash II" and also "Image II", and "Hash III" and "Image III".

Simply make a byte-by-byte comparison of "Image I" against "Image II" and find what differences there are.

Depending on the actual differences found, some hypothesis can be formulated on the reason that caused the changes.

If there are no differences between the digital images, it is *somehow* a glitch in the SOLO4 thingie (regarding the hashing but not the copy), if there are differences, it may be a defective sector, a remapped one, etc. on the actual disk.

A common "conceptual mistake" is to believe that the disk is actually imaged "physically", a modern disk is more like a "living thing" 😯 more than anything else it is a "black box" that you access through the onboard electronics (in itself a computer with an own OS).

jaclaz

 
Posted : 24/12/2016 6:54 pm
(@thefuf)
Posts: 262
Reputable Member
 

There are several possible answers
1. someone intentionally modified the original evidence;
2. someone unintentionally modified the original evidence;
3. a new bad (unreadable) sector (or multiple bad sectors) appeared on the drive;
4. there was a bad sector on the drive before the first image was taken by LE, and you are using a different error granularity (you are getting a different number of sectors replaced with null bytes in an image);
5. the same as above, but an adapter or a drive enclosure was used by LE (these devices affect the error granularity).

If you have the original image taken by LE, simply compare it to the image acquired by you (use vbindiff or a similar tool).

If no original image is available, try to find modified data build a timeline, look at the contents of the $LogFile (NTFS), look at timestamps in a file system superblock (Ext3/4 and so on). If there are bad sectors, try to play with a different error granularity (Linux)

dd if=/dev/<device name> bs=<block size> iflag=direct conv=sync,noerror | sha256sum
Try different values of the <block size> parameter 512, 1024, 2048, 4096, 8192, and so on. However, it could be better to write a script and simulate a different error granularity by writing null bytes to the image (so you won't wear down the suspect drive).

Also, ask LE guys about their actions. May be there was something obvious they did that changed the original evidence. And compare the firmware version numbers (I have seen a piece of forensic hardware that reports a single bad sector when a single bad sector was encountered on a suspect drive, and the same product with a different firmware version that reports 128 bad sectors when a single bad sector was encountered on the same drive).

If the problem is extremely critical, get the Solo-4 device used by LE, and examine its system logs for signs of writes to the original evidence. I have seen a competing product (validated by NIST, of course) writing to a suspect drive (connected to a write-blocked port, of course) with traces left in system logs (but I never used Solo-4 devices, so I can't tell anything about possible modifications to a suspect drive when an examiner, for example, is using that device to preview a file system after an acquisition).

Can you also provide additional details about partitions and file systems found in the image?

 
Posted : 24/12/2016 10:16 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I may be grumpy BUT

If no original image is available, …

… immediately suggest the people involved in the acquisition to find a new job. 😯
wink

jaclaz

 
Posted : 24/12/2016 10:58 pm
(@krishna)
Posts: 45
Eminent Member
Topic starter
 

thank u very much for all the suggestions and quick response.

as required i just wanted to give further details about the disk. the system has a windows 8 pro OS, the disk consists of EFI system partition (ESP)with FAT32 and NTFS file system.
the sector count in all the images is same i.e 1953525168.

waiting for further inputs in this regard and i also request the members to suggest the good tool to compare the image 1 and image2 byte by byte.

thank u

 
Posted : 24/12/2016 11:59 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

waiting for further inputs in this regard and i also request the members to suggest the good tool to compare the image 1 and image2 byte by byte.

Good ol' FC.EXE? 😯
http//ss64.com/nt/fc.html

Or - as thefuf already suggested vbindiff
https://www.cjmweb.net/vbindiff/

a word of caution, the site is OK but seemingly has an expired certificate (stupid https), so your browser may throw a fit at it.

I believe you can use also a hex editor such as HxD
https://mh-nexus.de/en/hxd/

No idea if there can be issues with such large files, maybe it would be specifically more productive to use a script to hash corresponding parts of the images and compare the partial hashes, more or less like a binary search. (of course if there are several changes spread all over the image it won't work that well).

jaclaz

 
Posted : 25/12/2016 1:38 am
Share: