Verified Forensic Image

could you just hash the disk, attempt to write to it , then hash the disk again?
if the hashes dont match then you have a problem.

If your purpose is to verify that the write blocker is not altering data then you are on the right track. Only I don't know how to restore a forensic image back to the hard drive. I would simply pull a hard drive from any computer and use FTK Imager to create a set of EO1 image files. When it is done creating the image files it gives a Verify Results box with Computed Hash and Reported Hash and whether they match. That data is also in the report file that comes with the image files. If your purpose is to prove that it is blocking then just hook up a drive and try to write to it. Kudos for doing your own testing since there is no better learning experience.

To give it a simple test then you could give hmorgan's suggestion a go.

If you wish to try a restore (Encase and XWays allow you to do this) then when you have to remember is that the E01 hash will reflect the image and when it is restored to another disk (which will likely be larger to allow the restore to occur correctly) then if you were to fun a hash over the restored disk it would be different to the original image since it would run the algorithm over the unallocated clusters as well. You would have to specify the hash was over a certain area of the disk. So in all honesty the method doesn't make that much sense for what you are trying to achieve, although it may be useful as a learning experience.

To do a restore with encase, load the case, right click on the case device and select "restore".

The CFReDS Project http//www.cfreds.nist.gov/ has a bunch of images of simulated digital evidence that you could use for this. All of these have MD5 values that you can verify against. These data sets also have documented contents to search for so they provide a valuable training resource as well.

Kaly,

The issue I see with your solution is that, say the image you have is 20Gb, then you write it out to your HD which is 100Gb. You may have a problem getting the hash to match again when you re-image because you will be picking up more bytes, even if you Zero them out.

Also, in that example you are not only testing the FastBloc but also your method and attachments for writing out the known data to your drive. Suppose the hash comes back different, how will you know if it was the FastBloc or the method you wrote the disc in the first place? You could hash it in between, perhaps.

My suggestion to test your FastBloc. Obtain a drive, small one will do. Size matters not. Wipe it, put some files on it. Shutdown your computer.

Boot into your computer with a forensic Linux Boot CD, any one which will not automount the drives will do. Now hash the drive. This will be your answer sheet.

Shutdown computer, attach that drive using the FastBloc device. Now boot back into the same Linux Forensic boot CD and image the drive. Your hash value for the image should match the answer sheet.

Now you have proven that your FastBloc is indeed imaging correctly.

Good Luck

Mark

I'm sorry but this is a little more complex to verify correctly, than just shoving some data out and checking a hash.

Also be aware that MD5 Is now considered a flawed hashing system, SHA is preferred.

Read the following standards to get a rough idea how the NIST handle write blocker testing.

National Institute of Standards and Technology (2004) Hardware Write Blocker Device (HWB) Specification. [Online]
Available at http//www.cftt.nist.gov/HWB-v2-post-19-may-04.pdf

National Institute of Standards and Technology (2005) Hardware Write Blocker (HWB) Assertions and Test Plan. [Online]
Available at http//www.cftt.nist.gov/HWB-ATP-19.pdf

It is only worth doing something if your going to do it correctly, there are no shortcuts in forensics.

C.

I'm sorry but this is a little more complex to verify correctly, than just shoving some data out and checking a hash.

Also be aware that MD5 Is now considered a flawed hashing system, SHA is preferred.

C.

You are talking about collisions using the MD5 hash algorithm.

MD5 is not recommended for such things as SSL certificates or other secure authentication protocols but when you are talking about using it to validate an image or files copied from a source the odds of a collision are extremely remote.

A very good summary can be found here

http//www.accessdata.com/media/en_us/print/papers/wp.md5_collisions.en_us.pdf

RB

code-slave I completely agree that you would need a rigorous testing suite in the event you were testing it for ISO or UCAS purposes. In fact the same principle in those circumstances would also apply to software you use (which is a massive can of worms).

My impression was that kalymistirl was looking for basic testing to assist in their own mind how these things work. Of course such testing will not validate the device but it will at least show that they at least tested it to ensure it hasn't an 'obvious' error (that the write-protection is simply non-functional).

I agree with Beetle, MD5 hashes are still appropriate to use. The collision involved a very small amount of data and the data was mathematically 'tweaked' in order to achieve the collision. Such a non-assisted collision with small files would be very rare, with large files it would be computationally just about impossible.

Kaly,
Also, in that example you are not only testing the FastBloc but also your method and attachments for writing out the known data to your drive. Suppose the hash comes back different, how will you know if it was the FastBloc or the method you wrote the disc in the first place? You could hash it in between, perhaps.

My suggestion to test your FastBloc. Obtain a drive, small one will do. Size matters not. Wipe it, put some files on it. Shutdown your computer.

Boot into your computer with a forensic Linux Boot CD, any one which will not automount the drives will do. Now hash the drive. This will be your answer sheet.

Shutdown computer, attach that drive using the FastBloc device. Now boot back into the same Linux Forensic boot CD and image the drive. Your hash value for the image should match the answer sheet.
Mark

Mark,

Chicken and egg - how do you know the Linux Boot CD was operating correctly? A "forensically sound" Linux Boot CD is just offering software writeblock rather than hardware.

-David