Stumpy- you mention CP cases which I assume head to some sort of trial and you use Linux for examinations, so it looks like you haven't had this problem.
I think another important thing here is that a pile of bits is a pile of bits, a link file is a link file, a jpeg is a jpeg, as long as your chosen tool correctly reports their state and location of those bits then the antecedents of the tool shouldn't be (and in my experience, aren't) an issue. In fact, I can't recall any court case when the tools were even discussed, maybe that is just a UK thing?
My experience is that defence council don't question the tools, per se. It doesn't really matter what tool you use (IMHO) as long as it is reliable, one way to determine reliability is to verify with another tool. Ultimately the test comes down to this What piece of evidence you found and where it was on the disk. If defence council were to question the reliability of any tool (Linux, Windows, proprietary or OSS) that I use, I would point to the evidence and say something along the lines of "I found piece of evidence X at physical sector(s) Y, if you look at that location with any forensic tool you will find it too".
In fact it would be interesting to have a discussion with defence council about the reliability of the tools. Last week I used a Windows based forensic package (probably the market leader) to do some analysis on a disk image. In 8 hours of work I stopped counting when I got to 20 crashes or system hangs, switched over to Linux used and achieved what I needed to in about 40 minutes, no crashes, no hangs, no worries. IMHO, if your system crashes whilst your case is open then you really need to verify the integrity of your image and case file again, just to make sure nothing got corrupted (I have certainly had occasions where all my bookmarks are messed up after a system crash using said Windows based tool). I really envy anyone who has time to do this, I don't know anyone who does do this though, purely through time constraints. On that basis, I would be far more confident of presenting a case done with software that didn't once crash, hang or do something unexpected, which I generally find is the case with Linux tools. In my experience, anything that goes wrong is normally down to me, rather than the OS or tool.
In respect of a tool for parsing .dbx files, I have found this
http//
You will have to edit the makefile to get it to compile, but initial results seem to be pretty good. It seems to parse the email header information out into a csv file and parses the email content into text files.
The main problem, so far, seems to be that it names the parsed text files 0000.txt, 0001.txt etc for each dbx files. As you can only specify 1 output directory, if you tray and loop through the file system on a mounted drive and parse the .dbx files on the fly it will overwrite the text files from a previously parsed .dbx file. Any suggestions how to overcome that, so that all the .dbx files can be found and parsed out into the same directory on the fly?
wow- looks like I hit a hot topic with a few people. I appreciate the feedback from everyone about the myths of OSS vs commercial products in the courts.
As I said, I don't have experience with this in the real world, so I look to forums like this for info from those that have the experience.