Re: [Bug-ddrescue] Re: Looking to use Linux for data recovery on a dead XP hard drive

[DePriest, Jason R.]

On 9/6/07, James W. Watts  wrote:
> Reading the image from the rescue drive that I DBAN'ed produced the same 
> results as before. Still
> only showed a partial recovery. And the files it did show were unreadable.
>
> I guess the filesystem is damaged, as Antonio suggested. Is there any way to 
> repair it?
>
> James
>
>
> James W. Watts wrote:
> > # Rescue Logfile. Created by GNU ddrescue version 1.3
> > #      pos        size    status
> > 0x00000000  0x1321301C00    +
>
> The logfile says that ddrescue recovered 82161179648 bytes (82GB)
> without errors. If you can't mount the image produced by ddrescue it
> should be because the filesystem in the (aparently not) damaged drive is
> corrupt.
>
> If the rescue drive is larger than the damaged drive the comparison is
> going to fail, and the rescue drive will contain at the end whatever
> data left there by earlier uses of the drive. Wiping the rescue drive
> with DBAN will make a difference on the files recovered with Get Data
> Back, but won't remedy other errors the filesystem may have.
>
>
> Regards,
> Antonio.
>

You could download The Sleuthkit (http://www.sleuthkit.org) and try
some of tools from there on the image.

For example.  I have a drive attached to a system via a Firewire
hardware write-blocker.

Example follows -
img_stat - Display details of an image file
mmstat - Display details about the media management system (partition tables)
mmls - Display the layout of media management systems (partition tables)
fsstat - Display details of a file system

You can see how each command builds on the information provided by the
previous one.

address@hidden /TSK
$ /TSK/sleuthkit/bin/img_stat -t /dev/sdc
raw
address@hidden /TSK
$ /TSK/sleuthkit/bin/mmstat -i raw /dev/sdc
dos
address@hidden /TSK
$ /TSK/sleuthkit/bin/mmls -i raw -t dos /dev/sdc
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  -----   0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000001   0000000062   0000000062   Unallocated
02:  00:00   0000000063   0361705406   0361705344   Win95 FAT32 (0x0C)
03:  -----   0361705407   0361882079   0000176673   Unallocated
address@hidden /TSK
$ /TSK/sleuthkit/bin/fsstat -o 63 -i raw -f fat32 "/dev/sdc"
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT32

OEM Name: MSWIN4.1
Volume ID: 0xd6d6
Volume Label (Boot Sector): Lanex LLC
Volume Label (Root Directory):
File System Type Label: FAT32
Next Free Sector (FS Info): 215912422
Free Sector Count (FS Info): 4092157856

Sectors before file system: 63

File System Layout (in sectors)
Total Range: 0 - 361705343
* Reserved: 0 - 31
** Boot Sector: 0
** FS Info Sector: 1
** Backup Boot Sector: 6
* FAT 0: 32 - 88338
* FAT 1: 88339 - 176645
* Data Area: 176646 - 361705343
** Cluster Area: 176646 - 361705317
*** Root Directory: 176646 - 176677
** Non-clustered: 361705318 - 361705343

METADATA INFORMATION
--------------------------------------------
Range: 2 - 5784459170
Root Directory: 2

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 16384
Total Cluster Range: 2 - 11297772

FAT CONTENTS (in sectors)
--------------------------------------------
176646-176677 (32) -> EOF
176678-176709 (32) -> EOF
176710-176741 (32) -> EOF
176742-176773 (32) -> EOF
... lots of stuff I hit ctrl-c

There are lots of other commands you can use.  I wouldn't recommend
the Autopsy front-end unless you find a way to stabilize your image a
bit.

Note the offsets from mmls if you get that far.  I had a drive that
was unmountable because the partition table was in a non-standard
offset.  I was able to hit it with the tools from the command-line,
but Autopsy was not able to see it because it was not as configurable
as the command-line tools it communicates with.

-Jason