Two E01 with differ...
 
Notifications
Clear all

Two E01 with different MD5, help please ~~

8 Posts
5 Users
0 Likes
1,143 Views
(@chauyiu2000)
Posts: 3
New Member
Topic starter
 

Hi all,

I have a case recently and there is a serious problem.

I used Encase 6.18 acquired a laptop hdd (120GB, E01) in 2015 and had 3 "read error" in 3 different sectors.

I acquired the hdd again (E01 and dd) in 2017 for court purpose. This time no error occurred.

The MD5 is different since the two E01 is different.
For experiment, I filled in "00" in the 3 "read error" sectors to the dd file by using WinHex (as said from Encase it will zeroed out when error occur), then I calculated the MD5 again, but the MD5s didn't match.

I extracted 700+ files in 2015, and I extracted same files in 2017, the MD5s are matched.

The problem now is, the MD5s of 2 E01 is not matched even though I zeroed out the error sectors in experiment.
I have no idea how to explain such issue . Please help ~~

 
Posted : 10/05/2017 11:20 am
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

Sometimes when you read every byte on an older spinning hard disk it plays ball, sometimes it doesn't. Take those words and put them into a suitable explanation that a judge/jury can understand and that should be the end of it. Your hashes match for your contentious files which is all that really matters. This is a good example of why, the first time around, we should always lay our cards on the table and say 'I acquired the disk using blah blah blah and due to the age of the disk certain sectors could not be read as shown here in my log files'.

 
Posted : 10/05/2017 11:38 am
(@athulin)
Posts: 1156
Noble Member
 

we should always lay our cards on the table and say 'I acquired the disk using blah blah blah and due to the age of the disk certain sectors could not be read as shown here in my log files'.

… and, it seems, have a good explanation of why it worked better wto years later.

I mean, the other way around, fine, especially if the hard disk drive had been left unpowered for all that time. But fail in 2015, and no problems in 2017 takes some additional explanation. Unless the drive *had* been powered up, used, and the disk remapped the bad sectors,

 
Posted : 10/05/2017 9:05 pm
(@chauyiu2000)
Posts: 3
New Member
Topic starter
 

Thanks guys ~~

Some additional information about the case

1) Old E01 was deleted by colleague accidentally, the experiment I conducted was according only the previous Encase acquisition report and the new E01/dd. I can not compare old E01 and new E01 since the old one is missing.

2) Acquired new E01 was requested by Defendant side, they want the E01 image and perform examination by themselves.

3) My boss consideration is, the Defendant lawyer may point out this issue (two MD5 not matched) and say like 'two MD5 is not matched because the two images are different', '700+ files MD5 were matched because Forensics Examiner put those 700+ files into my Client's computer after first acquisition, that's why 700+ files MD5 are matched but the images MD5 is not matched ….'

Thanks for your advises
And sorry for my poor English, hope you guys understand what I'm saying ~

 
Posted : 11/05/2017 7:03 am
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

You don't have the original E01? That doesn't help! Have you got the hash values of all of the chunks of the original E01? Maybe you could compare that with the hash values for each chunk of your new E01 and prove that only one chunk of, say, 2GB was different?

Other than that I would start harvesting any available SMART data from the drive controller as that might give weight to any argument that the drive is not very reliable, hence the inconsistencies. Maybe repeat the acquisition process a few times with exactly the same settings and see whether it is consistent. Ideally it wouldn't be, so that you could show that this is the 'normal' behaviour of that drive.

Otherwise, you're just going to have to put your hands up and state that there was some issue with the original acquisition but you have no way to compare the 'new' E01 with that one. The files were/are still there with the matching MD5 that presumably the defence would still have to explain away. No easy task.

 
Posted : 11/05/2017 10:04 am
(@thefuf)
Posts: 262
Reputable Member
 

For experiment, I filled in "00" in the 3 "read error" sectors to the dd file by using WinHex (as said from Encase it will zeroed out when error occur), then I calculated the MD5 again, but the MD5s didn't match.

What was the error granularity? It is possible that a single bad sector results in 64, 128, etc. sectors being filled with null bytes in the image.

 
Posted : 11/05/2017 4:28 pm
(@mansiu)
Posts: 83
Trusted Member
 

Go to check the SMART info, look for reallocated sector counts. Those 3 bad sectors may have been replaced with spare sectors and this explains why bad sectors are gone.

 
Posted : 11/05/2017 10:53 pm
(@chauyiu2000)
Posts: 3
New Member
Topic starter
 

Thanks again guys

redcat
Yes, the original E01 was wiped by my teammate. What I only left is the original Encase acquisition report. It only show the whole image MD5, not chunks of MD5.
My situation is standing on thin ice …

thefuf
The setting of error granularity is 1. Therefore I filled "00" in 1 sector in my experiment.

mansiu
We are also thinking about SMART and reallocated sector counts. We are searching around these information since we have not knowledge in this field.
Is there any method to know which bad sector replaced by which spare sector ??
We can't access the original hdd because it's an exhibit and keep by other team. Is it possible to check the SMART info without the hdd ??

Thanks again, you guys are very helpful ~~

 
Posted : 12/05/2017 8:47 am
Share: