dcfldd for disk imaging
**DD WILL OVERWRITE DATA ON A DRIVE BE SURE OF WHICH DRIVE IS THE SOURCE AND THE DESTINATION**
If you don’t have a USB write blocker remount the drive to prevent unintentional changes to the drive. This is good forensics. dcfldd is a part of Kali Linux but if you want to add it from source it is available here.
Find the installed drives on the system:
ls –l /dev | grep sd
If you need more information about the drives to determine which is the source and which is the destination for the image:
Change the drive permissions to read-only:
chmod 440 /dev/sdb
The drive is now set to read-only for both root and owner; it is time to start the image. This is a time consuming process dd takes a significant amount of time to copy the disk to image.
An astute commenter mentioned that changing the block size to 4096 bytes dramatically increases the speed of the image which is true. The default value is 512bytes. Leaving the default at 512 bytes is a belt and suspenders approach, if a block is bad dcfldd writes 0’s into the image. Using the smaller and slower default option minimizes the potential data lose. On a known good drive increasing the block size may be appropriate depending on the circumstances. Where forensics are concerned, especially if the image may be used in a disciplinary or legal setting, it is best to err on the side of caution.
The hashwindow option allows the image to be split into multiple smaller image files that individually hashed. This has the benefit of allowing a failed hash to only invalidate only a portion of the total image. The option takes an input value in bytes; to use this option set the hashwindow=1G.
dcfldd if=/dev/sdb hash=sha1,md5 md5log=/image/md5.txt sha1log=/image/sha1.txt of=/image/toshiba.dd
Now you’re imaging.
One of the advantages of dcfldd is the built in hashing function. When the image is completed we can verify that the image is sound by checking the hash log and a separately generated hash.
Check the hash values created during the imaging process:
To generate a separate hash for verification run the following and compare the outputs:
Verify that the image file is good and that data hasn’t changed. You can use md5sum or sha1sum but they take forever to run. Dcfldd has a built in verification function.
dcfldd if=/dev/sdb vf=/image/toshiba.dd verifylog=/image/verifytoshiba.txt
This is what the whole process looks like.
If the verification fails you will get a message similar to this:
This article was edited on 7/20 to include great feed back that was received from reddit users as well as direct comments. The comment was published because of the email address used. If you want recognition please feel free to contact us and I’ll update it again. Thanks to F. Erensics and HackThe______ for providing insight.