Difference between pages "Ddrescue" and "Encase image file format"

From Forensics Wiki
(Difference between pages)
Jump to: navigation, search
 
 
Line 1: Line 1:
{{Infobox_Software |
+
[[EnCase]] uses a closed format for images which is reportedly based on [http://www.asrdata.com/SMART/whitepaper.html ASR Data's Expert Witness Compression Format]. The evidence files, or E01 files, contain a physical bitstream of an acquired disk, prefixed with a '"Case Info" header, interlaced with CRCs for every block of 64 x 512 byte sectors (32 KiB), and followed by a footer containing an MD5 hash for the entire bitstream. Contained in the header are the date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password; the header concludes with its own CRC.
  name = ddrescure |
+
  maintainer = [[Antonio Diaz Diaz]]|
+
  os = {{Linux}}|
+
  genre = {{Disk imaging}} |
+
  license = {{GPL}} |
+
  website = [http://www.gnu.org/software/ddrescue/ddrescue.html http://www.gnu.org/software/ddrescue/ddrescue.html] |
+
}}
+
  
'''ddrescue''' is a raw disk imaging tool that "copies data from one file or block device to another, trying hard to rescue data in case of read errors."  The application is developed as part of the GNU project and has written with UNIX/Linux in mind.
+
EnCase can store media data into multiple evidence files, which are called segment files. Each segment file consist of multiple sections. Each section consist of a section start definition. This contains a section type.
  
'''ddrescue''' and '''[[dd_rescue]]''' are completely different programs which share no development between them.  The two projects are not related in any way except that they both attempt to enhance the standard [[dd]] tool and coincidentally chose similar names for their new programs.
+
Up to EnCase 5 the segment file were limited to 2 GiB, due to the internal 31-bit file offset representation. This limitation was lifted using a base offset work around in EnCase 6.
  
From the [[ddrescue]] info pages:
+
At least from Encase 3 the case info header is contained in the "header" section, which is defined twice within the file and contain the same information.
<blockquote>
+
GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors.<br><br>
+
  
Ddrescue does not truncate the output file if not asked to. So, every time you run it on the same output file, it tries to fill in the gaps.<br><br>
+
With Encase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.
  
The basic operation of ddrescue is fully automatic. That is, you don't have to wait for an error, stop the program, read the log, run it in reverse mode, etc.<br><br>
+
Version 3 of The Encase F introduced an "error2" sections that it uses to record the location and number of bad sector chunks. The way it handles the sections it can't read is that those areas are filled with zero. Then Encase displays to the user the areas that could not be read when the image was acquired. The granularity of unreadable chunks appears to be 32K.
  
If you use the logfile feature of ddrescue, the data is rescued very efficiently (only the needed blocks are read). Also you can interrupt the rescue at any time and resume it later at the same point.<br><br>
+
Within Encase 5 the number of sectors per block (chunk) can vary.
  
Automatic merging of backups: If you have two or more damaged copies of a file, cdrom, etc, and run ddrescue on all of them, one at a time, with the same output file, you will probably obtain a complete and error-free file. This is so because the probability of having damaged areas at the same places on different input files is very low. Using
+
Encase from at least in version 3 can hash the data of the media it acquires.
the logfile, only the needed blocks are read from the second and successive copies.
+
It does this by calculating a MD5 hash of the original media data and adds a hash section
</blockquote>
+
to the last of the segment files. Later versions of Encase 6 also include a SHA1 hash.
  
== Installation ==
+
== See Also ==
=== Debian ===
+
The package 'ddrescue' actually is [[dd_rescue]], another dd-like program which does not maintain a recovery log.
+
<blockquote>
+
aptitude install gddrescue
+
</blockquote>
+
  
== Partition recovery ==
+
[[EnCase]]
  
=== Kernel 2.6.3+ & ddrescue 1.4+ ===
+
== External Links ==  
'ddrescue --direct' will open the input with the O_DIRECT option for uncached reads. 'raw devices' are not needed on newer kernels. For older kernels see below.
+
  
First you copy as much data as possible, without retrying or splitting sectors:
+
* [https://downloads.sourceforge.net/project/libewf/documentation/EWF%20file%20format/Expert%20Witness%20Compression%20Format%20%28EWF%29.pdf Expert Witness Compression Format (EWF)].
<blockquote>
+
* [http://www.cfreds.nist.gov/v2/Basic_Mac_Image.html Sample image in EnCase, iLook, and dd format] - From the [[Computer Forensic Reference Data Sets]] Project
ddrescue --no-split /dev/hda1 imagefile logfile
+
</blockquote>
+
  
Now let it retry previous errors 3 times, using uncached reads:
+
[[Category:Forensics File Format]]
<blockquote>
+
ddrescue --direct --max-retries=3 /dev/hda1 imagefile logfile
+
</blockquote>
+
 
+
If that fails you can try again but retrimmed, so it tries to reread full sectors:
+
<blockquote>
+
ddrescue --direct --retrim  --max-retries=3 /dev/hda1 imagefile logfile
+
</blockquote>
+
 
+
You can now use ddrescue (or normal dd) to copy the imagefile to a new partition on a new disk. Use the appropriate filesystem checkers (fsck, CHKDSK) to try to fix errors caused by the bad blocks. Be sure to keep the imagefile around. Just in case the filesystem is severely broken, and datacarving tools like testdisk need to to be used on the original image.
+
 
+
=== Before linux kernel 2.6.3 / 2.4.x ===
+
In 2.6.3 the 'raw device' has been marked obsolete. On later kernels ddrescue will use O_DIRECT on the input to do uncached reads.
+
 
+
First you copy as much data as possible, without retrying or splitting sectors:
+
<blockquote>
+
ddrescue --no-split /dev/hda1 imagefile logfile
+
</blockquote>
+
 
+
Now change over to raw device access. Let it retry previous errors 3 times, don't read past last block in logfile:
+
<blockquote>
+
modprobe raw<br>
+
raw /dev/raw/raw1 /dev/hda1<br>
+
ddrescue --max-retries=3 --complete-only /dev/raw/raw1 imagefile logfile
+
</blockquote>
+
 
+
If that fails you can try again (still using raw) but retrimmed, so it tries to reread full sectors:
+
<blockquote>
+
ddrescue --retrim --max-retries=3 --complete-only /dev/raw/raw1 imagefile logfile
+
</blockquote>
+
 
+
You can now use ddrescue (or normal dd) to copy the imagefile to a new partition on a new disk. Use the appropriate filesystem checkers (fsck, CHKDSK) to try to fix errors caused by the bad blocks. Be sure to keep the imagefile around. Just in case the filesystem is severely broken, and datacarving tools like testdisk need to to be used on the original image.
+
 
+
At the end you may want to unbind the raw device:
+
<blockquote>
+
raw /dev/raw/raw1 0 0
+
</blockquote>
+
 
+
== Examples ==
+
 
+
These two examples are taken directly from the [[ddrescue]] info pages.
+
 
+
Example 1: Rescue an ext2 partition in /dev/hda2 to /dev/hdb2
+
<blockquote>
+
ddrescue -r3 /dev/hda2 /dev/hdb2 logfile<br>
+
e2fsck -v -f /dev/hdb2<br>
+
mount -t ext2 -o ro /dev/hdb2 /mnt<br>
+
</blockquote>
+
 
+
Example 2: Rescue a CD-ROM in /dev/cdrom
+
<blockquote>
+
ddrescue -b 2048 /dev/cdrom cdimage logfile
+
</blockquote>
+
write cdimage to a blank CD-ROM
+
 
+
 
+
This example is derived from the ddrescue manual.
+
 
+
Example 3: Rescue an entire hard disk /dev/sda to another disk /dev/sdb
+
 
+
copy the error free areas first
+
ddrescue -n /dev/sda /dev/sdb rescued.log
+
attempt to recover any bad sectors
+
ddrescue -r 1 /dev/sda /dev/sdb rescued.log
+
 
+
 
+
== Cygwin ==
+
 
+
As of release 1.4-rc1, it can be compiled directly in [[Cygwin]] [http://en.wikipedia.org/wiki/Out_of_the_box Out of the Box]. Precompiled packages are available in the [http://cygwin.com/packages/ Cygwin distribution]. This makes it usable natively on [[Windows]] systems.
+
 
+
== See also ==
+
 
+
* [[aimage]]
+
* [[Blackbag]]
+
* [[dcfldd]]
+
* [[dd]]
+
* [[dd_rescue]]
+
* [[sdd]]
+

Revision as of 14:13, 17 December 2010

EnCase uses a closed format for images which is reportedly based on ASR Data's Expert Witness Compression Format. The evidence files, or E01 files, contain a physical bitstream of an acquired disk, prefixed with a '"Case Info" header, interlaced with CRCs for every block of 64 x 512 byte sectors (32 KiB), and followed by a footer containing an MD5 hash for the entire bitstream. Contained in the header are the date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password; the header concludes with its own CRC.

EnCase can store media data into multiple evidence files, which are called segment files. Each segment file consist of multiple sections. Each section consist of a section start definition. This contains a section type.

Up to EnCase 5 the segment file were limited to 2 GiB, due to the internal 31-bit file offset representation. This limitation was lifted using a base offset work around in EnCase 6.

At least from Encase 3 the case info header is contained in the "header" section, which is defined twice within the file and contain the same information.

With Encase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.

Version 3 of The Encase F introduced an "error2" sections that it uses to record the location and number of bad sector chunks. The way it handles the sections it can't read is that those areas are filled with zero. Then Encase displays to the user the areas that could not be read when the image was acquired. The granularity of unreadable chunks appears to be 32K.

Within Encase 5 the number of sectors per block (chunk) can vary.

Encase from at least in version 3 can hash the data of the media it acquires. It does this by calculating a MD5 hash of the original media data and adds a hash section to the last of the segment files. Later versions of Encase 6 also include a SHA1 hash.

See Also

EnCase

External Links