The following example shows the dcfldd tool encountering a disk with two errors. The locations (block offsets) of the errors on a disk are reported to stdout and logged to the specified file, as follows:
# dcfldd if=/dev/mapper/errdisk of=errdisk.raw conv=noerror,sync errlog=error.log ...
# cat error.log
dcfldd:/dev/mapper/errdisk: Input/output error (null)+15 records in
(null)+16 records out
dcfldd:/dev/mapper/errdisk: Input/output error (null)+29 records in
(null)+32 records out (null)+62496 records in (null)+62501 records out
Several bugs were encountered when testing dcfldd under Debian Linux. The block size used for padding remained at 4K, even when a 512-byte block size was specified (dd showed the same behavior). On some errors, dcfldd went into an endless loop and had to be manually terminated.
The dc3dd tool provides a very detailed overview of the errors encoun-tered. Errors are sent to stout and saved in the specified log file, as follows:
# dc3dd if=/dev/mapper/errdisk of=errdisk.raw log=error.log ...
# cat error.log
dc3dd 7.2.641 started at 2016-01-12 19:42:26 +0100 compiled options:
command line: dc3dd if=/dev/mapper/errdisk of=errdisk.raw log=error.log device size: 4000000 sectors (probed), 2,048,000,000 bytes
sector size: 512 bytes (probed)
[!!] reading `/dev/mapper/errdisk' at sector 1000 : Input/output error
[!!] 4 occurences while reading `/dev/mapper/errdisk' from sector 2001 to sector 2004 : Input/output error
2048000000 bytes ( 1.9 G ) copied ( 100% ), 5.74919 s, 340 M/s
input results for device `/dev/mapper/errdisk':
4000000 sectors in
5 bad sectors replaced by zeros
output results for file `errdisk.raw':
4000000 sectors out
dc3dd completed at 2016-01-12 19:42:31 +0100
The ewfacquire tool offers a default error granularity of 64 sectors, and this can be changed to 1 to reduce the number of sectors padded to zero.
In this example, ewfacquire only detected two read errors (similar to dcfldd;
it skipped and padded a 4k block without checking the other sectors):
# ewfacquire -t errdisk /dev/mapper/errdisk ewfacquire 20150126
...
The number of bytes per sector (1 <= value <= 4294967295) [512]:
The number of sectors to read at once (16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768) [64]:
The number of sectors to be used as error granularity (1 <= value <= 64) [64]: 1 The number of retries when a read error occurs (0 <= value <= 255) [2]: 1 Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [no]: yes ...
Acquiry completed at: Jan 12, 2016 19:57:58
Written: 1.9 GiB (2048000804 bytes) in 14 second(s) with 139 MiB/s (146285771 bytes/second).
Errors reading device:
total number: 2
at sector(s): 1000 - 1008 number: 8 (offset: 0x0007d000 of size: 4096) at sector(s): 2000 - 2008 number: 8 (offset: 0x000fa000 of size: 4096)
MD5 hash calculated over data: 4d319b12088b3990bded7834211308eb ewfacquire: SUCCESS
The ftkimager reports errors and logs them. The following example uses an actual physically defective disk (an original first-generation iPod) because the ftkimager didn’t work with simulated errors created with dmsetup:
# ftkimager /dev/sdg ipod
AccessData FTK Imager v3.1.1 CLI (Aug 24 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042 All rights reserved.
Creating image...
234.25 / 4775.76 MB (11.71 MB/sec) - 0:06:27 left Image creation complete.
# cat ipod.001.txt Case Information:
Acquired using: FTK ...
ATTENTION:
The following sector(s) on the source drive could not be read:
491584 through 491591 491928 through 491935
The contents of these sectors were replaced with zeros in the image.
...
Each of the forensic acquisition tools had some error detection, han-dling, and logging capabilities. However, for disks with a significant number of errors or hardware damage, using more specialized tools might be more appropriate. The next section describes the use of data recovery tools for this purpose.
Data Recovery Tools
Several disk block recovery tools are worth mentioning because of their robust error handling and aggressive recovery methods. Although these tools were not written with forensics in mind, they are useful in situations in which other forensic tools have failed.
The ddrescue tool (by Antonio Diaz Diaz) was designed to recover blocks from damaged disks. Unlike the dd family of tools, it has a multi-phase recovery algorithm, and you can run it against a disk multiple times to fill gaps in the image. The algorithm includes reading problematic parts of the disk backward to increase the number of recovered sectors and per-forming various retry operations over multiple passes.
A completed ddrescue operation results in statistics that describe the recovery success rate:
# ddrescue /dev/sda image.raw image.log
rescued: 40968 MB, errsize: 2895 kB, current rate: 0 B/s ipos: 39026 MB, errors: 38, average rate: 563 kB/s opos: 39026 MB, run time: 20.18 h, successful read: 8.04 h ago Finished
The log file that ddrescue produces shows the start and end times and a detailed overview of the disk’s problem areas:
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue /dev/sda image.raw image.log
# Start time: 2015-06-13 22:57:39
# Current time: 2015-06-14 19:09:03
# Finished
# current_pos current_status 0x9162CAC00 +
# pos size status
0x00000000 0x4F29D000 + 0x4F29D000 0x00002000
-0x4F29F000 0x00253000 + ...
The dd_rescue tool (note the underscore) was developed by Kurt Garloff in the late 1990s, and although the name contains dd, the com-mand syntax is completely different and it doesn’t perform data conversion (same with ddrescue). But it does transfer blocks of data similar to dd. Sev-eral features make this tool a possible option for use in a digital forensic laboratory. The block size is dynamically changed when disk errors occur, automatically decreasing to a physical block size. After a period without errors, the block size is changed again to improve performance. You can also image the disk backwards, from the end of the disk to the beginning.
This technique is useful if the drive has difficulty reading past a certain point on the disk.
The myrescue tool is designed to initially avoid unreadable areas (no retries) and focuses on recovering as much of the readable areas as possible.
After the readable sectors are copied, it works on the failed ranges. The tool documentation recommends letting difficult drives rest for a couple of hours between retries.
Another tool called recoverdm also performs data recovery. It is unique in that it can recover data from a damaged disk at the sector level or at an individual file level. The tool has additional features for floppies and optical media.