I always do this using DOS applications not from a Windows environment.
Alan
Hallo Alan
I do not think if you perform MD5 function from Windows, Linux or DOS it will make any difference. MD5 has seed value and will always produce a value result even if your data is empty. MD5 is useless for checking whether a drive has been wiped.
Which checksum do you mean also? Many checksums will produce not zero values as well.
I would not trust Encase to wipe a drive either. I have seen countless times where it did not completely wipe the drive and where random blocks of data still remained.
A good way of checking is to search for [^\x00] over a drive that has been wiped with 0x00.
As for the original question, I agree with what others have said. It is not necessary to wipe when using imagers whcih write data to file containers but would be if cloning. If you had to wipe the data media prior to imaging, all the forensic teams using network storage would have issues as you cannot wipe that?
I have just looked in the UK ACPO guide to see if it orders the wiping of data disks and I cannot see it.
Mike
Short of manually going through the drive and ensuring that each sector is OO, is anyone aware of any third party tools that will check a drive to see if it has been wiped properly?
Just to add to Lars post;
You could try hexdump a *nix util.
It will output data but if the data are repeated it will sub in an asterisk until some change is seen. so you don't have to sit staring at billions of zero's going past. - Drive is a 10Gig 5400rpm Fuji
Disk /dev/hda - 10005 MB / 9541 MiB - CHS 19386 16 63 (RO), sector size=512
==========================
root@1[root]# date; hexdump /dev/hda ; date
Wed Oct 17 172653 CEST 2007
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
25458c000
Wed Oct 17 174832 CEST 2007
==========================
where
date; is just to put a time stamp on for duration check
0000000 is the start address
the first line of 16 bytes shows zero's
"*" shows "it repeats"
until
25458c000 the end address
Other than that, maybe get a dedicated unit that wipes drives verifies like the "<…>masster" product range.
Kern
MD5 is useless for checking whether a drive has been wiped.
I'm interested in this comment. I would have thought that it provides a good mechanism to prove that a drive was wiped.
You wipe the drive by writing all zeros to it from /dev/zero and then run the MD5 on it, recording the value returned.
If anyone has a query regarding if the drive was indeed wiped you can create a backup of the HD, and then wipe the drive using /dev/zero. If you hash the contents you should get the same value as before.
You can state this as you know the dd command with the switch if=/dev/zero writes zeros to the entire disk and would expect it to completely overwrite anything on the disk.
I think its a case of knowing your tools, how they work, their expected output and being able to justify why you took the action you took.
I'm interested in this comment. I would have thought that it provides a good mechanism to prove that a drive was wiped.
You wipe the drive by writing all zeros to it from /dev/zero and then run the MD5 on it, recoding the value returned.
If anyone has a query regarding if the drive was indeed wiped you can create a backup of the HD, and then wipe the drive using /dev/zero. If you hash the contents you should get the same value as before.
This procedure would work for verifying that the results of one wipe matched the results of the second wipe. It would only be valid for identical drives that had no errors since the appearance of the smallest bad spot would now result in a different hash. This procedure also assumes that you manually verify that the wipe worked the first time.
I think after some n wipes you would have verified the wipe procedure and would only find a periodic spot check necessary. I'd like to hear what others do as a practical matter.
Maresware offers a unique solution….for free!
From their site
Sha verify is a program which will calculate the MD5 (128 bit), SHA1 (160 bit), SHA2 (256 bit), SHA2 (384 bit), and SHA2 (512 bit) hashes of files.
It also has the unique ability to emulate the MD5 or SHA1 of a number of specified disk sectors containing a single overwrite character. This is especially useful when trying to confirm the MD5 values of forensic software on wiped hard drives. It can also be used to confirm that your forensic software is providing you with the correct MD5 or SHA value of a wiped disk.
Check it out for yourself at http//
I am not affiliated with Dan Mares or Maresware, though I am an admirer.
Hi Larsminster,
Yes you are right MD5 will not work as you say but a simple checksum will.
In my original post I did not get my head in to gear; trying to do too many things at once!!
Alan
Hallo Alan
I do not think if you perform MD5 function from Windows, Linux or DOS it will make any difference. MD5 has seed value and will always produce a value result even if your data is empty. MD5 is useless for checking .
Yes you are right MD5 will not work as you say but a simple checksum will.
In my original post I did not get my head in to gear; trying to do too many things at once!!Alan
No it won't !!!
There are essentially three different mechanisms that I think are being discussed on this thread none of which really does the job properly/elegantly. To take each in order
Checksum
This simply works by adding the value in each byte/word/doubleword depending on the algorithm and returns the sum modulo the size of the checksum. For example a single byte hex string such as
01 will have a 8 bit checksum of 01 i.e. 01 % 256 – for non programmers % means the remainder of a after dividing by b
01 D1 will have an 8 bit checksum of 210 i.e. (01 + D1) % 256
01D1AC6D8406B8F8 has an 8 bit checksum of 25
Interestingly extend the above string by adding hex DB
01D1AC6D8406B8F8DB and the 8 bit checksum is 0 (zero)
A sector full of hex 80 will produce 8 bit and 16 bit checksums of 0 (zero)
In summary an 8 bit checksum will do the job but there is an error built in such that you have a 1256 chance of a drive filled with random data (or documents) having a checksum of 0. The normal checksum is 16 bits and the odds of a drive containing data is now 655361 – but still (in forensic terms) too close to 0 to be anything other than a very basic sanity check
CRC
The standard CRC used on floppy disks uses a polynomial of X^16 + X^12 + X^5 + 1 and it is designed to detect changes (drop out) in runs of data, the simplified process is that each bit in the data stream is shifted into a 16 bit register and on each iteration the register is XOR’d with the polynomial but only if the MSB is a 1.
The upshot of this is that a CRC appears on the face of it to satisfy the requirements – as a stream of zeros pumped into one end of the register will produce a zero output from the register. There is a problem though
However, the specification states that the register is preset to different values so that the MSB will always be a one for a given data stream, this means that a CRC on a single null byte will be different than a CRC on two null bytes – so the CRC is less useful than the checksum approach
Hash (MD5/SHA1 etc)
This has been done to death, but suffice it to say that a hash that reported a file of x bytes had a hash of y and a file of x bytes +1 null byte had the same hash of y would be next to useless.
In summary although the Checksum does work, with some deficiencies, but the simplest approach, if you want to use a program, is use something like hexdump as mentioned above – or write something (this would be a nice simple starter project for someone new to programming) to check that every sector contains zeros. What sounds better in court?
1. I used a complex algorithm based on polynomial arithmetic that produces a 256 bit value that tells me that the drive does in fact contain just zeros, or
2. I checked every sector of the disk to ensure that every byte was zero – here is the log file of the program I used showing that the drive was indeed blank
Our company standard though is to use a new disk drive for each job, or rather for each job that may leave the premises – while a disk drive can be wiped what is harder to do is to wipe any of the spare sectors that have been swapped out. There is always the chance, and it is a real chance, that an amount of data from a drive that has been previously used and wiped (albeit a small amount of data) could be recovered.
A second problem is that you wipe a 150GB drive on a machine that has a 128GB limitation, you then verify that the drive is empty (of course it is easiest to do this on the same machine) and (insert tool of choice here) you get a nice log file telling you that the drive is empty. You then send the drive out to an agency to receive some image files and they find that the drive contains data from a previous job above the 128GB cut off.
What a sound explanation Paul.
i'd go for 2 I checked every sector of the disk ….including new drives. standard procedure. "Belt _and_ braces."
Being a "need to see for myself" type i like to peek. Having bought alleged "brand new" devices before, albeit not direct from the manufacturer, brief analysis (hexdump) revealed data residue.
You just can't trust anyone can you?
Kern