Do 9 Year Olds Wear Thongs

The bad sector and the acquisition forensic

If you must have a hard disk in a forensic, ie all the trappings necessary to ensure that the copy is identical to the original, to all those working in the field comes to mind the use of DD, or DCFLDD

DC3DD

(In the Open Source GNU / Linux), with the usual options and parameters.

are two approaches: 1) optimistic (we consider the healthy disc and all areas healthy) 2) Pessimistic (we consider that the disk has some bad sector) When the optimistic approach is repudiated, because when you find yourself with the acquisition of reading errors, then you tend to take the viewpoint pessimistic, sometimes even start all over again.

examine scenarios:

dd if = / dev / sdb of = / conv = media/sdc1/disco.dd noerror, sync bs = 32K
suscritto The command reads blocks from disk is 32KB / Dev / sdb and write destination disk / media/sdc1 (mounted in writing) the file disco.dd, the option conv = noerror, sync serves two functions:

1)
noerror
- Tells dd not Halting before any read errors, ignoring the unreadable blocks, but without the sync, change the address of record, as the image (disco.dd) of the disc would have a final size wrong, less than that of the disc original.
2)

Sync - The flag sync forces dd to write the blocks of the size you choose (eg BS = 32K) and if there are not enough data to fill the block, it will be filled with zeros (0s padding). This creates a problem, the target image file size will have a multiple choice of BS. Eg if the source disc is 6Kb and BS = 4K, the image file size will have as 8Kb.

And with a BS = 32K and conv = noerror, sync, if we encounter bad sectors, but they belong to the read buffer of 32Kb, the DD should be configured as well to fill 32Kb of zeros, even sacrificing the health sector that there might be in those 32Kb. If there are only two bad sectors 512 bytes * 2 = 1024 bytes = 1Kb, 31Kb means that the remaining will be zero because dd has read a block from 32Kb met and made errors filling up the entire block of zeros bed. So the solution
would be to set up a dd with BS = 512, which is the minimum size of a sector, so as to read the disk, sector by sector, and if one of them is unreadable, it would be filled with zeros (sync), while the next sector (read) would be read correctly, preserving its contents.

dd if = / dev / sdb of = / conv = media/sdc1/disco.dd noerror, sync bs = 512
The problem with this configuration is that more stress on the hard disk, forcing a lot of readings ( sector by sector) and makes the process slower.
How to fix? There are alternative tools such as ddrescue
or
dc3dd
, which allow read larger blocks of 512 bytes, but when you are confronted with a mistake, they will use the minimum size of block size, 512 bytes and just fill with zeros.
DC3DD has the default blocksize of 32768 bytes (32Kb), in order to increase performance.
The file is calibrated on the final image size regardless of the source disk block size, so the image file size is exactly the same as if we had used a BS = 512.
Sector Error Recovery

When you encounter an error and the block size is larger than the area of \u200b\u200bthe source device, and the parameter conv = sync, noerror is set, the search dc3dd the top end of the block and try to read each indvidual sector, so the areas will be acquired good and bad will be replaced by zero.
This feature allows you to acquire the undamaged areas of the disc at higher speeds (as the BS = 32K), without losing any data blocks surrounding a bad sector.
To activate this mode is required to direct I / O mode enabled (iflag = direct on Linux, / dev / rdisk * Mac OS X). dc3dd if = / dev / sdb of = / conv = media/sdc1/disco.dd noerror, sync bs = 32k iflag = direct or



with ddrescue ddrescue-r3-d / dev / sdb / media/sdc1/disco.dd log.txt



In essence, the parameter
iflag = direct or
for ddrescue-d, is used to bypass the kernel cache (pagecache) * and go directly to disk (direct I / O), considering that the minimum size of the sector . Those wishing to use
DCFLDD with direct access can not use the parameter iflag = direct, since dcfldd is a fork of dd, and then does not follow the same development of the latter, but can access the source device in direct I / O via the / dev / raw (
to this document on raw devices in GNU / Linux
). It 'clear that forensic tend to use more as a tool DC3DD since it also features multiple automatic hashing, verification, etc..
Eg dc3dd if = / dev / sdb of = / conv = media/sdc1/disco.dd noerror, sync bs = 32k = iflag = direct progress on hash = md5, sha1 log = log.txt vf = / dev / sdb verifylog = log_verifica.txt
* The page cache is the place where the kernel keeps a copy of the data in RAM to improve performance by avoiding I / O of the disk, where data must be read is already in RAM. DC3DD is based on DD, then iflag = direct also works with DD.