Categories
Hardware Software

Forensic drive imaging with dd

Raspberry Pi dd imaging guide.

Preface:
This guide is for sharing a forensic approach to imaging a hard drive or solid state device.  I tend to not see many forensically tooled guides, so this one covers imaging from the perspective, that you need a verifiable image of a drive you will be working with.  I am writing it will full intent to be useful without needing to have a Write-blocker or needing to run and wait for the sha256 signature checks to be run.  In effort to be accessible I will cover the imaging of a Raspberry Pi with Raspbian and getting that running.  If you are familiar with that process, please jump ahead to the Action section.
My logic for using a Raspberry pi is because they are some of the cheapest functional computers one can get.  My logic for imaging the Pi fresh from an ISO, is to be sure no extra data is left over on the Pi from any previous projects you might have been doing in the past.

I want to add a side-note that you can follow the steps under action for almost any Linux distribution on various hardware.  I have done similar on a current era laptop running Tails before.  Your CPU heavy tasks like sha256sum will likely run much faster than on the Pi 2 I used for this guide. USB hard drive performance may also run higher based on your USB drive connectors and laptop, versus a Raspberry Pi 2.  Just for point of reference, I wanted to mention this.

Preparation:
Tools needed:

  • Raspberry Pi
  • SD Card
  • A USB to MicroSD reader (to image your Pi)
  • Power Supply
  • HDMI Display
  • Keyboard and probably a mouse
  • Post-It notes to label your drives
  • A USB powered hub (you want this for use with the external drives)
  • A USB SATA Dock
  • USB Write-blocker to prevent making changes to source drive. (or you can use a second USB dock but cannot count on the full unchanged integrity of the source USB drive.)

As I mentioned the Write-blocker, that will increase your cost quite a bit. Roughly $300 if you are going to use a Cru ComboDock 5.5 that I use.  You are still fully able to follow this guide without one, but minor changes to your source drive may happen while you read data from it (especially if you browse the drive contents and it generates thumbs.db files) and that would cause a problem in the sake of capturing a forensically sound image of that source drive.

With that noted, let’s get the Raspberry Pi ready to go with a fresh install of Raspbian OS.

Download latest Rasbian to your main computer you are reading this from.
Install to sd card with etcher imager (resin.io is the imager I used to write the .iso to MicroSD Card)
Put sd card in your Pi and boot it up.
Bring up a terminal and set pi passwd (default password is: raspberry)
Raspberry Pi Configuration can be found under Preferences on the menu of Raspbian Desktop.  On this first tab of System you can change the bottom options:

  • Disable auto login
  • Boot to CLI

Now that we have the Pi booted and setup, let’s jump into the Actions portion of the imaging.

Actions

Hook up source drive (If no write-blocker, use a USB drive bay / or external drive).  Follow the below steps to identify your source drive.
No gparted on Raspbian anymore, so use Parted in the terminal.

sudo parted -l

Typically the first usb drive will be /dev/sda.  Also cross reference the output to make sure it matches to the size of the drive you just hooked up. (500 GB source drive in my case)
You can also  type ls /dev/sd* in a terminal to see what drive is connected.  Now that we know what the source drive is, go ahead and hook up the destination drive you are using to be the clone of your source drive.
In another terminal, type sudo parted -l again.  In my case I now see a /dev/sdb.  This is my second drive I will be using to write the clone of the source drive to. (1000 GB destination drive in my case)

For your sake, this is where I recommend using post-it notes to write a note to put on each disk, stating what one is the source and it’s /dev/path.  Also doing the same for your destination and it’s /dev/path.

Source drive is /dev/sda
Dest drive is /dev/sdb

With that out of the way, we are ready to jump into the long haul of running  a dd command.  This will copy the data from your source drive, block for block to the destination drive.  dd is quite a serious command and can result in data loss if you do it wrong.  Here is where a write-blocker is especially useful to prevent overwriting the drive.  Also this is where the notes on the physical disk are helpful.  Below is the command for the setup we outlined.

dd if=/dev/sda of=/dev/sdb bs=16384k status=progress

Let’s break this command down.  I look at the if= being equal to Input file.  That’s our source drive.  of= being Output file.  This is where our destination drive is being overwritten.  bs= is Block Size.  I go with 16384k as it is a block size I have seen around good for imaging.  status=progress is a nice add-on so you can see the results of the dd command.  Otherwise you would be waiting for the progress to output once it is done.
This will take quite some time. 500 GB source to a 1TB destination drive.  Easily took about 8 hours as the finished results state:
27184.1 s, 18.4 MB/s.  Divide that by 60, then again by 60 and I got 7.55 hours to image a 500 GB drive to a 1 TB drive.
Hurry up and wait as you are doing a block for block image, so it even will copy the blank space to the destination drive.

Once done, verify each drive matches (Especially for forensic sake and use of write blocker).
Drive to drive sha will not match, so you want to do it for the partitions specifically.  Once again, be warned that it took around 7 hours on this Pi setup to run sha256sum against each one of these partitions.  Below are the commands I ran to generate the sha256 signature, followed by their matching results.

sha256sum /dev/sda1
sha256sum /dev/sdb1

813dcb6470f62c7c12623a0ef092551965b83e501e70dff4e01e1220cebf0129  /dev/sda1
813dcb6470f62c7c12623a0ef092551965b83e501e70dff4e01e1220cebf0129  /dev/sdb1

Bingo!  Image is a success and the source partition is a match to our cloned partition.  For conversations sake, if you were to run sha256sum against the entire disks, they would not match up.  Keep in mind the destination drive I used is a 1TB disk, so it has more free space than does the source drive.

Here are examples of mismatched checksum, because we compared the entire disks where one was larger than the other.

83b3b53d577d0ae793c947220b4ef3aa3d323e8349e0d3615b77964ec5baeb80  /dev/sda
f24189b6160b9a91bf5037ade4d4ab2f45a9bad9ebe254c0a349688f8987bc10  /dev/sdb

That concludes this guide.  If you have an questions or feedback, reply in this thread or hit me up online.  Thank you for reading and visiting. :)
Original thread