Sunday, June 3, 2018

DC3dd - Creating a Forensic Image of a USB

Since the USB drive being duplicated is being plugged into a Linux based system or more specifically SANS SIFT Workstation, to make sure the drive is easy to detect, let's first clear our dmesg buffer.

For those not aware of dmesg, this "is used to examine or control the kernel ring buffer". By default, it displays all messages from the kernel ring buffer.

To clear the kernel ring buffer, we type:

# dmesg --clear

To ensure the disk is also not automouted, using dconf-editor, I disabled the "automount", "automount-open" and enabled "automount-never" features. This was done by typing using the "dconf-editor"

Once the editor winow opens, then navigate to:

-> org -> gnome -> desktop -> media-handling

From the above, you can then disable the two options.

Now that we have the basics out of the way, let's insert our USB drive and look at the dmesg output.

# dmesg 
[ 2247.780789] usb 2-1: new SuperSpeed USB device number 10 using xhci_hcd
[ 2247.803791] usb 2-1: New USB device found, idVendor=090c, idProduct=1000
[ 2247.803797] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2247.803801] usb 2-1: Product: USB DISK
[ 2247.803804] usb 2-1: Manufacturer: SMI Corporation
[ 2247.803806] usb 2-1: SerialNumber: AAKTVG216KF7TH93
[ 2247.808934] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2247.809223] scsi host39: usb-storage 2-1:1.0
[ 2248.953289] scsi 39:0:0:0: Direct-Access     SMI      USB DISK         1100 PQ: 0 ANSI: 6
[ 2248.953818] sd 39:0:0:0: Attached scsi generic sg2 type 0
[ 2248.958202] sd 39:0:0:0: [sdb] 62914560 512-byte logical blocks: (32.2 GB/30.0 GiB)
[ 2248.959002] sd 39:0:0:0: [sdb] Write Protect is off
[ 2248.959006] sd 39:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 2248.959812] sd 39:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2248.975287] sd 39:0:0:0: [sdb] Attached SCSI removable disk

From above we see the "Product: USB DISK" and we see also that it has been assigned device "sdb".

If we now perform a "ls /dev/sd*" we see our "sdb" drive.

# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sda5  /dev/sdb

Let's now go ahead with leveraging dc3dd to create our forensics image.
# dc3dd if=/dev/sdb  hof=/cases/nik-usb-sdb.img hash=md5 hash=sha256 log=/cases/nik-usb-sdb.log verb=on ssz=512

To understand the command above:

if=/dev/sdb  -> use the input file /dev/sdb
hof=/cases/nik-usb-sdb.img -> Hash output file /cases/nik-usb-sdb.img
hash=md5 -> Use MD5 hashing algorithym
hash=sha256 -> Use SHA256 hashing algorithym
log=/cases/nik-usb-sdb.log -> Log the output to "/cases/nik-usb-sdb.log"
verb=on -> Enable verbose reporting
ssz=512 -> set the sector size to 512. I got this from the dmesg results

Looking at the results we see:

dc3dd 7.2.641 started at 2018-05-17 02:51:17 +0000
compiled options:
command line: dc3dd if=/dev/sdb hof=/cases/nik-usb-sdb.img hash=md5 hash=sha256 log=/cases/nik-usb-sdb.log verb=on ssz=512
device size: 62914560 sectors (probed),   32,212,254,720 bytes
sector size: 512 bytes (set)
 32212254720 bytes ( 30 G ) copied ( 100% ), 1243 s, 25 M/s                   
 32212254720 bytes ( 30 G ) hashed ( 100% ),  332 s, 93 M/s                   

input results for device `/dev/sdb':
   62914560 sectors in
   0 bad sectors replaced by zeros
   248c65b1d5d0fb63c8b35dd411cc3ed8 (md5)
   3a015e8c91a982c2629d037431953521b9daad811916436b807e2efd0aaef0fd (sha256)

output results for file `/cases/nik-usb-sdb.img':
   62914560 sectors out
   [ok] 248c65b1d5d0fb63c8b35dd411cc3ed8 (md5)
   [ok] 3a015e8c91a982c2629d037431953521b9daad811916436b807e2efd0aaef0fd (sha256)

dc3dd completed at 2018-05-17 03:11:59 +0000

From above we see via the "[ok]" for both the md5 and sha256 hashes that the copy is a perfect image.

At this point, we can now go ahead and perform our forensics on the file "/cases/nik-usb-sdb.img"


No comments:

Post a Comment