Last September, Graduate Assistants, Amy Wickner from SCUA and myself from DSS, began working with the Forensic Recovery of Evidence Device (FRED), with the goal of creating a workflow for processing born-digital media. Since born-digital material is still fairly new to libraries there is no widely accepted ‘way of doing things’ and there are few case studies on how libraries and archives have handled the issue. Ours was a process of trial and error, informed by the literature and online forums. We kept a daily log, which featured the word ‘failed’ regularly, but we have continued to make progress despite these challenges.
Our first question – which disk imaging program is most effective; BitCurator or Forensic Toolkit (FTK) Imager? BitCurator is an open source Linux-based environment for creating and analyzing forensic disk images, which are bit-by-bit copies of digital media. FTK Imager creates both forensic images and logical images (only containing the logical volume, excluding deleted and orphan files) and is the free imaging component of the larger proprietary FTK.
We began with a small flash drive containing 6 files, including many file types (jpg, xls, doc, pdf). Since the item was so small there was little difference in imaging time, but BitCurator won by 14 seconds. Next we imaged a much larger item, a hard drive containing a terabyte of data. This is where we faced our first major hurdle, one we continue to struggle with: mapping the local area network (LAN). Since this hard drive was too large to image directly to FRED, we needed the LAN to store the disk image. Since FRED is partitioned to include Linux and Windows we needed to connect both sides to the LAN. This Windows partition connected fairly easily, however the Linux partition requires the user to connect via the terminal. Since neither of us are Linux experts we relied on a script provided by the original Born-Digital Working Group. Although this script was unsuccessful, it was a good starting point and after a self-led crash course in Linux and Bash scripting we were able to connect BitCurator to the LAN and we began disk imaging. Surprisingly, FTK was faster in imaging the larger volume; 2- 4 hours faster depending on if the image was forensic or a logical image.
The next step was in analyzing the images. Although FTK can provide some information about the image, BitCurator has a more robust reporting tool which scans for Personally Identifying Information (PII), reports on file types, and shows paths for deleted files. The first report matched what we already knew about the original media. When we ran the reporting tool a second time on the same disk image we discovered inconsistencies with the previous report. We are currently in communication with the BitCurator team, but this problem has not yet been resolved. Until we have consistent reports we cannot rely on this tool for analyzing disk images.
After the most recent update to BitCurator we had to re-connect the Linux partition of FRED to the LAN. Although we thoroughly documented our previous work with the issue, this new attempt was more problematic and we ultimately failed in fixing the problem ourselves. We are currently working with User Systems and Support to resolve the problem, but in the meantime we cannot access disk images stored on the LAN for analysis in BitCurator.
These challenges show how much the success of one project relies on a network of experts both internal to UMD Libraries and external groups like the BitCurator team and other users who posted their experiences online. All of these groups have been vital to continuing our work. Although there were challenges, many of which are still problematic, we continue to make progress and hope to have a revised workflow complete by the end of the summer.