NTFS Raw Drive Error- Recovery with Clone

[gavinsth]

I have a WD 1600bevt 160 gigabyte hdd that came from an old Compaq laptop running Windows Vista.
Like was recommended, I made a clone of the drive onto my computer.

I used a file recovery utility which did manage to pull off individual files, but they are all corrupted. Some thumbnails show up correctly, but the full picture does not.
Primary concern is wedding pictures. I tired taking a copy of a couple files and using the hex-editor trick, but to no avail.

I've been attempting to use DMDE to recover files, but have been presented with some errors, and now I don't know where to go. When I open the volume, the logical file structure appears to be intact.
Some volumes are missing indicators.

There's a lot of red MFT Attribute offest errors.

Any help you can provide is much appreciated.
Anything screenshots, logs, or text, let me know.
Thanks

[fzabkar]

Could you start by showing us DMDE's Partitions window?

[lcoughey]

What did you use to clone it with?

[gavinsth]

Could you start by showing us DMDE's Partitions window?

See attachment.

[img]

What%20did%20you%20use%20to%20clone%20it%20with?

[/img]

I used teskdisk to output a .dd image.

Thanks

Attachments

I'm assuming this is what you wanted.

[fzabkar]

I meant something like this:

http://forum.hddguru.com/download/file.php?id=14372&mode=view

[gavinsth]

I meant something like this:

http://forum.hddguru.com/download/file.php?id=14372&mode=view

Whoops, here's that screenshot as requested.

Attachments

[fzabkar]

It looks like you have cloned your source drive to a partition on the target???
Normally you would clone a physical drive to another physical drive, or to an image file.

Also, I don't understand how $NoName03 can extend beyond the last sector of the physical drive. In any case $NoName02 appears to be the most likely candidate, although the Indicators are telling us that its Boot sector and MFT are missing.

[gavinsth]

It looks like you have cloned your source drive to a partition on the target???
Normally you would clone a physical drive to another physical drive, or to an image file.

Also, I don't understand how $NoName03 can extend beyond the last sector of the physical drive. In any case $NoName02 appears to be the most likely candidate, although the Indicators are telling us that its Boot sector and MFT are missing.

So I did clone the drive to an image. I'm using the OSFMount utility to make the drive accessible to DMDE because the clone is a .dd format.

So from my understanding, if the MFT and Boot Sector are missing, is there any way I can go about recovering this data?

[fzabkar]

ISTM that you dd-ed a physical drive to an image file, then used OSFMount to mount the physical disk as a logical volume. If so, then that doesn't make sense. Instead you should mount the dd image directly in DMDE by selecting the Disk Image radio button in the opening window.

[gavinsth]

ISTM that you dd-ed a physical drive to an image file, then used OSFMount to mount the physical disk as a logical volume. If so, then that doesn't make sense. Instead you should mount the dd image directly in DMDE by selecting the Disk Image radio button in the opening window.

So, I did what you said. I assumed that since it wasn't listed in the file types when you get to the file explorer chooser.

What should I do from here?

[fzabkar]

Now what do you see in the Partitions window?

[gavinsth]

Now what do you see in the Partitions window?

This is what I see now.

Attachments

[fzabkar]

I would perform a Full Scan of $NoName02, with the NTFS and Raw checkboxes ticked. Hopefully there will be no MFT offsets this time.

BTW, how was the file system damaged/corrupted?

[gavinsth]

I would perform a Full Scan of $NoName02, with the NTFS and Raw checkboxes ticked. Hopefully there will be no MFT offsets this time.

BTW, how was the file system damaged/corrupted?

The results from the scan are in a picture below. I also saved a copy of the log for future reference. I'm not liking how much red I'm seeing.

TBH, I'm not quite positive on how it was corrupted. This is a friend's laptop. They told me that the battery died, so they had ordered a new battery from HP. I'm not sure if it happened right after, or what the specific time table was, but they couldn't get windows to boot. I've plugged the drive into multiple Linux, Windows and MacOS machines and none of them saw any data. They all showed the drive as unformatted/raw. I'm hoping that at the minimum, I can save some of their wedding photos that are on the drive. I've made a few successes pulling off some data, but a lot of what I have been able to pull of is corrupted. I'll attach a copy of one of the files that is corrupted. The thumbnail appears fine, but the image is not.

Attachments

20150906_125832.jpg

(1.98 MiB) Not downloaded yet

[fzabkar]

JPEG files begin with 0xFF 0xD8 and end with 0xFF 0xD9.

This is the full extent of your damaged JPEG:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  FF D8 FF E1 98 67 45 78 69 66 00 00 4D 4D 00 2A
........
001D3A10  28 00 A2 8A 28 00 A2 8A 28 00 A2 8A 28 03 FF D9
001D3A20  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you can see, there is a large section at the end of the file (0x1F9F6A - 0x1D3A20 = 0x2654A) which is "noise". AFAICS, the file's original (correct) size and starting cluster would have been reported in the corresponding MFT record. DMDE would then have assumed that the file was contiguous and assembled it accordingly. Unfortunately it appears that the file was in fact fragmented, and that DMDE was unable to locate all the fragments.

My image viewer software rejects the damaged JPEG as invalid, but Mozilla and Opera display the first contiguous section (0 - 0x16C65).

The thumbnail image is located between offsets 0x276 and 0x986A.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000270                    FF D8 FF DB 00 84 00 08 06 06
........
00009860  60 DC 3F 1A B7 45 14 58 0F FF D9

Am I permitted to upload the thumbnail image?

Attachments

[fzabkar]

@gavinsth, I have an idea how we might locate the last sector of your damaged JPEG.

If we assume that the file size is correct (ie 0x1F9F6A), then the last sector of the original file would have had an EOI (End Of Image) marker (ie 0xFF 0xD9) at offset 0x168.

Assuming that DMDE locates raw JPEGs (ie those without their original file name) by first searching for an SOI (Start Of Image) marker (ie 0xFF 0xD8) and then an EOI, then one or more of these raw images will have a length which is 0x16A plus a multiple of the sector size (0x200 x number of sectors). Alternatively, we could use a multiple of the cluster size (usually 4096 bytes), in which case the last cluster would have a size of 0xF6A bytes.

To this end, you could type the following in a Windows DOS box:

dir \recovered_raw_JPEGs_directory\*.jpg /s > jpeglist.txt

If you like, I could parse the resulting text file for suitably sized candidates. These candidates could then be patched into the damaged file.

[gavinsth]

@gavinsth, I have an idea how we might locate the last sector of your damaged JPEG.

If we assume that the file size is correct (ie 0x1F9F6A), then the last sector of the original file would have had an EOI (End Of Image) marker (ie 0xFF 0xD9) at offset 0x168.

Assuming that DMDE locates raw JPEGs (ie those without their original file name) by first searching for an SOI (Start Of Image) marker (ie 0xFF 0xD8) and then an EOI, then one or more of these raw images will have a length which is 0x16A plus a multiple of the sector size (0x200 x number of sectors). Alternatively, we could use a multiple of the cluster size (usually 4096 bytes), in which case the last cluster would have a size of 0xF6A bytes.

To this end, you could type the following in a Windows DOS box:

dir \recovered_raw_JPEGs_directory\*.jpg /s > jpeglist.txt

If you like, I could parse the resulting text file for suitably sized candidates. These candidates could then be patched into the damaged file.

Wanted to let you know that I saw your message. When I get the chance, I'll try it and let you know what happens. You could post the thumbnail.

[fzabkar]

@gavinsth, my approach might appear complicated or convoluted, but I have other ideas which may be simpler, assuming that we are able to recover your sample JPEG.

Attachments

thumb.jpg (37.49 KiB) Viewed 15151 times

[Arch Stanton]

I know it's an old thread. Just for future reference. I got a JPEG fetish so I had to look into it. Issue with that file is not that it's not complete. It's just corrupt as heck. After removing corrupt data that prevent file from decoding you can actually see the data is there.

[Arch Stanton]

Old case Spildit ..