Understanding "Sour...
 
Notifications
Clear all

Understanding "Source verification failure" in Guymager Acquisition

Suai
 Suai
(@suai)
New Member

This seems to be a recurring issue I'm having with HDD acquisitions in Guymager.

I know it has to do with bad sectors on the disc, but I can't quite get a clear grasp around it to explain in a court hearing. Could someone kindly explain what's going on, and IF the acquisition could be considered as valid?

Here's an extract of a .info file from a failed acquisition:

 

During acquisition, 40 bad sectors have been encountered. They have been replaced by zeroed sectors. The sector numbers are:
1369656456-1369656463, 1369658800-1369658807, 1369664416-1369664423, 1369667208-1369667215, 1369669888-1369669895
During verification, 24 bad sectors have been encountered. The sector numbers are:
1369658800-1369658807, 1369664416-1369664423, 1369667208-1369667215
State: Finished successfully (with 40 bad sectors)

MD5 hash : ba324ecbf23f21830f9b0099bbf1bca8
MD5 hash verified source : e3c4c3867ca797bbf0a1cc914e44fba6
MD5 hash verified image : ba324ecbf23f21830f9b0099bbf1bca8
SHA1 hash : e0eb8f44d0e807c390c072c58d81cad690780906
SHA1 hash verified source : 8e8da131eb092a7d5b9e9d85b60219234a972ef7
SHA1 hash verified image : e0eb8f44d0e807c390c072c58d81cad690780906
SHA256 hash : --
SHA256 hash verified source: --
SHA256 hash verified image : --
Source verification FAILED. The device didn't deliver the same data during acquisition and verification. Check if the defect sector list was the same during acquisition and verification (see above).
Image verification OK. The image contains exactly the data that was written.
Maybe you try to acquire the device again.

Quote
Topic starter Posted : 20/11/2020 4:31 pm
jaclaz
(@jaclaz)
Community Legend

Acquisition, 5 extents were found "bad" (and thus written to the image as 00's):

1) 1369656456-1369656463

2) 1369658800-1369658807

3) 1369664416-1369664423

4) 1369667208-1369667215

5) 1369669888-1369669895

Verification, only 3 extents were found bad:

2) 1369658800-1369658807

3) 1369664416-1369664423

4) 1369667208-1369667215

During verification the 2 extents:

1) 1369656456-1369656463 (63-56+1=8)

5) 1369669888-1369669895 (95-88+1=8)

that total 40-24=16 sectors, for *some* reasons, and unlike before, were read correctly (and - indirectly -  at least one of them is not 00 filled).

If you check the image, these two extents will be filled with 00's.

In theory, you could try dd-ing from the source just these two latter extents, then make a copy of the image and write them to it, if you re-compute the hashes they will become the same as the "verified source".

The image is not "valid", it misses the "real" contents of 16 sectors but, much more than that, you have no way to prove that those 16 sectors are the only difference.

It is an old issue that noone seemingly wish to solve. IMHO there is the need of "more granular" hashing, see:

https://www.forensicfocus.com/forums/general/change-of-hash-sha-256/

https://www.forensicfocus.com/forums/forensic-software/different-calculated-hash-in-encase-ftk/

https://www.forensicfocus.com/forums/general/flaw-in-evidence-verification-process/

jaclaz

ReplyQuote
Posted : 20/11/2020 5:23 pm
Share: