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/ conv=notrunc,noerror

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.