Version 0.1
Copyright (C) 2004, Netherlands Forensic Institute
Rddgui is a Graphical User Interface (GUI) for the Robust Disk Duplicaitor (rdd) imaging software. Rdd used to be a command line utililty. With version 2.0 it comes with a GUI that can be used to avoid typing long command lines. A command line version of rdd is still available.
This help applies to rddgui verision 1.0. It might be useful for later versions too, although some modifications might be made to the user interface. This help might also be useful for the command line version of rdd because it extensively explains all options. The options on the rdd command line version are the same, the only difference is the GUI.
All screens in the GUI have a Help button. Clinking this button will show this help page.
The screens are connected to each other in a wizard like style. Clicking the Next button will show the next screen while the Previous button will show the previous screen.
Some settings, like e.g. the input file or device settings can be customized to a high level. The regular settings are displayed in the wizard like screen while the less regular and more difficult settings are 'hidden' behind an Advanced button.
Whenever a path to a file or device must be entered, there is a Browse button available. This button will show a file open dialog screen in which the file or device can be selected.
A listing of screens in alphabetical order:
The rdd-gui can make an image or verify an image that already has been made. An image is a bitstream copy of all bytes of a device or file.
Rdd can run in 3 modes:
Local mode does not use a network in which two versions of rdd are communicating with each oter. In local mode, rdd makes an image of a file or device and stores it either as an image file or on a target device. The file or device must be avialable on the computer rdd is running on. The location can be on a server that is avialable on your network.
In client mode, rdd reads the device or file that has to be imaged. The data read from the device or file is transmitted over the network to a computer running rdd in server mode. Because in client mode rdd reads the file or device, the file or device must be accessible by rdd.
In server mode, rdd reads the data that is transmitted by another computer running rdd in client mode and stores it as an image file or on a target device. Rdd in server mode is typically run on a server that stores several images.
By selecting a profile, the GUI sets some default values for the chosen profile. The list of profiles contains several types of media. All settings that are set to default values can be changed in screens that are to come.
The input file or device is the file or device you want to image. You must specify this file or device.
Rdd is designed not to change the input file or device. But, as all software, rdd is not free of bugs. When possible, use a hardware writeblocking device.
Rdd can read the input file or device from the start to the end.
Rdd can also read any part of the file. The following items can be set:
All values can be specified in bytes, kilobytes (kB), Megabytes (MB) and Gigabytes (GB).
You must specify the output image and the logfile.
The output image can be a file or a device and must be specified.
Rdd logs all its activity to a file. This file must be specified.
Rdd can write the output image as one piece or rdd can split the output image in files of a specified size. When splitting, rdd will add a sequence number to the names of the output files.
Splitting an ouput image can be useful if you know you will have to burn a large image on a set of cd-recordables.
Some filesystems like FAT12, FAT16, and FAT32 have a maximum file size. These filesystems can not handle files larger than this size.
Rdd can calculate MD5 and SHA-1 hash values over the bytes it reads.
We recommend that you use both MD5 and SHA-1. MD5 is widely used, but its one-way hash function has been under attack for a while.
We recommend that you compare the MD5 or SHA-1 hash value that rdd calculated during imaging with the MD5 or SHA-1 hash values obtained by:
For this check, we recommend you use other software than rdd. Linux
md5sum and sha1sum are good options.
When your device reports non reproducable readerrors, the verification hash might not be the same as the hash rdd calculated.
Besides calculating an MD5 or SHA-1 hash rdd can calculate Adler-32 checksums and CRC-32 checksums over the bytes it reads. Where MD5 and SHA-1 hashes are calculated over the complete input file or device, Adler-32 and CRC-32 checksums are calculated over smaller blocks of data. All Adler-32 checksums are written to one file and all CRC-32 checksums are written to one file.
When you have an rdd image with one of these checksum files, and the hash of the image is different from the hash rdd calculated during imaging, rdd can pinpoint the exact blocknumbers that have been changed.
This screen has boxes for selecting the checksum method, the size of the block to calculate checksums over, and the files in which all checksums are written.
In most cases it is not necessary to calculate both Adler-32 checksums CRC-32 checksums. One checksumming method is enough. Adler-32 is a bit faster than CRC-32. Checksumming can be used in addition to hashing. Checksumming is not implemented in rdd to replace hashing because checksums are much less distinguishing than hashes.
A blocksize of 64 kB is the default value in rdd. You clould select larger blocksizes for large hard disk drives. This will reduce the size of the checksum file. For smaller media, like a floppy disk, you might want to use a smaller blocksize. We recommend not to use blocksizes smaller than 64 kB for the Adler-32 checkusum because the checksums might not be distinguishing enough with smaller blocksizes.
Refereces:
Most copying software read files or devices in blocks, using a certain blocksize. When they encounter a read error, the whole block of e.g. 256 kB, will be lost. Even though only one sector of 512 bytes was damaged and is responsible for the read errors. In this case nearly 256 kB of data is lost unnecessary.
Rdd will reduce its blocksize when it encounters a read error when the option for error recovery is chosen. Reducing the blocksize and retrieving as much data as possible was one of the major design goals rdd.
Choosing error-recovery will set the default values. To what blocksize rdd reduces its blocksize, can be set in the Error-recocery Advanced screen. The deault size is 512 bytes.
When rdd is unable to read the block, it will replace the block with zero bytes in the image.
When rdd encounters a read error it will try to read the block it was reading with a blocksize of the retry blocksize. The default value is 512 bytes. This is the sector size of a hard disk drive. Setting a smaller blocksize when imaging a hard disk drive is useless because a standard hard disk drive will never read less bytes than 512.
The operating system might try to read a damaged block a couple of times. Rdd can drop the block after a certain number of retries and proceed to the next block.
Trying to recover as much as possible can take a lot of time. Rdd can give up after processing a certain number of damaged blocks or rdd can proceed until a crash of the operating system or a power brownout.
Rdd can calculate the entropy and the MD5 hash value of blocks of bytes it reads. These entropy and MD5 hash values are stored in textfiles. Rdd comes with programs that can produce a plot of the entropy and block-MD5 values from these textfiles.
The entropy of a group of bytes is a measure of the amount of randomness of the bytes in the group. Good predictability (poor randomness) results in a low entropy and poor predictability (good randomness) results in a high entropy. An expample of good predictability is a block containing zeroes. Examples of poor predictability are files that are crypted with a good crypto algorithm or files that are heavily compressed. Calculating the entropy can help distinguishing between unused areas and areas that might contain a crypto container or heavily compressed data.
Besides calculating an MD5 hash over the complete image, rdd can calculate an MD5 hash over blocks it reads. Calculating MD5 hash values over blocks can show if the evidence contains much re-occurring blocks. In most cases, blocks that have a high entropy cannot be discarded. Although a series of blocks have a high entropy, the blocks might be exactly the same. Analyzing the block-MD5 plot together with the entropy plot might reduce the amount of bytes worth researching.
This document describes how to make and interpret the plots. It also gives some examples.
In this screen you can set the blocksizes and the ouput files for the data to generate the entropy and block MD5 plots from. Please refer to the help on the Statistics screen for an explanation of these values.
This screen provides information on the progress of making an image. The following information is available:
Pressing the Cancel button will stop the imaging in progress.
This screen provides information on the completed image. The following information is available:
Rdd logs everything it does. Click the 'Show logfile' button to view the logfile.
The button 'Image or verify another file or device' will return to the 'image or verify' screen.
Rdd can use a network to transprort an image from one computer to another. Rdd uses the TCP/IP protocol over an ethernet connection. Before you try to establish a connection, make sure you have a computer with a network card installed and your computer supports the TCP/IP and ethernet protocols.
When rdd runs in client mode, rdd reads the file or device that must be imaged. Instead of storing the image locally, all data is sent over a network to another computer that runs rdd in server mode. Rdd in server mode receives the image and stores it locally. To minimize the network load the image can be sent in a compressed format.
All settings like selecting the file or device to image, the blockize, etc. are configured in rdd running in client mode. Even the location where to store the file on the server is selected in client mode. Before the image is sent, the rdd client notifies the rdd server where to store the image.
Rdd in client mode will try to establish a connection to the specified rdd server. The server must therefore be configured first. It must be 'listening' on the network for an rdd client that wants to establish a connection.
Make sure there is a network route from the rdd client to the rdd server and that it is not blocked by a firewall. If a firewall is blocking the route you will have to open a port on the firewall. You can configure rdd to use any TCP port.
Please refer to the Networking section of for the basics of rdd in client mode and rdd in server mode.
In this screen you can configure rdd in client mode. You can enter the name or the IP address of the computer that is running rdd in server mode. The image can be compressed to minimize the network load and increase the speed. In most cases the network speed will be lower than the speed of the hard disk drive. Reducing the number of bytes to send will reduce the time that is needed to perform an imaging operation over a network.
Rdd in client mode will write a log file on the connection and transferring the image locally. This file is not sent over the network. This logfile will look much the same as the logfile rdd makes in local mode. Note that the compression option does not apply to the logfile. It only applies to the image that is sent over the network.
Rdd can use any TCP port in the range from 0 to 65535. Make sure the rdd client and the rdd server both use the same TCP port.
This screen shows rdd is running in client mode trying to connect to a computer that is running in server mode. When the connection is established, this screen will disappear and be replaced by a progess screen. If no connection can be established, make sure the computer that is running rdd in server mode is waiting for a connection and there is a network route from the rdd client to the rdd server.
Please refer to the Networking section of for the basics of rdd in client mode and rdd in server mode.
Rdd in server mode will write a logfile on the connection and transferring the image.
Rdd can use any TCP port in the range from 0 to 65535. Make sure the rdd client and the rdd server both use the same TCP port.
This screen shows rdd is running in server mode, waiting for an rdd client trying to establish a connection. When the connection is established, this screen will disappear and be replaced by a progress screen. If no connection can be established, make sure the computer that is running rdd in client mode is trying to connect and that there is a network route from the rdd client to the rdd server.
This screen shows there is a connection between the rdd client and the rdd server. The following information is avialable:
This screen provides information on the completed image. The following information is available:
Rdd logs everything it does. Click the 'Show logfile' button to view the logfile.
The button 'Image or verify another file or device' will return to the 'image or verify' screen.
Rdd can canculate MD5 and SHA-1 hashes over all bytes it reads. Besides these hashes over the complete image, rdd can calculate Adler-32 and CRC-32 checksums over blocks of data it reads. All these hashes and checksums can be used, up to a certain extent, to verify the integrity of an image produced by rdd.
Please refer to the sections Integrity and Integrity, advanced for a discussion on these hashes and checksums.
In this screen you can conofigure the following items:
Note that rdd does not verify the hashes. Verification must be done by comparing the hash rdd calculates at verifying with the hash rdd calculated at imaging.
The default is that rdd expects an Adler-32 checksum file is available named like the image file, but with the extension a32. This setting can be changed in the Verify, Advanced screen.
In this screen you can select the correct Adler-32 checksum file and the correct CRC-32 checksum file. If rdd did not make these files during imaging, you should not use them in verifying an image. Information that is not available can not be verified.
This screen shows rdd is verifying and image file. The following information is avialable:
This screen is shown when rdd has finished verifying an image file. The following information is avialable:
Rdd logs everything it does. Click the 'Show logfile' button to view the logfile.
The button 'Image or verify another file or device' will return to the 'image or verify' screen.