zero fill and checksum

An MD5 hash will be different for every length of file, even though the contents may all be zero. A CRC sumcheck will also produce different results.

The only sumcheck that will return zero is one that justs adds each byte to a number.

The only way to check that it is totals zeros is to add every byte into a long number, ie int64 to make sure it does not overflow. This number should be zero

So, how do you go about proving that in court?

Here is how I heard it. You image the drive, but after doing your examination on the image you want to start up the computer as the suspect did, same hardware and such. You can't just put the evidence drive in, so you do a copy of the image to a new, similiar drive. However, the defense might balk, how do you know that the new, similiar drive did not have old data on it, data that you are now using against their client.

I might have heard wrong, but my curiousity remains. How do you go about proving a zero filled drive is actually zero filled? A program or something?

Pretty much all the live forensics CDs out there implement a checksum that will return a string of zeros if your drive is wiped. Get one, validate its results against a known wiped drive, and then use it every time and you are fine.

So, how do you go about proving that in court?

Here is how I heard it. You image the drive, but after doing your examination on the image you want to start up the computer as the suspect did, same hardware and such. You can't just put the evidence drive in, so you do a copy of the image to a new, similiar drive. However, the defense might balk, how do you know that the new, similiar drive did not have old data on it, data that you are now using against their client.

I might have heard wrong, but my curiousity remains. How do you go about proving a zero filled drive is actually zero filled? A program or something?

Compression of the zeroed out storage device should produce maximum compression ratio and you can prove this for any given-sized storage media. On another note, the Secure Erase utility is fast and completely compliant with U.S. gov standards and practices.

If I am not mistaken…

A CRC32 check of the entire drive that is completely Zeros will yield a checksum of all Zeros.

I don't have my info in front of me but I seem to recall that may be the case. You may want to test it out. This is assuming that the drive has been zero-wiped and not reformatted after that.

Happy and safe holidays and New Year to everyone!
-=ART=-

If you are wanting to see things like the user did and aren't going the virtual route. Use Safeback and backfill.

Something that is easily forgotten is that any objection has to have foundation, someone can't object just to object. If there is an objection raised you can intelligently say you did xyz and why xyz was the best choice for your sceneraio.

Safeback is a great tool and rarely mentioned anymore, but as long as you get a hard drive which is close to the same size as the donor drive, you will be A O K.

So, how do you go about proving that in court?

Here is how I heard it. You image the drive, but after doing your examination on the image you want to start up the computer as the suspect did, same hardware and such. You can't just put the evidence drive in, so you do a copy of the image to a new, similiar drive. However, the defense might balk, how do you know that the new, similiar drive did not have old data on it, data that you are now using against their client.

I might have heard wrong, but my curiousity remains. How do you go about proving a zero filled drive is actually zero filled? A program or something?

"A CRC32 check of the entire drive that is completely Zeros will yield a checksum of all Zeros."

I am pretty certain that a CRC32 will not produce a sucheck of zero from data which is just zero. I am also pretty certain that the sumcheck will be different for each length of a zero filled file. The sumcheck starts with an XOR with a value such as 0x8005 (for CRC16) and this ripples through to be different with every byte

I am not pretty 😯 , but I am certain wink
http//en.wikipedia.org/wiki/Cyclic_redundancy_check

Checksums of a 512 bytes 00 filled file (tiny hexer)
Sum of bytes
00

MD5 digest
BF619EAC0CDF3F68D496EA9344137E8B

Checksums of a 1024 bytes 00 filled file (tiny hexer)
Sum of bytes
00

MD5 digest
0F343B0931126A20F133D67C2B018A3B
jaclaz

In my opinion CRCs are not ideal for verification of all-zero space, for two main reasons
(1) while it is possible to select a CRC with properties that generate a zero result for all-zero data, they will do it for any length of data (so does not verify that the full data length has been examined)
(2) CRCs are easily manipulated (i.e. I could easily insert data into the middle of all zero space and simply add a few bytes of extra data to generate a zero CRC). Equally CRC-checked data itself is often designed to generate all-zero result for error checking.

My preferred method therefore is either a direct check (effective programming check of values at all locations are ==0), or if wanting to use tools for ease of use, then to perform a standard hash (MD5/SHA1/SHA256) and compare against the known result for a hash of an all-zero sequence of bytes of the same length as the data under consideration. The "known result" can be generated either by creation of a file of the required size of all-zero binary data and performing the hash on that file, or programatically.

Since I had a software method I wanted to test, I have created this as a simple windows utility, the "all-zero hash calculator" (am sure I should have thought of a snappier name…) which will provide the "known result" for any specified length of bytes, and included acceleration tables so that the result can be calculated in less than a second for any length up to 2TB. I have made this freely available here. Any feedback welcome as usual, and hope some people find it useful.

Phil.