Computer Forensic HOWTOs

Kristinn Gudjonsson has really done some great work.  He’s the author of the log2timeline script and posts forensics updates regularly.  It’s hard work detailing the steps you took, writing it up and such.  So hats off to Kristinn and the always good SANS computer forensics blog.

I decided to do some malware analysis as a part of some presentation I had to do. And since I went through the process, I decided to post it here if anyone is interested.

via PDF malware analysis.

Introduction

As everyone knows, disk I/O performance is significant factor in how quickly and efficiently a forensic analyst can perform their duties.  Often times, people try to through hardware at a performance issue and hope it “just works” out of the box.  While there can be an increase in performance by simply buying faster drives, the issue is much more complex and includes RAID controller configuration, stripe sizes, disk configuration and file system to name a few.  This article is the first of several in this series that will test various configurations in the pursuit of the highest performing array.

Problem statement

In part 1, my goal was to test the impact of stripe size on performance.  Specifically, my RAID controller supports 16kB, 64kB and 256kB stripe sizes in a RAID0 array and I wanted to understand the impact of these different settings, if any.  Additionally, I wanted to set a performance baseline by running the tests against the stock hard drive shipped with my workstation as well as a WD VelicoRaptor and a 4-disk RAID5 array.

Hardware

Below is an overview of the relevant hardware in my workstation:

• HP xw8400 workstation, 2x Intel Xeon E5345 2.33GHz Quad-Core, 8MB L2 cache (8 cores total)
• 4GB RAM
• 300GB WD VelicoRaptor OS drive, Seagate Barracuda 7200RPM “stock drive”
• 64-bit Linux (2.6.27-11-generic SMP x86_64 GNU/Linux), Ubuntu 8.10
• 3Ware 9690SA-8E SAS/SATA RAID controller
• 2 CRU Dataport 4-bay external chassis:
  • Chassis 1: 4x Seagate Barracuda 1TB 7200RPM ES2 SATA drives (ST-ST3100034NS)
  • Chassis 2: 4x Fujitsu 300GB 15000RPM SAS drives (FJ-MBA3300RC)

The Seagate drives needed this firmware updated which I did prior to testing.  Every drive was configured with a single EXT3 partition for consistency.

Test methodology

Of course, I am most interested in how the drives perform forensic tasks so I the following test script was developed to test reading and writing of both large and small files using common forensic techniques:

1. Copy 38GB dd image from different drive to test target
2. Calculate md5sum of dd image and write to target drive
3. Extract strings from dd image and write to target drive
4. Extract unallocated space from dd image and write to target drive
5. Carve files from dd image and write to target drive
6. Execute suite of iozone tests for write, rewrite, read and reread benchmarks

On steps 1-5, I used the time command to measure elapsed time.  The iozone tests were written to disk in text and Excel format and provide the basis for read/write throughput and the charts.

Summary Results

The results we very interesting and are summarized in the table below:

As you can see, a few things are immediately evident:

• The stock Seagate Barraduca drive was outperformed in every test by a factors ranging for 1-3 times faster (speed up). This, of course, was expected.
• The single WD VelociRaptor drive performed amazing well and given the reduction in cost is a great option for any forensic analyst on a budget
• The RAID5 setup with 4 7200RPM SATA drives performed very well also
• Of the 3 RAID0 configurations tested, the 64kB stripe performed the best and was the overall performance winner.  A clear example was the 3.19x speed up generating an md5sum of the dd image, decreased the total time for 2 minutes and 51 seconds (from 9 mins and 5 seconds).

Also, to accurately measure disk/array throughput I had to remove the performance boosts generated by the RAID card cache, RAM and CPU cache.  I ran iozone with parameters that created files from 64kB up to 4GB and record sizes from 4kB to 16MB.

Finally, for the RAID0 64k stripe array, the maximum read throughput iozone recorded was 4,036MB/sec (nearly 4GB/sec).

Conclusions

Given these results, a RAID0 array with 64kB stripes is the ideal configuration for my forensic workstation “scratch space”.  The next part in this series will examine the various file systems to determine which performs the best including ext2, ext3, ext4, xfs, jfs and reiserfs4.

I hope to post the iozone read and write graphs soon so check back.  Also, if you have a different setup, experience or other comments, please share.

Have you ever tried to open a 80GB file in a hex editor. The fancy GUI editors try to load the whole file…needless to say, that is rather painful. There are two great tools I use in Linux.

xxd

xxd is dumps a file in hex to the screen. If you pipe it through less, you can quickly view a file. You can also the -a option to auto skip so it’s a great way to verify that a drive has been wiped (i.e. xxd -a /dev/sdd).

hexedit

Hexedit is a Ncurses based hex editor. It is easy to navigate (arrow keys), you can tab between the hex and ASCII output and switch into edit more to change and then write a file. This is great when, for instance, working with a dd image from Apple’s iPhone. The file system is HSF/X (fifth generation HFS) and you need to change the identifier at 0×0400 from HX to H+ for most tools to recognize the file file system.

I’m sure there are other great editors people use…please let me know and I’ll try it out and post here.

Metadata (data about data) has become a fairly well known aspect in electronic discovery. There are many tools available which can read and even change metadata. So, it is with caution that a forensic analyst should use metadata. However, it can be an important step in your investigation.

Tools for metadata extraction

Google will find several million sites if you search for metadata extraction. I personally prefer open source tools so I can evaluate exactly what is happening, explain it thoroughly if required and, if necessary, modify the program. Here are a few links to sites for various tools:

• File-Word (MSWord.pm) by Harlan Carvey
• ForensicsWiki list
• Metadata Extractor
• wvWare
• DocScrubber

My preference is Harlan’s tool as it does a great job and it can see all the source (although I don’t enjoy programming in Perl all that much).

Installing File-Word and wmd.pl on Linux

So, here are the steps to install Harlan’s tool in Linux. You first must have perl installed (I’m using 5.8.8) and then use CPAN to install the necessary modules.

• perl -MCPAN -e ‘install Bundle::CPAN’ (install CPAN bundle)
• perl -MCPAN -e shell (run the shell)
  • install OLE::Storage
  • install OLE::PropertySet
  • install Startup
  • install Carp (no need to force if you get that error)
  • install Unicode::Map
• wget http://www.cpan.org/modules/by-authors/id/H/HC/HCARVEY/File-MSWord-0.1.zip
• unzip File-MSWord-0.1.zip

The package comes with a sample script called testwd.pl which is written for Windows however you can instruct perl to interpret the script and it will run fine. To run the script, simply type:

• perl testwd.pl /doc/to/analyze.doc

and the metadata will be displayed to standard out. If you get an error that the MSWord.pm file cannot be found, you should copy the file (from the zip archive) to your perl path which will be displayed in the error message.

Harlan wrote a script called wmd.pl which makes the output more reader friendly and I am posting a copy here with his permission. It can be hard to locate this file on the Internet.

Microsoft Office file formats

It may be helpful at times to reference the specifications for the various Microsoft Office file formats. With the latest release of Micorosft Office (2007), the file formats are now in XML and are a open, published standard. Prior to this format, the file formats were binary and were not as easily accessible. You may find the following links helpful:

• How to extract information from Office files by using Office file formats and schemas
• Ecma Office Open XML File Formats Standard
• Microsoft Office Binary File Formats
• Word 97 structure from wvWare notes

If you have found other tools helpful, please let me know so I can update this article.

If you primarily use Linux and The Sleuth Kit/Autopsy to perform forensic investigations, you will already know there are certain limitations to searching in TSK. The following is the approach I use to provide a more thorough search.

Overview of search strategy

In an effort to provide very thorough searches, my strategy combines indexing and bitwise (binary) searches. Indexing has the advantages of being very fast (after the index is built), the ability to understand file format and advanced searching such as fuzzy word searches (common/close spellings of words). However, relying solely on the file system can easily miss key fragments and simply will not work for unstructured data (i.e. memory images, pagefile, swap space, etc.). So, I also index raw data with a filtered binary algorithm.

Detailed steps for forensic searches

All of this “magic” is done using a combination of Linux, The Sleuth Kit and dtSearch Desktop. dtSearch is a commercial, yet affordable, searching software that runs primarily on Windows (they have a SDK for Linux but not the slick user interface). The following assume you have a dd image of a hard drive and can extract the file system. Also, I run dtSearch on Windows XP machine using VMWare Workstation. You can then allow the XP guest to access your Linux file system (read-only or read-write).

1. Mount the file system read-only on the Linux workstation (be sure your non-root account has access). For an NTFS image, I issue the following: mount -t ntfs -o ro,loop,show_sys_files,offset=32256,umask=222 /cases/case001/images/sda-img.dd /cases/fs-readonly/
2. Extract the unallocated space from the image (using TSK or Autopsy)
3. Run foremost (or scalpel) on the unallocated space to carve any files from it
4. Extract the slack space from the image (i.e. dls -s -f ntfs -o 63 -i raw /case/case001/images/sda-img.dd > /cases/case001/extracted-files/slack.dd
5. Run foremost (or scalpel) on the slack space to carve any files from it
6. Allow the dtSearch system read-only access to the mount file system and the extracted files (both the raw slack/unallocated and the foremost files)
7. Create an index in dtSearch (or multiple if you don’t want everything in one index). Allow dtSearch to index the following:
   1. read-only NTFS file system with access to all system files (very important to catch things like snapshots in System Volume Information)
   2. Raw slack file
   3. Directory with files carved from slack
   4. Raw unallocated file
   5. Directory with files carved from unallocated file
8. Start the index and get some coffee (or go to bed)
9. When complete, search away. If you created multiple indexes, you can then search allocated and carved files and the raw binary file separately. dtSearch uses a “filtered binary” approach to raw files which has proven quite effective in my cases.

I’m sure there are many other ways to approach this problem. Also, I am not familiar with commercial tools however I believe FTK uses a “lite” version of dtSearch in their product. Please share your approach to this problem.

In Linux, file systems are generally mounted by root unless non-root users are given permission in the /etc/fstab file. If you are performing an analysis and need to mount a raw file system (dd image) for review, you can issue the following command as root:

mount -t ntfs -o ro,loop,show_sys_files,offset=32256,umask=222 /cases/case-sense-net/tag1/tag1-img.dd /cases/fs-readonly

The will mount the image file (generated by dd, dcfldd, dc3dd, etc.) in /cases/fs-readonly and will allow non-root users to view all of the files and directories. The key is the umask=222 which sets the permissions on the mount file sytem to 0444, or read-only for all users but able to change into subdirectories.

Doing Mac/iPhone forensics, you will eventually need to examine the contents of a disk image which Apple stores in a .dmg file. Here’s some information on the files and how you can mount them.

.dmg file information

The two types of .dmg files I have come across are a uncompressed file and a compressed one. The file command for both are as follows:

Uncompressed:

ahoog@wintermute:~$ file stage1-decrypted.dmg
stage1-decrypted.dmg: Macintosh HFS Extended version 4 data last mounted by: ‘10.0′, created: Fri Aug 29 00:33:37 2008, last modified: Fri Jan 2 11:07:50 2009, last checked: Fri Aug 29 02:33:37 2008, block size: 4096, number of blocks: 6400, free blocks: 218

Compressed:

ahoog@wintermute:~$ file stage2-decrypted.dmg
stage2-decrypted.dmg: VAX COFF executable not stripped – version 376

Mounting the .dmg disk image in Linux

To mount the uncompressed image in Linux, type the following:

mount -t hfsplus -o loop stage1-decrypted.dmg /mnt/dmg

Using the loop device, you can mount the file and then modify it as needed (or mount read-only) and then umount (all changes are preserved if in read/write mode).

Mounting the compressed .dmg disk image required an additional step. I came across a utility called dmg2img which uncompressed the image. So you now use the following commands to mount the image:

dmg2img -i stage2-decrypted.dmg -o stage2-decrypted-uncompressed.img
mount -t hfsplus -o loop stage2-decrypted-uncompressed.dmg /mnt/dmg

Other operating systems

It’s worthwhile to note that in Apple’s OS X, you can simply double-click the .dmg file and it will mount. However, this is not forensically sound and you should not do this on images that require read-only.  For read-only and other options,  you can use the hdid or hdiutil commands. In Windows, apparently you can use a program called MacDrive (in Target Disk mode) however I have not verified this.

While performing forensic testing on an 3G iPhone using the techniques outlined by Jonathan Zdziarski in his book “iPhone Forensics“, I discovered the xpwn tool (by planetbeing) pre-compiled for OS X was not up to date (missing many of the firmware bundles which contain the encryption key and initialization vectors to uncompress the RAM disk .dmg images). I switched over to the Linux workstation however the Linux pre-compiled binaries of xpwn complained about my version of GLIBC with the following error:

/home/ahoog/src/XPwn-0.5.5-Linux.broke/xpwntool: /lib32/libc.so.6: version `GLIBC_2.4′ not found (required by /home/ahoog/src/XPwn-0.5.5-Linux.broke/xpwntool)

So I figured I would just build from source. Planetbeing was nice enough to write up build directions however for my Debian Etch, I had to do a few different things to get it to compile and work. Below are the steps I took to make everything work, adapted from Planetbeing’s direction:

1. apt-get install build-essential
2. apt-get install libz-dev libusb-dev libssl-dev libbz2-dev libpng12-dev (changes from planetbeing’s BUILD doc listed below)
   • libssl-dev instead of libcrypt-dev
   • libbz2-dev instead of libbz2-dev3
   • added libpng12-dev
3. Install git-core and associated files to download the source (GitHub kept failing with a 404 when trying to download from the website link)
   • apt-get install git-core git-arch git-cvs git-svn git-email git-daemon-run gitk gitweb cogito git-doc rsync curl
4. git clone git://github.com/planetbeing/xpwn.git
5. install cmake (per BUILD)
   • wget http://www.cmake.org/files/v2.6/cmake-2.6.2.tar.gz
   • tar zxvf cmake-2.6.2.tar.gz
   • cd cmake-2.6.2
   • ./configure
   • make
   • sudo make install
6. Create and cd to build folder
7. cmake ~/xpwn
8. make
9. make package
10. executables and files located in ~/build/_CPack_Packages/Linux/TBZ2/XPwn-0.5.5-Linux

Hope this helps Debian/iPhone folks out.

The first time I tried to mount a Mac OS X partition in Linux, I ran into several issues. Here were the problems I had and the resolution.

HFS+ partition structure

Man computer forensic jobs are on Windows or even Linux computer which use the DOS partition structure. So, the first time you come across a Apple partition, things look a bit different. The following are the partitions, as seen by mmls and parted, on a HFS+ USB drive:

mmls output

wintermute:/mnt# mmls /dev/sdc
MAC Partition Map
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  -----   0000000000   0000000000   0000000001   Unallocated
01:  00      0000000001   0000000063   0000000063   Apple_partition_map
02:  Meta    0000000001   0000000004   0000000004   Table
03:  01      0000000064   0000262207   0000262144   Apple_Free
04:  02      0000262208   0160086511   0159824304   Apple_HFS
05:  03      0160086512   0160086527   0000000016   Apple_Free

parted output

wintermute:/mnt# parted /dev/sdc
GNU Parted 1.7.1
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print

Disk /dev/sdc: 82.0GB
Sector size (logical/physical): 512B/512B
Partition Table: mac

Number  Start   End     Size    File system  Name                  Flags
1      0.51kB  32.8kB  32.3kB               Apple
3      134MB   82.0GB  81.8GB  hfs+         Apple_HFS_Untitled_1

HFS+ partition and journaling

When you mount the HFP+ partition, you issue the following:

wintermute:/mnt# mount -t hfsplus /dev/sdc3 /mnt/sdc/

and while everything looks good from mount:

wintermute:/mnt# mount
/dev/sdc3 on /mnt/sdc type hfsplus

the journaled filesystem has actually caused some issues. You notice this is you want to write to the drive or if you look at dmesg:

sdc1: rw=0, want=262211, limit=63
hfs: unable to find HFS+ superblock
hfs: write access to a jounaled filesystem is not supported, use the force option at your own risk, mounting read-only.

Disabling journaling on HFP+ file system

If you need to write data to this drive (helpful as I move files between Linux, Windows and OS X forensic workstations), you can remove the journaling from the file system. This is not recommended for the system partition on a Mac but is fine for a data drive. Of course, understanding the benefits of a journaled file system for data recovery is important. Anyway, to remove the journal I issued from following command on my OS X workstation per Apple’s support article:

neuromancer:/Volumes root# /usr/sbin/diskutil disableJournal /Volumes/mac-backup

Write away

Placing the drive back in Linux and mount with the same command as above resulting in a writable HFS+ partition on my Linux workstation:

wintermute:/mnt# mount
/dev/sdc3 on /mnt/sdc type hfsplus (rw)

I recently had the need to decode the Yahoo! Messenger archive files (.dat) from a suspect’s computer. I did not come across any nice, command-line, OSS packages but here’s what I did find (and use).

Explanation of Yahoo! Messenger Archive format
This site has a nice write-up on the format of the Yahoo! Messenger Archive .dat files.  This is helpful if you want to decode them by hand or add the signature to foremost.conf for file carving.  It’s interesting to note that the messages at XOR’d with the user name.

Ikitek Software

Yahoo Message Archive Decoder by Ikitek Software is the first package I found and trusted enough to install.  The application worked fine after I provided the entire profile directory (default location of C:\Program Files\Yahoo!\Messenger\Profiles) instead of just the archive directory.  The help menu has an interesting section about heaven but I stuck to the task at hand.

Piravi Software Solutions

Super Yahoo Messenger Archive Decoder by PIRAVI  Software Solutions was a second program I installed.  The distinctly un-Web 2.0 website was targeting a distinctly different audience than the forensic analyst.  Nevertheless, I install the program and it worked equally well.  The user interface was a bit kludgy but it seemed to have more features.  The command line option (which comes with the paid version) would be useful for examinations to enable scripting.

Other options?

Perhaps you have come across other options?  Please share.  I installed (and promptly removed) the open source Yammy software because it ran a mini-webserver locally and required that Yahoo! IM was installed.