Monday, November 9, 2009

Microsoft COFEE - Much ado about nothing

The entrance to Microsoft's Redmond campusImage via Wikipedia
Well the big story today is that Microsoft's law enforcement only tool, COFEE has been leaked to the internet and is a big hit on the torrent download servers.

I did not bother to locate a download source for it, since I am not supposed to have a copy of it.  However, I did locate a link to the user manual on an official law enforcement website, which I shall not name or link to here.

With so much hype about the wonders of this tool, I was pretty disappointed when I read the user manual.  Basically all it is, is a shell on a USB Windows FE stick for the free tools you can get anywhere, including some of the old sysinternals, aka Winternals..

To be honest, law enforcement agencies would be better off using Helix 3 Pro or Drive Prophet.  There is a free LEO version of Drive Prophet available from the DOD Cybercrime folks who purchased a license for the purpose of distribution to law enforcement agencies.

And of course there is the new commercial version of Drive Prophet that was just released by our company, Guardian Digital Forensics.

From what I saw in the user manual, it is not even that easy to use.  Built for untrained first responders, I did not see anything in the examples given that would be useful to anyone other than a trained person who can interpret the information.

It is interesting to read some of the message board posts talking about the leak.  This is probably a good thing since most of the posts I read on various boards were completely clueless about what COFEE does and is for even after they downloaded and ran it.

It is certainly not what I expected to see.  I was expecting a tool that provides something closer to what Drive Prophet does: extract and generate reports that are immediately useful to the first responder.  Digital triage that can be used and is useful for anyone without the need for training in interpreting a bunch of cryptic reports.

Now that the mystery is solved, at least in my case, I can stop wondering what magic Microsoft has developed to advance the forensics field.  The answer is; none at all.

Reblog this post [with Zemanta]

Tuesday, November 3, 2009

Tool Versions in Court Cases: Three Criteria for Any Forensic Tool

I recently spoke at the 2009 Techno-Forensics conference on the subject; "Challenging the law Enforcement Examiner, What a Defense Expert Sees".

During the Q&A period, someone asked me if I used the same version of the tool used by the law enforcement examiners when I did my examination.  I.e. did I use Encase 4.0 if they used it in their examination?

I thought it was such an interesting and timely question that I would write this post.

When I attended computer forensic training, a big deal was made about noting the version of the tool used for the examination so you could go back and duplicate the results or so it could be independently verified at a later time by someone using the same tool.

While that seems logical on the face of it, it really is not.

I use the latest verified version of the software I have at my disposal.  Simply because I want to have the latest optimization and features that will allow me to do the most thorough examination possible.

Restricting myself to older versions would be a disservice to my clients.

However, I think that it is important to explain my answer a little more fully here as I did at the conference.

Any tool being used to gather and present evidence in the digital forensics field must meet three requirements:

  1. 1. Predictable
    •  In order to create any sort of tool that finds or recovers data from a digital source, the tool must take advantage of the predictable nature of the source.  In other words, if you cannot predict that a Microsoft Word file will have certain predictable characteristics, e.g. the header and footer, then how would you be able to write a tool to find the documents? Or how would a tool be able to tell of a JPG picture file was renamed to disguise its nature?
    • The same thing is true for verification of captured evidence.  The calculation and comparison of the MD5 or SHA-1 hash value of the file must be predictable for hash analysis to have any meaning.
  2. Repeatable
    • If a tool or process is to have any value, it must return the same result each time.  In other words, it must be a highly accurate, repeatable process.  No matter what tool is run, if the tool is accurate, it should always get the same result and should get it every time it is run against an evidence set.
  3. Verifiable
    • One of the things we talk about a lot in this field is verification of tools.  Especially tools that are used to gather and vet evidence.  If the tool or process cannot be verified that it meets the two conditions above, then the tool cannot be used in a forensic process.
Looking at the three conditions above, then any tool used must produce the same result when examining the same data.  Specifically, if one examiner reports having found a file of a type, of a certain size and at a particular sector and offset, then any examiner should be able to locate and reproduce that exact evidence with any forensic tool.

If that is not the case, then there will have to be a resolution as to why the evidence presented does not meet these criteria.

  1. Did the examiner make a mistake?
  2. Was the tool used not reliable? (Did not meet the three requirements above.)
  3. Was the evidence finding simply reported incorrectly?
  4. Is there a difference in the original evidence that is not reflected in the forensic copy?
In most cases that I have done, the error is on the human side, not on the tool side.  Failing to follow good practices, or simply not understanding the tool being used are the biggest problems I see on a day to day basis.
Reblog this post [with Zemanta]

And the winner is....

Congratulations to Luby Novitovic of the Chicago Inspector General's office on his winning the Drive Prophet giveaway.