Booting Disk Images in Linux

A Picture can be Worth a Thousand Words

Sometimes there is no substitute for booting a computer to gather data.  But the forensic consequences of  directly booting the system under investigation are prohibitive.  And, while it can be possible to restore a computer image to another hard drive and install that drive in the computer hard drive for booting, this can be costly, very time consuming, and you only get one shot before you've changed the data from original (and repeated boots may be desirable depending on the investigation).

In response to this, tools like LiveView were created.  The concept was to boot the forensic image, rather than restore it, and capture all system changes in a disk cache.  The operating system could be booted quickly and repeatedly from an original state.  However, I never found LiveView to be very effective, and it the past few years I have avoided Windows-based tools whenever possible .

Enter xmount by Dan Gillen.  Xmount will mount raw (dd), Expert Witness Format (ewf, aka, EnCase), and possibly Advanced Forensics Format (aff) images and create a virtual disk that can be run in a virtual machine.  Supported virtual disks are raw (qemu), vdi (VirtualBox), and vmdk (VMware).  Xmount is easy to use: its as simple as invoking the command, listing the image type, the virtual disk type desired, assigning a disk cache file, and selecting the disk image to mount.  For example:

$ sudo xmount --in ewf --out vdi --owcache disk.cache image.E?? /mnt

Of course, you've only come partway to actually booting that image.  You could try to boot the virtual disk in your virtual machine, but if it's a Windows operating system, chances are it will fail.

Open the Flood Gates with "opengates"

Windows operating systems rely on the hardware of the system in which they are installed to boot.  Thus, you cannot normally remove a hard disk drive with a Windows operating system, install it in a differently configured system, and expect it to boot.  Thus, neither will your virtual disk boot in your virtual machine, unless the configuration of the virtual machine closely matches that of the original system.  However, xmount creator Dan Gillen has a solution for us: "opengates."

Opengates is a utility to overcome the hardware limitations of Windows Operating systems.  It does several other things to make the virtual disk bootable, but one most interesting and useful capability is the removal of user passwords.  Opengates is deployed with BartPE, a bootable live windows environment.  Gillen provides very clear instructions for creating an opengates enabled BartPE disc with PEbuilder.  But in short, you need a Windows XP or 2003 machine (to run PEbuilder), a licensed Windows XP install disc, the opengates software, and about 10 minutes.

Configuring the VM

Qemu

If you are using qemu, the steps to a running VM are pretty short.  You simply setup your VM with a CD-ROM and the virtual disk.  The CD-ROM contains the BartPE disc (I use an ISO I call opengates.iso).  I use the command line thusly:

$ sudo xmount --in ewf --out dd --cache disk.cache image.E?? /mnt

$ qemu -cdrom opengates.iso -drive file=/mnt/image.dd -boot menu=on

The "-boot menu=on" argument allows a boot menu to be selected with F12.  I boot initially with BartPE, and opengates runs immediately.  You can simply take the defaults for most options, the only catches being user password removal and AntiWPA (a Windows Product Activation) workaround.  When opengates is done, it displays some necessary VM settings (but Qemu can't be configured--that I know of--with those settings), and reboots the system.

On the second boot, I boot from the virtual disk.  In a recent case, the Windows Vista Business edition did not boot under qemu, however.  So, I tried VirtualBox.

VirtualBox

VirtualBox can be deployed immediately, using the changes made with opengates under Qemu if desired.  The changes are recorded in disk cache set when mounting, and the cache can be reused with subsequent mounts/boots.  However, I'm going discuss VirtualBox as though the whole process was centered around its use.

First, xmount must be used to create the virtual disk:

$ sudo xmount --in ewf --out vdi --cache disk.cache image.E?? /mnt

Next, start and configure VirtualBox.  I recommend the PUEL edition (downloaded from the website) if you plan to use USB, and it is easier to install.  Setup your VM, using your opengates enabled BartPE ISO and the xmount virtual disk.

Boot the ISO, either by using the F12 key or by manipulating the boot order in the VM.  Use opengates to configure the virtual disk as indicated in the Qemu section above.  Be sure to note the VM settings recommended by opengates and configure your VM accordingly.  You may not find exact matching settings based on the VM you are using and the version, but it shouldn't be hard to determine and you'll make them in the System tab.  Common settings with be "Mother Board | Enable IO ACPI" and "Processor | Enable PAE/NX"

If the OS in your image was in a hibernated state, you'll likely not be able to restore it, but there is no harm in trying.  If the OS fails to load the hibernation file, it will delete it and boot normally.  If all goes well, you should boot into Windows.  Remember, all changes are being cached in your disk cache file.

Snakes in the Grass

A couple of gotchas to look out for: 

1. Make sure you are using xmount v0.4.4 if you want to use VirtualBox (v3.2.8 or later).  A bug in previous versions causes VirtualBox to reject the image.  
2. Make sure you configure your virtual machine with the settings provided by the opengates utility.  For example, I needed to configure my VM to use ACPI before the Windows Vista Business OS in my virtual disk would boot.
3. Make sure you put the virtual disk on the IDE controller.  Mine was automatically added to the SATA controller, but would not boot.

Android SMS Parsing

There are two ways to skin this cat... but one is much better!

A colleague was looking for help parsing a Android mms/sms database (mmssms.db).  It was an archived sqlite file pulled from a computer hard disk drive, apparently created through by a phone/computer sync.  The main problem was that the sms table dates were in unix epoch time (with microseconds), ant there were about 2700 entries in the sms table alone.

Initially, I  wrote a command that exported the contents of the "sms" table with sqlite using "select * from sms", read each line, assigned the date data to a variable, removed the microseconds (divide by 1000) from the date data, and used "date -d @$variable" to convert the date.  Finally, I tacked on the converted date to the end of the line.  The whole thing looked like this:

$ sqlite3 -header mmssms.db "select * from sms" | while read i; do a="$(echo $i)"; b="$(echo "$i" | cut -d '|' -f5 )"; c="$(date -d @$(echo $(($b/1000)))); echo $a\|$c; done

Effective, but not very elegant.

I suspected there was a way to convert the date in sqlite, and there was.  It took me a short while to master it, but essentially, it was "select datetime(date, 'unixepoch', 'localtime') as date from sms".  That will only get you the date from each line, however, so the full command looks like this:

$ sqlite3 -header mmssms.db "select _id, thread_id, address, person, datetime(date/1000,'unixepoch','localtime') as date, protocol, read, status, type, reply_path_present, subject, body, service_center, locked from sms"

 Still a mouthful, but much faster and cleaner output.

Finally, I decided that it would be really nice to have all the tables in the database, a total of  13, exported to csv for documentation and review.  Plus, I needed a way to remember this nifty conversion trick (the same date format is found in Firefox and Chrome histories).  So I wrote a program to automate future processing. Two of the tables, sms and threads, had dates that needed to be converted, and the program makes provisions for these tables.  You can download it here.

Previewer is Dead, long live CAINE!

A brief history...

In the summer of 2009, I created a forensic boot disc primarily intended for preview examinations of digital media called, appropriately, "Previewer."  It was based on Ubuntu 8.10 and included my home-grown tool, Ipod-ID, a bash script that searches iPod devices for evidence of ownership.  Basic use of Previewer was taught at a training event for the Central California chapter of the HTCIA in September, 2009, and investigators from four counties were in attendance.

Previewer was modeled after CAINE 1.0, a forensic boot disc targeted at expert forensic examiners.  CAINE was feature rich, but required a good foundation in computer forensics to fully utilized.  My goal was bring a basic forensic examination ability to non-experts so that criminal cases could be filed before the computer got lost in the computer lab backlog.  We debate the merits of that philosophy later.

With that goal in mind, I wrote a handful of nautilus-scripts to assist layman investigators with examination of digital media, primarily computer hard disk drives.  The Nautilus file browser was the main examination tool, the the scripts, accessed with a right click in the file pane, providing examination functionality, including the ability to save data as evidence and produce simple reports about the saved data.

A new beginning...

Fast forward to today.  Previewer remained stagnant after one revision to correct some minor issues with  some of the nautilus-scripts.  Since then, the Linux kernel has made advancements in hardware support, and the Ubuntu Linux distribution on which Previewer is based has undergone some major changes.  More importantly, mounting schemes in most forensics boot discs, including Previewer and CAINE 1.0, were found to be flawed (in limited, but none-the-less important, ways).

Increased work load and decreased personal free time caused me to turn back the inspiration for Previewer: CAINE.  CAINE has an active development team and a very capable project manager, Nanni Bassetti.  CAINE was about to update to version 2.0, and the mount issues were corrected.  I contacted Nanni and told him about my scripts and the philosophy behind them.  He took a look at the scripts and felt they would be a good addition to CAINE.

Therefore, I am happy to announce that CAINE 2.0 was release 9/14/2010.  It includes a much-improved set of nautilus-scripts from Previewer as well as all the expert tools expected from previous CAINE releases.  Anyone accustomed to Previewer should have no trouble with using CAINE 2.0, and in fact, should find it more effective and useful than Previewer.  The main "gotcha" is that the administrator account (root) now has a password (i.e, "caine").

Please contact Nanni (through the CAINE website) with comments or concerns about the main distribution.  You can always contact me regarding the nautilus-scripts (here, by email, or through the CAINE webiste).