Linux dd can be a powerful and flexible tool to have in your box.
You will find it installed by default on the majority of Linux distributions available today and it can be used for a multitude of digital forensic tasks, not least of which is providing a simple means of obtaining a raw image of a file, folder, volume or physical drive. It has a simple, relatively intuitive syntax and a useful set of options to extend its basic capabilities.
On the negative side it does not give any feedback to the user when it is launched, has no error checking by default and perhaps most importantly can be very destructive if you get things wrong, earning it the nickname of "Data Destroyer" (dd) over the years.
As always, read the man pages before you use it [# man dd] and fully test the processes in a safe environment before letting it loose on a job that really matters.
The basic dd syntax is as follows:
# dd if=
("if" being "input file" and "of" meaning "output file").
is actually one of the options that I mentioned above. If you don't include it dd will use a default byte size of 512. The byte size is usually some power of 2, not less than 512 bytes. For example: 512, 1024, 2048, 4096, 8192, 16384. It can however, be any reasonable number). Personally I always set the byte size manually so that I know exactly what is going on with the process that I am running.
It should be easy to work out from the basic command that "if=
" is the data being read whilst "of= " is where the data is being written to. It should also be obvious that if you reverse the source and target entries by mistake, you can potentially overwrite your source with your target. In real terms this can mean filling the contents of your suspect drive with all of the zeros from your sanitized evidence drive. Of course, if you have your suspect drive attached through a write blocker as I previously suggested you should be protected to a certain extent from this kind of error. The main thing is to take care with your data entry and get the syntax right before you hit the return button.
If you are wondering what I mean by sanitized evidence drive, it is simply the process of wiping and formatting a drive prior to writing new evidence to it. You should always make sure that you start any investigation in this way so that the danger of residual data on your target drive corrupting your evidence is removed. You can use "dd" to do this using this command:
# dd if=/dev/zero of=/dev/
This process will basically fill your target drive with zeros, overwriting any data as it goes. One pass should be enough although you can of course run it as many times as you like before re-formatting the drive. The byte size used in the example will be the default 512. You are free to choose any size you wish and may see reductions in processing times as a result of using a larger number. Experiment with different byte size entries on a spare drive and see what difference it makes. If time is not an issue, then just stick with the default.
Now that we have the basic syntax (# dd if=
of= ) we can see that what dd is doing is copying chunks of data from the source, in this example in the default 512 byte blocks, and writing that data to the target, which can be a file or another block device. So we now have a choice as to where, and how we store our forensic image. Lets say that we have an 80 GB hard drive that we want to image. You could send the output straight to a wiped and formatted drive, like this:
# dd if=/dev/
of=/dev/ bs=512 conv=noerror,sync
which produces a straight copy of the original.
You can write the output to a file:
# dd if=/dev/
of=/home/user/linux_image.dd bs=512 conv=noerror,sync
although in practical terms an 80 GB (uncompressed) file might be a little unwieldy to deal with, unless you then use dd again to write the file back to a clean disc (again a straight copy):
# dd if=/home/user/linux_image.dd of=/dev/
Which simply writes the contents of linux_image.dd to your target device.
You will have no doubt noticed that I have introduced several new switches using the conv= (conversion) option on the back of the command. These are very important additions that I had already alluded to in paragraph 3 above. These switches turn on various forms of error checking within the dd command. By default dd will happily copy out data until it locates a sector or block on the source device that it can't read. Then it will just stop what it is doing and you won't have a full image. Using conv=noerror,sync will adjust this behaviour so that dd will pad the bad sectors with zero characters and then carry on copying the rest of the data that it can read. The second part of the switch, sync provides the zero padding and also ensures that the sectors on the target device are aligned with those from the source device, thus ensuring an accurate replication of the original media. notrunc simply tells dd to keep copying to the end of the target device rather than truncating the image early.
There are a number of other useful switches within dd. Open up # man dd to see an explanation of them all.
There is just one more area that I want to cover briefly before I move on and that is splitting images into manageable size files using dd and a unix tool appropriately called split. To do this on the fly using dd you simply have to pipe the dd if= through the split command like this:
# dd if=/dev/
| split -d -b 2000m - image.split.
I intend to talk about splitting images in a later post so won't elaborate too much here. Suffice to say that the above command takes standard output from the dd command and pipes it as standard input to the split command. The result (in this case) is a series of 2 GB files, in the current directory, that will be named 'image.split.01', 'image.split.02' and so on.
As I say, there will be a more detailed look at this technique in later posts. For now just get used to the difference in syntax from a standard dd operation (i.e. no of= string).
Well, that's a brief overview of Linux dd, it should certainly be enough to get anyone started with the basics of using it as a forensic tool. As always I would advocate further reading (man dd) and of course a Google search will throw up a good amount of reference material.