Since I am currently doing a Forensics track on my masters, I wanted to throw in a quick note on DCFLDD. What is quite nice with DCFLDD is that it is created with forensics in mind (by U.S. Department of Defense Computer Forensics Lab, according to the forensicswiki), and is a further enhancement of the popular tool named DD. Amongst other features DCFLDD handles hashing, verification, simulationous output and logging. We’ll get back to that later on in a practical test of the application. The test only features a software write-blocker.

Being the most important perspective in forensics is the integrity and forensic soundness (being that the image is captured as it was before acquired, and not changed in any/a controlled way).

The test

The following was done in a OS X test environment, with DCFLDD compiled into it. I took a memory stick deciding to do an image capture of it. Insert it, but make sure the FS is not mounted automatically in OS X (as is the default).

Now issue the following command:

dcfldd if=/dev/disk2s1 hash=md5,sha256 hashwindow=10G md5log=md5.txt sha256log=sha256.txt hashconv=after bs=512 conv=noerror,sync split=10G splitformat=aa of=image.dd

Couple of things about the above command (from the manual of DCFLDD):

noerror:  Continue after error
sync:     Pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs
hashconv: Perform the hashing before or after the conversions

That should get you to somewhere near this:

7959808 blocks (3886Mb)
7960008+0 records in
7960008+0 records out

Okay. What we’ve seen is a capture of a USB stick. We now have two hash files to be used for the chain of evidence and to help prove the integrity of the acquisition.

file: sha256.txt 0 - 4102886912: 37fad88ff09740b35340c93e6d2337307508a981f77dd7665d3e58e6d8098eb5
Total (sha256): 37fad88ff09740b35340c93e6d2337307508a981f77dd7665d3e58e6d8098eb5

file: md5.txt 0 - 4102886912: 7114c0b0eb9cda11f1fe0f63cb486a1d
Total (md5): 7114c0b0eb9cda11f1fe0f63cb486a1d

Now we can start doing some essential forensics, running fls and ils:

fls -m image.dd.aa

0|/Read Me.url|104|r/r-wx-wx-wx|0|0|71|1322434800|1244666592|0|1244666592
0|/COV 0000. BL|150|r/r--x--x--x|0|0|32768|1322348400|1322429436|0|1322429436

ils returned nothing in this case:

ils image.dd.aa


And the image ”image.dd.aa”. Let’s mount the image, in Linux you would mount it on a loopback device like this:

mount -o ro,loop /tmp/image.dd.aa /mnt

In OSX you will have to do:

hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount image.dd.aa
output: /dev/disk3

mount -o ro /dev/disk3 /Volumes/test/

This mounts the image read-only in the volumes test folder. Remember to hash all files before continuing:

MD5 (/Volumes/test//ar-SA_BitLockerToGo.exe.mui) = 3d9f4e026147e25a1546e9debe4ec29e
MD5 (/Volumes/test//autorun.inf) = 58835871e57fa4900939e252dae4090f
MD5 (/Volumes/test//bg-BG_BitLockerToGo.exe.mui) = 705dc1a49e59540efdbfcb0648bcc2c0
MD5 (/Volumes/test//BitLockerToGo.exe) = 7aa637bb31d179896bf2c27e2bedc2e0
MD5 (/Volumes/test//cs-CZ_BitLockerToGo.exe.mui) = d3ae7c6c50cb25e8587f9f82e9c87418
MD5 (/Volumes/test//da-DK_BitLockerToGo.exe.mui) = a61f7f4979428b15f39224b3c46214a7
MD5 (/Volumes/test//de-DE_BitLockerToGo.exe.mui) = 3afe929403d5e52abe1ba3f00e456cec
MD5 (/Volumes/test//PAD 0000. PD) = b5cfa9d6c8febd618f91ac2843d50a1c

Remember to always verify your hashes in the start and end of the procedure.

Now I have a bitlocker on-the-go device to work on :p