Disk Restoration and Computer Forensics

I got a new hard drive to replace the drive in my laptop's hard drive caddy today.  I wanted to copy the data from my existing drive exactly as it is to my new hard drive and I figured this may be a good time to discuss Disk Restorations.  It's most applicable for general IT purposes but can be very helpful for doing forensics as well.

The concept is simple, I can create a perfect duplicate of a suspect hard drive.  I can then place the duplicated hard drive into the suspects machine, keeping the suspect hard drive disconnected and then boot that hard drive to see exactly what the user would have seen.  If your suspect machine is Windows based this may be the easiest way to get a good look at the environment because it is very difficult to make a virtual machine from the evidence file.

Lets get started.  I started this process in Windows with EnCase Imager to show how it can be done using EnCase (note I was doing it direct hard drive to hard drive with no write block protection which is NOT forensically sound).  Below you can see the lack of space.  I was duplicating the "Data" volume onto a new 1TB drive.

Next I opened EnCase Imager (Guidance Software) to add the disk to the "Case".  Below you can see the default EnCase Imager screen.

Here we will be selecting the "Add Local Device" link.

On this screen I deselected everything.  For forensic purposes you should have the device write blocked.

Here you can see I have selected disk "1", containing the volume "Data" and the new disk ("3") below it.

After selecting the drive and clicking next we can now see and navigate the disk and its content.  Most of the EnCase capabilities are not present in the Imager but the core interface is the same.

To start the restoration process we need right click on the disk, select "Device" and "Restore..."  Had we been wanting to create an E01 (EnCase Evidence File) of the device we could have used the "Acquire" option here.

It will now ask you before populated a list of disks.

Here I've selected the disk I wish to restore to.

Because this is not a case I disabled the "Wipe remaining sectors on target" option.  If I had been doing this for a case I would have left this option selected because it is not forensically sound to have any data on a disk being used to host suspect data.  The reason for this is related to how a disk stores data.  If you do not wipe the remaining data it is possible for data carvers to recover files that are not on the original disk.  We call this cross contamination.  Note: wiping the remaining sectors will take a very long time because it is writing h/00 across the entire disk, then verifying that it has been written.

Obviously if you have any other data on this disk it will be destroyed (particularly if you zero the remaining sectors).

Once the process has started you will see it in the bottom right hand corner.

I cancelled this process because it would have taken over 15 hours and I wanted to cover how to do this with the Linux tool dd.  The first thing I needed to do was identify which drive was which.  Using Ubuntu's Disk utility I am able to see which disk is which disk is which "/dev/sdb" and "/dev/sdc" are the disks that I am using with sdb being the source and sdc being the destination drives.  It's important to note that I'm not just copying the volume but everything including the Master Boot Record and unallocated space.  (Also note an error in this first screenshot.  You can see the screenshot tool I was using to capture the window).

On the second screenshot you can see that the volume information during our copy attempt with EnCase had already been successfully copied over.  If we were to look at this volume with a hex editor we would find that the majority of that volume was empty (because we stopped the process before it was completed).  Now that we know our hard disk addresses we can Restore the disk using the dd tool.

If we wanted to zero out our destination drive we could use the following command:

$ sudo dd if=/dev/zero of=/dev/sdc bs=4k

This is a fairly clear command but lets break it down.  The "if=/dev/zero" is our source device (in this case we are using a default Linux file "zero" that is completely full of zeros specifically designed for wiping data).  dd will be copying the contents of this file to the destination device which we have designated with the "of=/dev/sdc" portion of this command.  The "bs=4k" stands for block size is telling dd to copy 4096 bytes at a time.  This command will destroy all data on the disk.

Once the drive has been successfully wiped (which I did not do for this situation) we will need to hash our source device.  To do this we can use the command cat and the md5sum tool with a Linux pipe.

$ sudo cat /dev/sdb | md5sum

NOTE: this only works with disks that are the exact same size.  If the drives are not the exact same size we can do this with the volumes on the drive.  This will ensure the integrity of the volumes and is what I did in this case.

$ sudo cat /dev/sdb1 | md5sum

a35a8d086e23ed20cdccafce41c08802  -

Now that we have the hash values for the volumes we can restore the drive.  The dd command we will use is very similar to the command we used to wipe the disk but includes a few more options.

$ sudo dd if=/dev/sdb of=/dev/sdc bs=4096 conv=notrunc,noerror,sync

39072726+0 records in

39072726+0 records out

160041885696 bytes (160 GB) copied, 3092 s, 51.8 MB/s

This again has our source and destination drives listed and this is a DISK to DISK copy.  It also has a designated block size.  Additionally we have the "conv=notrunc,noerror,sync" options specified.  "notrunc" tells dd not to truncate any data (and reduces errors).  "noerror" tells dd to not stop if there is an error (by default it will stop).  And finally, "sync" writes zeros for read errors (EnCase and FTK Imagers will also write zeros for errors during imaging).  If you wanted to create a disk image of this drive you could have done this:

$ sudo dd if=/dev/sdb of=/ForensicImages/ITEM_1.dd bs=4096 conv=notrunc,noerror,sync

Additionally, if you want to see the progress of your dd transfer or image you can create a new tab and use the following command to see the activity of the dd application:

$ watch -n5 'sudo kill -USR1 $(pgrep ^dd)'

Under certain circumstances the speed of the dd process can be sped up using some variable commands.  Additionally, hashing can be performed by using a | and && to pull it all into one command.  If I use this option I may cat the contents of the files and copy everything from the original command through the cat to help preserve the process

a9dadc2026fa0a1ed4994e8110b952e0e5cdf44776f63c95c913cf68a35fec52  /dev/sda

a9dadc2026fa0a1ed4994e8110b952e0e5cdf44776f63c95c913cf68a35fec52  Disk.dd

The previous lines were written to a file using the commands below.  No lines were added or removed.

root@slitaz:/media/cdrom/ImageFiles# sha256sum /dev/sda > Dis

kHash && dd if=/dev/sda bs=4M | dd of=Disk.dd && sha256sum Disk.dd >> DiskHash

19079+1 records in

19079+1 records out

156301488+0 records in

156301488+0 records out

root@slitaz:/media/cdrom/ImageFiles# ls

Disk.dd   DiskHash

root@slitaz:/media/cdrom/ImageFiles# cat DiskHash 

a9dadc2026fa0a1ed4994e8110b952e0e5cdf44776f63c95c913cf68a35fec52  /dev/sda

a9dadc2026fa0a1ed4994e8110b952e0e5cdf44776f63c95c913cf68a35fec52  Disk.dd

Below I used EnCase to create an E01 file from the dd created above.

Additionally, I calculated the SHA1 hash value of the dd file and found it matched the SHA1 value produced during the imaging process below.

Ideally, I would have done the SHA1 hashing prior to and after collecting the data but since this was not for forensic purposes I simply confirmed the original DD image and E01 images are the same binary data.

Name: LenovoT61-BaseImage

Path: G:\ImageFiles\LenovoT61-BaseImage.E01

EnCase Imager

Status: Completed

Start: 03/23/16 08:30:57 AM

Stop: 03/23/16 09:21:50 AM

Time: 0:50:53 

Name: LenovoT61-BaseImage

Path: G:\ImageFiles\LenovoT61-BaseImage.E01

Acquisition MD5: 2CAF4BD3D8C6F609295DFE9B2E53DCAE

Acquisition SHA1: F6883398295DA563BA3D0286AAA18EEB73C1FD0C

EnCase Imager

Status: Completed

Start: 03/23/16 09:21:50 AM

Stop: 03/23/16 09:36:35 AM

Time: 0:14:45 

LenovoT61-BaseImage: Verified, no errors

But we are not doing that today and if we were we would probably use a different tool (ewfimager or dcfldd for CLI imaging).

The copy took only about 2 hours and I was using a slow 5400RPM source drive and restoring a 160 gigabyte drive.  There are a few other factors like the speed of the disk controller (this is where your SATA I, II, and III connection speeds make a difference).

Forensically the next step is to re-hash the source drive.  This process takes a large amount of time (approx 45-50 minutes in my case) because entire volume has to be read and processed.

$ sudo cat /dev/sdb1 | md5sum

a35a8d086e23ed20cdccafce41c08802  -

We have just verified that the volume is exactly the same as it was prior to us creating the restore disk.  So lets make sure that this restore disk is correct by hashing the resource disks volume.

$ sudo cat /dev/sdc1 | md5sum

a35a8d086e23ed20cdccafce41c08802  -

So both volumes are exactly the same.  This process took less time because this drive is much faster than the original drive (approx. 30 minutes).  Forensically speaking, now you would place the copied disk into the suspect machine in place of the original and boot it up, allowing you to view the suspects working environment without ever compromising the original evidence.

 Below I included a screenshot of the resources being used by the md5sum tool.

I had a case about six months ago that I needed this for.  Here is a synopsis:

I had a large number of items in this case including a 2 terabyte external hard drive.  The external drive was a Western Digital Passport and was encrypted.  I also had about 3 laptop computers that we had recovered during a search warrant.  During my exam on one of the laptops I noticed that the Western Digital encryption software was installed on this Windows based computer and a shortcut was on the users Desktop.  I am aware that it is possible for the software to auto de-crypt and mount the encrypted drive.  Using EnCase I completed a restore of this laptops hard drive and booted up the laptop with the restored disk.  I then connected the drive to the now running suspect computer.  By default the drive was de-crypted and mounted allowing me to use EnCase Imager to create an image over the live system.  Had the user not been lazy and unwilling to enter the password each time the drive was connected I suspect I would have never been able to defeat the drives encryption.

--------------------------------------------------------------------------------------------------------------------------- 

Now for the not so forensic part.  To make use of the additional 840 gigabytes on the new drive I needed to expand the existing volume to take up the rest of the disk.  To do this I needed the gparted tool.

$ sudo apt-get install gparted

Then I used

$ gksudo gparted

to open the program.

In the top right hand corner I selected the drive that I wanted to make changes to.  You can see much of this disk is unallocated.  Using the orange arrow I selected to resize the volume (for this to work the volume must NOT be mounted).  Then I dragged the volume to its maximum size.

Then hit the check mark to apply the changes.

It's going to want you to make sure that this is exactly what you want to do because if you are wrong it may put a damper on your day!

And wallah!  It's off.

Once you are done it will give you the details about the operation.