Wednesday, January 23, 2008

Validating write blockers

In the Recommended forensic hardware thread in the Hardware forum I recently wrote the following about a hardware write blocker I'd just come across which I hadn't seen before:

I think this brings up the interesting question of how we (as practitioners) test the write blocking capability of new devices both to satisfy ourselves that they work as advertised and to be able to show that in court.

For the sake of argument, let's imagine that we *need* to use one of these IOI products (if we want to be specific we'll say it's the FW2ATA525-MR1-WP already mentioned) but it's not a device you've used or tested before, it hasn't been used in a court case in your area and you have only the manufacturer's word that it works properly. What methodology are you going to employ to test it in some formal sense?

In practice, I suspect most of us use write blockers which are seen as industry standards and have already gone through some form of validation procedure. Typical choices would be Guidance Software's FastBloc devices or something from the Tableau product line, both examples of items from well respected specialist companies. Not only have these devices presumably undergone extensive testing by manufacturers concerned to protect their reputation as industry leaders but we also have the results of independent testing to refer to, perhaps the best well known being the NIST hardware write block testing program.

What of new devices from relatively unknown manufacturers though? How do we reassure ourselves and the courts that they work as advertised? The obvious answer is that we test them ourselves but how exactly do we do that, what methodology do we use?

In theory, write blocking is easy to understand: we want to prevent any alterations to the attached evidence device while allowing all data to be retrieved. In practice the situation is more complex, there are many different commands which can be sent to a storage device from a variety of different components in a host computer (BIOS, OS, application software, etc.) and we need to satisfy ourselves that a write blocking device operates as expected (preventing alteration/allowing retrieval) under all circumstances. Similarly, testing methodologies can be either straightforward or complex. For example, compare the validation methodology suggested in the Helix manual:

This process is based on the National Center for Forensic Science (NCFS) 5 step validation process for testing write protection devices (Erickson, 2004). It was originally designed to test the Windows XP SP2 USB software write blocker, but has been adapted to test any hardware and/or software write blockers.

Step #1 – Prepare the media

a) Attach the storage media you will be testing with to your forensic workstation
in write-enabled mode.
b) Wipe the media - validate that this has been successful.
c) Format the media with a file format of your choosing.
d) Copy an amount of data to the media.
e) Delete a selection of this data from the media.
f) On the desktop of your forensic workstation create 3 folders. Call these Step-1, Step-2 and Step-5.
g) Image the media into the Step-1 folder and note the MD5 hash.

Step #2 – Testing the media

a) Remove and then replace the testing media into your forensic workstation.
b) Copy some data to the media.
c) Deleted a selection of this data from the media.
d) Image the media into the Step-2 folder and note the MD5 hash.
e) Validate that this hash value is ''different'' to that produced in Step #1.

Step #3 – Activate the write blocking device

a) Remove the media from your forensic workstation.
b) Attach and/or activate the write protection device.
c) Follow any specific activation procedures for the specific blocker.

Step #4 – Test the write blocking device

a) Insert the media into your forensic workstation.
b) Attempt to copy files onto the media.
c) Attempt to delete files from the media.
d) Attempt to format the media.

Step #5 – Check for any changes to the media

a) Image the media into the Step-3 folder and note the MD5 hash.
b) Validate that this MD5 hash is the ''same'' as the MD5 hash from Step #2.

with the methodology outlined by NIST in their test plan available at

If you're thinking the easy way round this is just to avoid the issue and buy one of the well known write blockers instead, the bad news is that testing your device (regardless of manufacturer) is almost certainly something you should be doing anyway. There's a good thread here in the forums discussing when and why write blockers should be tested.

Of course, we need to see validation within the wider context of the entire forensic process which involves, potentially at least, presenting evidence in court. As a result, there may be certain testing methodologies which are already specified or recommended wherever we find ourselves working.

I think I'm going to dig a little further into this and see what various agencies have to say. I'll report back when I have some news but in the meantime any thoughts or comments would be very welcome. How would you validate a new write blocker? Do you regularly test your existing device? How reliable are hardware write blockers (have you had one fail on you)? Let me know.

Tuesday, January 15, 2008

Events calendar updated

Just a quick note to say that the events calendar has now been updated with relevant events covering the rest of the year. If anyone know of other events which should be included (primarily conferences) please add them to the calendar by going to the appropriate day/days and clicking the "Add Event" button (I'll then review/approve the new addition). Thanks!

Wednesday, January 09, 2008

Computer forensics around the world

One of the interesting things about running Forensic Focus is seeing which countries our visitors are coming from. Of course, as an English language site it's not particularly surprising to note that a significant number of visitors come from the US and the UK. However, I'm always delighted to see just how many visitors come from other countries - not just other English speaking or Western European countries, but countries from every corner of the globe. Interest in computer forensics is certainly a worldwide phenomenon.

From some of the emails I've received over the past few years and posts to the forums (not to mention news items posted to the homepage) it's clear that the state of computer forensics differs widely from one country to another. What do I mean by "state"? A number of things, touching upon but not limited to issues surrounding: legislation, awareness, training, best practice, job opportunities, etc. It's also clear that things are changing and progress is being made in many places.

An opportunity exists for those of us in countries with more fully developed computer forensics infrastructures to assist newcomers to the field and, from what I understand, a number of countries are actively seeking experienced practitioners from outside their borders to assist with this process. That's not to say that building awareness and implementing change is a straightforward process, and no one knows a country better than its own citizens, but lessons learned elsewhere can often save valuable time and effort. Ultimately, though, computer forensics exists within a larger framework built around the use of and access to technology, the political climate, even social norms and values. The shape of forensic computing in one country may differ from that seen in other areas of the globe.

I'd be interested to hear what others think of the global state of our profession. Which countries are world leaders in computer forensics and why? Which countries are furthest behind? Is the development and use of high tech investigative powers always a positive thing? Please leave a comment!

Saturday, January 05, 2008

Training and education links page updated

The training and education links page at

has been updated. Links are now listed by country on separate pages and non-working links have been removed.

The procedure for adding a new link has also been simplified, just click here.

Friday, January 04, 2008

X-Ways interview and a few other items

For those who didn't catch last month's newsletter a quick note to say that Stefan Fleischmann has very kindly agreed to answer interview questions this month. If you have any questions about Stefan's X-Ways range of software products please feel free to post them to this forum topic. Alternatively, if you prefer, you can always drop me a line privately (email, PM or contact form). The X-Ways lineup includes not only X-Ways Forensics but also X-Ways Capture for live analysis and I for one am certainly looking forward to speaking to Stefan and learning more about both of these products. If there's anything you'd like to ask please don't let this opportunity go by!

In other news the forum discussion of recommended forensic hardware now finally has a summary page to go with it at

This should be very much a "living document" with updates and additions strongly encouraged - please use the forum topic mentioned above to continue the discussion.

Another topic which came up quite recently in the forums is that of report writing. This too now has a dedicated page at

and again I'd like to encourage further additions to this page (sample reports, relevant links and articles on CF report writing).

Finally, a quick plug for this post by kovar concerning terms of engagement. It seems to me this is another useful area for discussion, in particular for those in private practice, and at some stage will probably also warrant a separate page as a quick reference. Please help if you can!

Tuesday, January 01, 2008

Happy New Year!

A very happy New Year to all readers and all the best for 2008!

I'm looking forward to getting back in the saddle this month after the usual craziness of December. Hope everyone enjoyed themselves...see you soon in the forums!