Trying to Catch Me Mounting Dirty

Today I had to quickly forensically image an IBM Thinkpad for one of the forensic experts with which I work.

Because of a screwy cd drive on the laptop, I couldn’t just boot into the Sid / Knoppix-based Helix CD and use LinEn to image, but rather had to remove the hard drive, break out my newly purchased UltraKit write blocker kit, and image it that way (which, while more forensically sound, takes much longer to do).

Overall, the Ultrakit is fairly straight forward. In one side of the Tableau IDE write blocker, you plug in an IDE cable, which plugs into the IDE converter for your little IDE laptop hard drive. In the other end, you plug in your A-A USB cable, which plugs into your computer’s USB port. In the computer’s other USB port, you plug in your target USB drive (a 500 GB Seagate, in my case). Lights on the Tableau clearly tell you that everything is working ok (disk activity, connection to host, write blocking enabled, power, etc).

About an hour into imaging the laptop hard drive, I decided to kill the job and start the process on a laptop that was significantly faster. Bad idea — something I should have know better than do! Unplugging and rebooting Helix must have resulted in some sort of dirty dismount, because after booting on the new laptop and mounting the same Seagate 500 GB hard drive with ntfs-3g, I couldn’t seem to write properly to the drive without some sort of “input/output” error. Instead of using Sid’s ntfstools to “fix” the problem (which I’ve done in the past), I just used an XP Pro workstation to quickly format it again.

I then tried to use my Intel-based Macbook Pro for the imaging, but for whatever reason, Helix wouldn’t boot past the basic Grub menu. Instead of trying to figure out why, I just finished the job on my HP laptop.

For those new to the process, here are some steps I did to image the drive (most importantly, I guess, is NOT to mess with the connection once you start the image transfer!).

(1) Quickly format the destination USB hard drive to NTFS. Since I don’t completely trust the NTFS tools, I most always use Windows. (One recommended step before this is to zero out the hard drive in Helix by typing [something like] dcfldd if=/dev/zero of=/dev/sda bs=8k conv=noerror,sync, of if you want to securely wipe it, type something like wipe -kq /dev/sda)

format e: /fs:ntfs /q

(2) Once in Helix, check out which devices the operating sees (but may not have mounted).

fdisk -l

(3) Say it’s /dev/sda (I sure hope so, or you’ve zero’d out the wrong hard drive!), let’s make sure that it’s completely dismounted. If not, then we will need to do close or kill anything else in Helix which may be accessing that USB drive.

umount /dev/sda1

(4) Create a folder that we can later mount to, as well as a folder within it that we can put in the forensic images we get from LinEn.

mkdir /mnt/bigUSB
mkdir /mnt/bigUSB/forenicImages

(5) Now, let’s map that USB device in /dev to the aforementioned folders.

ntfs-3g /dev/sda /mnt/bigUSB

(6) Once you mount that folder, you are ready to acquire an image with LinEn. Start it and select the /dev devices which you are imaging (not the hard drive that will be written to). Now, when you enter your save path, enter:

/mnt/bigUSB/forensicImages

(7) Enter in all your forensic notes, and then sit for a while.

Le voila! On fairly mediocre laptop, it took about an hour for every 20GBs. Afterwards, you can use the hashing tool to make hashes of the attached hard drive to ensure that nothing was lost or altered in your images.

While I used NTFS (because I had some ~50 GB EDB file), it’s important to note that Guidance Software, the makers of Encase, suggest using FAT32 on the target drive (which can be done by typing something like mount -t vfat /dev/sdb1 /mnt/bigUSB). I suspect that this is a result of portability, as FAT32 is a sort of “lingua franca” when it comes to file systems. Also of interest to forensic types is the wide array of other tools out there for making Encase images, some of which claim to make Encase images faster than LinEn.

Update: One extra step you should perform when doing forensics is computing and writing down the hash of the entire partition (this, of course, assumes that sdb [2nd USB drive] is your ’suspect’ drive, not your target drive).

e.g.

md5sum /dev/sdb
sha1sum /dev/sdb