Admissibility of Digital Evidence

Juniper
I was hoping to give you a link from previous discussion at FF that would be worthwhile reading. Crikey but I hadn't realised there were so many worthwhile discussions here at FF that it is easier to invite you to consider running a Forensic Focus search on write blockers. I am not sure there is one place that encapsulates all the pros and cons of using write blocker, but I could be wrong.

Sorry it is not better help for you.

NIST as developed the Computer Forensic Tool Testing methodology which has examined a number of hardware and software write blocking devices. These can be found, here

http//www.cftt.nist.gov/hardware_write_block.htm

MyKey Technologies has a white paper on possible problems with software write blocking which are important to consider if you are depending upon the OS to enforce the read-only options.

http//www.mykeytech.com/SoftwareWriteBlocking2-4.pdf

These days, with live imaging more widely used, the issue of write blocking should be considered not in the context of whether the imaging process altered the subject drive, but whether or not the examiner can fully explain what changes, if any, might have occurred and their forensic significance.

Using a CFTT validated write blocker, when practical, preempts a lot of argumentation as to whether the evidence was corrupted but I, for one, am finding many more circumstances where I have to leave a foot print and want, simply, to make it as small as possible.

As the saying goes, you don't throw the baby out with the bath water.

NIST as developed the Computer Forensic Tool Testing methodology which has examined a number of hardware and software write blocking devices. These can be found, here

http//www.cftt.nist.gov/hardware_write_block.htm

MyKey Technologies has a white paper on possible problems with software write blocking which are important to consider if you are depending upon the OS to enforce the read-only options.

http//www.mykeytech.com/SoftwareWriteBlocking2-4.pdf

These days, with live imaging more widely used, the issue of write blocking should be considered not in the context of whether the imaging process altered the subject drive, but whether or not the examiner can fully explain what changes, if any, might have occurred and their forensic significance.

Using a CFTT validated write blocker, when practical, preempts a lot of argumentation as to whether the evidence was corrupted but I, for one, am finding many more circumstances where I have to leave a foot print and want, simply, to make it as small as possible.

As the saying goes, you don't throw the baby out with the bath water.

Thanks for the replies - interesting stuff and have been looking at previous posts on the forum.

seanmcl Could you please give an example of a time when you left a footprint?? Can you elaborate as to why you had to do this??

seanmcl Could you please give an example of a time when you left a footprint?? Can you elaborate as to why you had to do this??

I can think of two situations, so far. The first is live imaging where it was not practical to shut down an enterprise network. In lieu of this I used F-Response which leaves a small but detectable footprint.

The other was a case where I had a legacy system for which the OS/drive were so obsolete that replacements could not be found. To retrieve the data which was encoded in binary form I had to run the native application. There was not VM or emulator for this OS/processor combination and booting the system required a geometry on the evidence drive which was identical to the subject drive, but the drives were no longer in production or available as refurbished drives.

I had no choice but to image the system, record the hashes, and then boot it in order to bring up the application.

Not ideal, but there were no alternatives.