Forensic Image and Video Extraction Support (FIVES) Project

While working with the Open Computer Forensics Architecture (OCFA), I came across the Forensic Image and Video Extraction Support (FIVES) project. At the time, REAPER was in the proof of concept stage, and I was thinking more about automated imaging and verification than image and video processing, but with interest in REAPER Preview, image and video detection became more important. Eventually, the developer of Automated Network Triage (ANT) reminded me of FIVES. Taking a closer look, they have some tools, such as face detection and age estimation (using OpenCV) that was exactly what I was looking for. What makes the project even better is the fact that each of the tools are modules that can be plugged into OCFA. I am working on giving REAPER preview a smaller memory footprint, integrating some of the new Sleuth Kit features, and will definitely be trying out some of the FIVES tools.

~1 min read

Installing a Eucalyptus Cloud with Debian Squeeze

When trying to install Eucalyptus on Debian, the newest version seemed to be packaged for Squeeze. I tried this directly on Lenny, but it did not work. I have never had luck trying to upgrade from Lenny to Squeeze. I suggest a new install rather than upgrading. Squeeze (testing) can be found here:

Just completed the install with Squeeze RC1 with no problems.
Eucalyptus hosts its own repository for Squeeze, which makes everything much, much easier. Also the documentation is pretty good, so this part will mostly be links.
<li>Install the front-end cloud controller and any nodes (nodes can be added later)</li>
<li> Next I suggest installing Euca2ools at the same time since you will need them anyway</li>
<li> Restart the hosts</li>
<li> Go to the first time setup to designate the front-end and join nodes to the pool</li>
<li> You should have logged into the front-end to see the first-time settings and change the admin password. Make sure you downloaded your credentials onto the front-end machine, and you have sources the key info file.</li>
<li> Now you will need an image. I suggest going to the repository and selecting one yourself to start out with.</li>
<li> Once you have an image, then add it to Eucalyptus</li>
<li> Make sure the service is running on the nodes: /etc/init.d/eucalyptus-nc start</li>
<li> See this documentation section 4 for a quick start for an instance</li></ul>
That should pretty much do it without any fancy configuration options (such as elastic IPs).

1 min read

Converting Parallels Disks to Raw on OS X

Update: See the forensic focus article:

Update: I have had problems with this method leading to corruption / being unreliable. Backup all your data before you attempt this.

We do quite a bit with parallels, and commonly want to copy a virtual disk for analysis. If you come across a machine with parallels disks, how do you copy a usable image file out? Parallels is set to use expanding disks by default, which are apparently compressed. Digfor talks about finding parallels on a Windows machine, and how to convert the disk. I will just cover the process on OS X (very similar).

Edit (7-12): An easier and faster way is to use ‘qemu-img’. I might try to create a how-to on it in the future, but it is pretty straightforward.

Essentially we want to locate the .hds file. In Mac the image is usually in the .pvm package (unless location was manually specified).
<li>Right click on the .pvm file, and click "Show Package Contents".</li>
<li>Move the .hds file to the .pvm directory</li>
<li>Rename the .hds file to OS.hdd (OS can be whatever is meaningful to you)</li>
<li>Open 'Applications/Parallels/Parallels Image Tool'</li>
<li>Choose the new disk image "OS.hdd"</li>
<li>Choose "Convert to plain disk"</li><ul>
<li>Note: This will expand the disk to its "true" size. Make sure your drive is big enough</li></ul>
<li>The converted disk is once again called OS.0.{###}.hds</li>
<li>The resulting file is now raw</li></ul>

img_stat ~/Documents/Parallels/Windows\ Server\ 2003.pvm/Windows\ Server\ 2003.hdd/Windows\ Server\ 2003.hdd.0.\{5fbaabe3-6958-40ff-92a7-860e329aab41\}.hds
Image Type: raw

Size in bytes: 8590675968

Note: You can also use Parallels Image Tool to split and combine the image file - though dd gives you more options.

1 min read

Profile Based Digital Forensic Preview

The newest build of REAPER Preview (officially Alpha 2) includes quite a few changes, but one that I am especially excited about is Profile Based Preivew. First I will describe the new REAPER Preview process:

REAPER Preview is designed to be highly-automatic preview. When REAPER Preview starts an ‘autorun’ profile is detected. Any file type filters, hash databases, and keyword lists that an investigator always wants to search for, are automatically scanned. These lists, obviously, need to be pre-set by by an experienced investigator for items that ALWAYS need to be scanned for. This profile should be extremely generic.

While the automatic profile is running in the background, the investigator can choose a specific pre-created profile. A specific profile could be, for example, exploitation, hacking, financial, etc. Each of these profiles would have specific hashes, keywords and preferred file types to search for. By creating a profile you not only control what is automatically searched for, but what and how found items are displayed. For example, in an exploitation case hashes and images might be the most important, where music files may not be relevant. You can choose to remove music as a display option, forcing the first responder to focus on images/hashes (since that is all they have access to). The scanning is automatic so they do not need to do anything except click the link of the profile they would like to view.

I often hear that generic keyword lists make no sense. To my knowledge there has not been a study linking keyword lists to profiling machines. I know investigators that have certain keyword lists in their heads for certain types of cases… why not use these to attempt to profile a system? I do, however, see the need for manual keyword searching since static keyword lists would not include names, etc. Because of this each profile also supports manual keyword searching against file names and full disk.

Essentially REAPER Preview is a tiered system, from highly-generic (autorun profile), to case-type specific (pre-set profiles), to incident specific (manual searching). I believe these three layers of abstraction can help an investigator quickly dig deeply into a system while not missing important information that might be more general.

I welcome you to try REAPER Preview yourself - it can be downloaded from the REAPER Forensics project page:

Any and all feedback is most welcome! Want to see a specific feature? Found a problem? Let me know!

2 min read

REAPER Preview Alpha 2 changelog

Gearing up for the official Alpha 2 release of REAPER Preview here is the change log and feature list:

<ul><li>REAPER Preview no longer loop-mounts suspect drives. All data is parsed directly from the raw disk. This not only faster, but we also do not need to worry about the issues talked about here.</li><li>Suspect disks are still set to read-only at the block level</li><li>Back-end is structured in a much more modular way. Programmers could easily insert a certain tool into the work-flow, if necessary</li><li>Preset automatic keyword searching</li><li>Preset automatic hashdb searching</li></ul>Front-End:
<ul><li>Whole code re-write. Front-end is now completely modular. Add or remove items with a simple include</li><li>Triage profiles supported! Will explain the concept of triage profiles in the next single</li><li>Greatly-improved Image/video gallery from Dynamic Drive implemented. The automatic image gallery I wrote was not powerful enough, and theirs is very nice. (Video previews are currently not working since the back-end switch).</li><li>Manual file-name and full disk keyword searching now available</li><li>Improved session logging (non-persistent)</li></ul>

~1 min read