This raises some obvious questions:
1. Why were these sectors unaddressable in Windows as opposed to
DOS/Linux?
2. Do you agree that even if the spare sectors did not contain any
useful evidene in this case, it _could_ have in another?
Suppose for example that the original disk had been partitioned with
Linux, using the entire address space. Now, when imaged under Windows,
the last sectors which could contain data could not be read.
What happens when you go to court with this evidence and the opposing
counsel alleges that you have missed crucial evidence that could free
his client from suspicion because you did imaging under Windows and
therefore did not image the entire drive?
Allthough this may seem far-fetched, we should really understand the
process that we go through when imaging a drive, including what areas of
a drive can be reached under which operating system. If Windows cannot
reach the entire drive, then perhaps the conclusion would be to avoid
imaging under Windows.
--
Svein Y. Willassen, M.Sc.
-----Opprinnelig melding-----
Fra: Siebert, Bill [mailto:bill.siebert@encase.com]
Sendt: 17. desember 2004 02:24
Til: forensics@securityfocus.com
Emne: RE: Two hash
Paul and I discussed this off list and discovered "the issue."
Linux and DOS were able to reach 5,103 sectors of non-addressable Unused
Disk Area, that Windows was not. Thus a different hash value.
The drive in question was 74.5GB in size.
Partitions:
Code Type Start Sector
Total Sectors Size
0B FAT32 0
10720080 5.1GB
07 NTFS 10720080
145560240 69.4GB
Linux, DOS, and Windows all saw the partitions correctly and captured
the partitions correctly.
As explained above, the differing 5,103 sectors were the drive's Unused
Disk Area and analysis of those sectors found absolutely NO data of any
significance or consequence.
If you hash the sectors from 0 to 156,296,385 with Linux, DOS, and
Windows, the hash values are all identical, thus the captured data is
identical.
Any imaging engine using Windows would reach the exact same number
sectors; i.e. 156,296,385 sectors as opposed to 156,301,488 sectors.
No harm, no foul, no issue.
For this reason, we have both moved on.
Happy Holidays.
--------------------------
Bill Siebert
Director of Customer Relations
Guidance Software Incorporated
215 N. Marengo Ave., 2nd Floor
Pasadena, CA 91101
telephone: 626.229.9191 x. 230
fax: 626.229.9199
cell: 626-523-1161
email: bill.siebert@encase.com
--------------------------
Have you heard? www.VisComing.com
-----Original Message-----
From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
Sent: Monday, December 13, 2004 8:49 AM
To: LERTI - Paul Vidonne
Cc: forensics@securityfocus.com
Subject: Re: Two hash
On Sat, 11 Dec 2004 13:45:35 +0100, LERTI - Paul Vidonne said:
How can a same physical disk can receive a different hash (MD5) from
EnCase and Linux md5sum ? (both through a drive lock) ?
The most likely explanation is that EnCase and Linux are using different
sets of blocks to compute the hash over - for instance, the Linux device
driver may be losing from 1-7 512 byte blocks at the end of the disk if
the disk capacity isn't an exact multiple of 4K or 8K or similar
(there's been multiple threads on the linux-kernel list regarding kernel
wonkyness in this case. The Linux
2.6 ide-cd driver is also known to have issues reading near the end of
the media as well).
Another possiblility is that the Linux md5sum is computing across the
physical disk, but EnCase is including its metadata in the signature.
It's also possible that *both* are happening, too....
Note: The information contained in this message may be privileged and
confidential and thus protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer. Thank you.
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
