The high cost of computer forensics software, your tax dollars NOT at work

Finding quality tools is tough, particularly if you’re an independent practitioner or a small company. One tool at $1,000 to $2,500 is affordable, but we need an entire toolbox full of tools and they’re all trending towards $1,000 and 20% per year maintenance. Pretty soon you’re out $20,000 up front and then $4,000 per year to stay current. OSS and free tools are awfully welcome.

Thankfully, if you’re a US citizen, your tax dollars paid for the development of an OS X forensics tool called MEGA. (paper) Quoting from the paper: “This project was supported by Award No. 2007-DN-BX-K020 awarded by the National Institute of Justice….” Very cool, right? Alas, MEGA morphed into Mac Marshal and went commercial. (And when did this happen? The MEGA paper includes screenshots of the tool with the label “Mac Marshal” rather than “MEGA”.)

So go to the Mac Marshal web site where you find:

“Because of a special arrangement with the U.S. National Institute of Justice, Mac Marshal is available free of charge to U.S. Law Enforcement personnel. If you qualify, please use the instructions below.

Mac Marshal is available for purchase by the private sector, and law enforcement agencies outside of the United States, from Cyber Security Technologies.”

So, if you’re in law enforcement, you can get a copy of it for free. If you’re not LE, you get to pay $995 to Cyber Security Technologies for it. (order form)

Wait, didn’t I already pay for at least some of this tool through my tax dollars? I can see a private developer deciding to give their product away for free to LE, and corporations discounting the product to the government on GSA schedules. But in this case, the tool was developed using US tax dollars, and the price to the public isn’t just recovering costs, it is making a substantial profit.

It gets more interesting….

I got onto this because I was working on vfcrack (Google Code link, OpenCiphers link), a tool to brute force the encryption on DMGs. It’s a bit out of date, and I thought I’d bring it up to speed. Turns out that this has already been done – as part of Mac Marshal.

“Mac Marshal also include a modified version of vfcrack [11], which enables fast dictionary-based brute-force password cracking of FileVault sparseimage and sparsebundle images, as well as other encrypted Apple disk image formats (the original distribution of vfcrack does not support sparseimage and sparsebundle images).” (citation)

So there is open source code in Mac Marshal that may have been updated at the taxpayer’s expense but not been returned to the public domain. The vfcrack license doesn’t explicitly prohibit this, but MacMarshal’s developer’s refusal to put the updated code back in the public domain certainly seems to be in bad form.

A couple of suggestions if you accept tax dollars to support the development your tools:

1. Price the resulting product so that the independent practitioner can afford to buy it without having to really think about it too much. A range of $200 – $300 I can see, but $995 is getting greedy. $200 covers distribution costs, the web site, answering questions, and the like.
2. If you use open source code in your tool and update it, put the updated code back in the public domain for the rest of us to use. It costs you nothing to do so, it earns you good will, and we (the taxpayers) paid for some of that development.
3. Remember that we are all working for the public, not just law enforcement. These tools are obviously used in civil matters, civil matters involving the same taxpayers.

And suggestions to tool vendors in general:

1. Price your tools so they are affordable. We (small companies) aren’t going to drop $1,000 on a tool without thinking about it, much less $2,500 or $5,000. My gut (biased, I’ll admit) says that if some vendors dropped their prices significantly, they’d get a boost in sales that covers the decreased per-unit profit, and they’d get their product into more peoples’ hands, which would lead to more sales. (Or am I being idealistic?)
2. Don’t discount the influence of someone who appears “small”. Many of us have clients in larger firms, and all of us talk (a lot) amongst ourselves. Check the CCE and HTCIA lists, look at Forensic Focus, go to the forensics conferences and talk to the smaller companies.
3. Invest in the long term. The small customers you win over now, and who you help do better work so they can be more profitable in the future, will be your beta testers, promoters, and recurring customers in the future.

None of what I describe here is against the letter, or even the spirit, of the law. It probably even falls under “good business practices”. But in charging a premium for a tool that was funded in part by US tax dollars, and in taking public domain code and not returning the changes to the public, the pricing and failure to publicly update code borrowed from the public domain seems contrary to the spirit of the digital forensics community.

Updated analyzeMFT now with binaries! (And the tools required to get there.)

I finally figured out how to build a standalone executable after an Alice in Wonderland run through redistributable libraries, py2exe, and Windows installers. There are still some issues, but it works well for the most part. Check the Download section on www.integriography.com.

Some tools that helped me turn a Python script into something that can run on any (most?) Windows systems are:

1. py2exe – http://www.py2exe.org/ – Read the Tutorial page for some really good help with the .dlls
2. Dependency Walker – http://dependencywalker.com/ – A great tool for determining what modules your application depends on
3. Inno Setup – http://www.jrsoftware.org/isinfo.php – A very simple yet powerful tool to build installation packages

Updated analyzeMFT, $MFT sequence numbers, and NTFS documentation

analyzeMFT updates:

At the request of Harlan Carvey and Rob Lee I made some changes to analyzeMFT and fixed a few bugs along the way.

• Version 1.1: Split parent folder reference and sequence into two fields. I’m still trying to figure out the significance of the parent folder sequence number, but I’m convinced that what some documentation refers to as the parent folder record number is really two values – the parent folder record number and the parent folder sequence number.

• Version 1.2:
  • Fixed problem with non-printable characters in filenames. Any Unicode character is legal in a filename, including newlines. This presented some problems in my output. Characters that do not render well are now converted to hex and a note is added to the Notes column indicating this.
  • Added “compile time” flag to turn off the inclusion of any GUI related modules and libraries for systems missing tk/tcl support. (Set noGUI to True in the code)

• Version 1.3: Added new column to hold log entries relating to each record. For example, a note stating that some characters in the filename were converted to hex as they could not be printed

The code and more details are available at www.integriography.com

Quick note on $MFT sequence numbers:

Microsoft tells us that each record in the $MFT has a FILE_RECORD_SEGMENT_HEADER Structure. Within this structure is a sequence number, defined as follows:

“This value is incremented each time that a file record segment is freed; it is 0 if the segment is not used.”

Ok, that’s pretty straightforward. At least until you look at teh first 16 entries in any $MFT as all of their sequence numbers match their record number. I’ve been told that since these files can never be deleted, repurposing the sequence number adds an additional sanity check and disaster recovery option. However, I’ve found one volume where this behavior continues for 12,000 records or more. Still looking into that one.

NTFS Documentation:

One of the best sources for NTFS documentation isn’t Microsoft, it comes from the Linux NTFS developers and is available here.