Jump to content

Wrote .img (Image file) to wrong drive - how to recover it now?


Recommended Posts

Hi,

I was attempting to write an .img file (akin to .iso image) to my SD card using Win32diskimager (found here: http://sourceforge.net/projects/win32diskimager/files/?source=navbar)

By mistake I wrote the image to my external HDD (Seagate BackupPlus 3TB). BTW, as you can read from SourceForge page, many others have made same mistake.

The HDD was not modified and had the factory setting; that is, it had one partition and was NTFS file.

The content of IMG file were no more than 73MB, but it created a FAT32 partition of 500MB.

My Linux and Win8 machines both see (but don't mount) the 500MB partition and show the rest as "unallocated" or "raw".

Windows wants to reformat this space.

I have access to another drive that is just like this (I bought two orginally) - that is, I have another spare 3TB Seagate BackupPlus that is empty.

Using CloneZilla I have copied (bit-for-bit, or sector by sector) a clone of the 'damaged' drive to the 'spare' drive. I will be using this clone for all recovery purposes and will leave the 'damaged' disk in a safe place.

TestDisk doesn't find any partitions (both quick and deep scan).

My understanding is that NTFS writes a copy of partition at the end of the sector (or was it copy of MBR to the end?).

Considering that TestDisk is not finding this partition (or for that matter vloume/FS); how can I recreate a partition?

Also, I think the files might be 'carved' or 'recovered', but this would imply I lose both the original file names as well as the directory structure.

If the partition recovery is a lost cause, is there a way to recover the files and directories with their original intact names?

Thanks in advance....I do know that I have done something really stupid and blame is all on me.

Link to comment
Share on other sites


PS. I also want to point out that I have read the following posts on this site, the situations others had were similar, but not same.

The solutions offered by jaclaz were spot on for these situations, but aren't specific to my case (as I only had one NTFS partition and also a MUCH larger drive).

I have read the following posts:

http://www.msfn.org/...howtopic=141687

http://www.msfn.org/...howtopic=141448

http://www.msfn.org/...howtopic=140675

http://www.msfn.org/...howtopic=133933

Link to comment
Share on other sites

TestDisk doesn't find any partitions (both quick and deep scan).

That seems to me the problem, it should.

Basically you want to get a disk editor and go around sector 786432*8=6291456 and start searching for the text string "FILE0".

Depending on the amount of "hidden sectors" before (they used to be 63, but nowadays they are more likely to be 2048) you should find it between 6291456+63 and 6291456+2048, if the search flips sectors much beyond, stop it (it is possible than on a 3TB volume the $MFT is moved on a higher address, the 786432 is the "standard" from around 5/6 Gb up, but cannot say if it has a "limit" on such a large hard disk)

Try also another thing.

Go very near (say 20000 sectors before) the end of the disk (i.e. go to last sector and go back some 20000 sectors), then start searching for text string "NTFS".

Post if you can find any of those, and where exactly (the first should be the first sector of the $MFT and the second the backup bootsector) you found them, if they are found (and they are valid), it is possible to rebuild the filesystem (of course anything that was in either the 73 or 500 Mb is anyway lost forever as it has been overwritten :( - cannot say if the thingy applies the whole 500 Mb or just the "written" sectors, i.e. probably the 73 Mb).

jaclaz

Link to comment
Share on other sites

Thanks jaclaz.

Here is an image of the details of this drive model from another forum. This isn't my drive, but the same exact model and capacity. The image provides all the details of this drive (clusters, blocks, etc.).

Permit me a few hours to report back as I need to create another clone. The clone on the 'spare' drive has been messed around with too much.post-383795-0-57193800-1383613066_thumb.

Edited by online789
Link to comment
Share on other sites

I ran into a little trouble trying to clone the 'damaged' drive using CloneZilla. This might be a noob problem.

CloneZilla only copies the 500MB 'partition', even if I ask it to do a sector by sector copy in Adanced Menu.

I know there are Windows based disk cloning tools, but I don't have much experience with any of them and rather stick with a bootable USB based solution.

Could anyone recommend a method to clone the entrie 'damaged' drive to the 'spare' drive?

Could dd method work? (as in sudo dd if=/dev/sdc of=/dev/sdd)

Mind you:

  • The two drives are exactly the same make and model, Seagate BackupPlus 3TB
  • Both are 3TB in size and have the same exact geometry/attributes
  • Since they are 3TB, I believe they are not MBR drives and are GPT (GUID Partition Table)
  • The 'damaged' drive was written over with a bootable image (.img file)
    • This IMG was to create an Android based bootable SD card, with boot sector and MBR and all that jazz
  • It created a 500MB partition and the rest of the 'damaged' drive is considered raw (and it seems CloneZilla ignores it)

Thanks in advance for your help.

Link to comment
Share on other sites

Clonezilla is one of one among the many misnamed tools. it is not really really a "cloning" tool. :(

From Linux yes, you want to use good. ol', plain dd.

When you do a "dd" image (or byte by byte, or sector by sector, or "forensic sound"), in this case a "dd clone", *nothing* (meaning GPT or MBR) actually matters, dd simply copies *whatever* it finds.

From the image you posted, it is confirmed that the values I gave earlier are valid.

The difference is that your hard disk has "large" sectors (i.e. 4096 bytes each), so the $MFT still starts at cluster 786,432, but cluster 786,432 corresponds to sector 786,432*1=786,432, and the hidden sectors are 2,048, so the start of the $MFT should be at sector 786,432+2,048=788,480.

In any case 786,432*4096=3,221,225,472, i.e. roughly 3 Gb, so, even if the whole 500 Mb were written it should still be there. :)

Same goes for finding the bootsector mirror, now that we know the size of the partition, it is on the last sector of the partition, 732.565.503.

Still from the images you posted, the disk is definitely "MBR".

There are no problems to manually create the MBR partition entry for the "old" partition, copy back the bootsector mirror to the bootsector, and then the disk should become accessible (though not yet bootable), in this particular case, provided that the presence of the $MFT and of the bootsector mirror is confirmed, and provided that the disk is fully fuinctional, there is actually no real reason to make the image or clone.

jaclaz

Link to comment
Share on other sites

Thanks again for your detailed explanation and help. One more question...

What is the best disk editor that you would recommend? I am interested only in Linux version.

I used Active@ Disk Editor but I'm not happy with its ability to search range of sectors.

Edited by online789
Link to comment
Share on other sites

Well, I am not particularly familiar with Linux disk/hex editors, I would probably try using:
http://www.wxhexeditor.org/home.php

but here you are in a "subset" of the original issue, we now know, with very good approximation where to look.
So you can simply dd the two sectors to file with dd and have a look at them with *any* hex editor.
Let's assume that your disk is sdc:

dd if=/dev/sdc of=mymft.bin bs=4096 skip=788480 count=1
should extract the first sector of the $MFT to mymft.bin
and
dd if /dev/sdc of=myboot.bin bs=4096 skip=732567551 count=1
should do the same for the first sector of the bootsector.

This said, what I personally use (and recommend) in similar cases (for Windows) is DMDE:
http://dmde.com/
which is a nice tool with a number of useful function, tools, very friendly licensed (Free for almost all functions and for recovery of single items, pay a very fair amount of money for recovery of multiple items).
There is for it a Linux (console) version which I have never personally used but that I expect to have same or similar functions to the GUI Windows version I normally use.
At least the windows version is fastish/very good at searching/finding the $MFT and at navigating on a disk or image.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Update.....

I had to objectives that needed to be met in order to make this work:

1. Clone the 'damaged' drive

2. Repair the 'cloned' drive to get to my files + directories

From my previous posts, you will see I had trouble with both. Alas, I have solved both issues.

1. Cloning:

In order to clone the drive, I used the trusty 'dd' command in Linux.

I downloaded the latest Ubuntu 13.10 USB in 64 bit (64 bit since my computer could support it and I needed all the horsepower).

Ubuntu was run as in "Live" mode.

I installed 'pv'. A program that helped me gauge the time it takes for dd to finish cloning my drive. PV is a tools that measures the "pipe" transfer from A to B. It also has a 'progress bar' in addition to ETA and Time elapsed. Really useful if you are trying to clone a huge drive like mine (3TB mind you).

Word of caution: be very careful with dd as if you get the name of physical drives wrong, there is no way to undo writing the wrong drive. (ie, don't mess up the 'source' and 'target').

The command for cloning drive sda to sdb with pv is:

sudo dd if=/dev/sda bs=4M | pv -s 3000G | sudo dd of=/dev/sdb bs=4M

Where bs=4M gives you the read ahead block size to 4MB. Supposedly this makes things go faster

3000G is the size of my drive, this is needed to tell pv the size to copy such that it can track progress

/dev/sda = was my source

/dev/sdb = was my target

2. Recovery:

After reading (for days on end...) all various sources as how to recover my $MFT and $MFTmirror (as well as the boot sector), I just gave up!

I tried several (including one that was recommend on this post) but I couldn't find a "free" disk editor that could actually find these two important blocks.

Granted it could have been my noob status with these tools (like I don't know the difference between offset and sector), but I ran out of patience.

So, I did the next best thing...I used a commercial Windows based software.

In this case I used Active@ NTFS partition recovery by LSoft. But I am sure there are many other tools out there that could do this. I am not trying to advertise for these guys.

It's only $money and after it showed me that it saw the directories I decided to get the full version.

The free version didn't allow me to restore, but the paid license let me do this.

So now I have my cloned drive with all the directories and files appearing as they were before the initial screw up.

A few notes for others benefit:

-While it is true that $MFTmirror only contains the few sectors of $MFT with info on directories and file information (Master File Table), somehow in combination with the tool I used it did aid in finding the directory structure.

-TestDisk kept thinking this is a FAT32 file syste. Which it clearly wasn't. The IMG was FAT32, but the original FS should have been NTFS. TestDisk (both quick and in depth) thought it had the wrong geometry. Even after correcting the geometry of my drive (from pictures that I posted), it wasn't able to find the file system.

-CloneZilla doesn't really do a drive clone, it only wanted to clone the partition it saw. I needed a drive clone.

-Ubuntu is a kick-arse OS, definitley try it (ok, this is besides the point)

Thanks to all for your help...please post your questions, perhaps my experience can help you resolve your problems.

Link to comment
Share on other sites

Well, as a matter of fact - and just for the record - the mentioned DMDE has a free edition and at least in it's Windows version (which you excluded using) is normally capable - believe me - to find a $MFT, and also as said, I already provided the actual addresses where to check (based on the data you provided).

So there was not - specifically - any need to "search", only to verify if those addresses were correct.

In any case, happy that you managed to recover your files :).

jaclaz

Link to comment
Share on other sites

Jaclaz,

Firstly, I owe you an apology as I was supposed to provide you results of my search for the NTFS and FILE0 after scanning my HDD, but never did.

You were able to correctly identify the location of the $MFTmirror (I believe) and I was able to save it to a file. This was fantastic, thank you.

I wasn't able to find the NTFS entry, however. This has everything to do with me and nothing to do with the actual tool you had recommended.

Indeed, I did use Windows based version of DMDE as you had suggested. But lack of my understanding of the innerworkings of NTFS file structure I didn't exactly know how to look for the right sector.

Additionally, I used the other tool (not DMDE) to locate the NTFS entry and it found the sector. I was actually able to write the boot record back to sector 0. My challenge was I didn't know what to do with the $MFTmirror and what sector to write to.

Again, I think this had to do with not knowing how the filesystem is organized.

Second, I fully agree that recovery would have been possible without use of a commercial 'recovery' tool. And DMDE (or any other disk editor) seems to have been the right tool had I known how to use it.

Having said point 1 and 2, I would think the average person who has a similar problem as I, most probably doesn't have the expertise required in this type of forensic recovery using disk editor.

For this reason my person suggestion is to use a commercial 'recovery' tool that automatically discovers and restores both NTFT as well as the $MFT. It would have saved me a tremendous amount of time if I had started that way instead of searching for sectors and strings and going with disk editor. Again, this is due to lack of knowlege of the underlying file system and no fault of the DMDE (or any other disk editor) tool. It is just a matter of judgement considering the expertise needed and the time and effort required to do the right thing.

To recap....

...if you are looking for a solution to the problem of flashing IMG file to the wrong HDD (instead of USB/SD card), the best method for me was:

1. Clone the 'damaged' HDD using a Linux tool called "dd" (available in most Linux/FreeBSD distros). Most other tools (such as CloneZilla) will only copy the partition and not the disk bit by bit (sector by sector).

2. If TestDisk (either Windows, Linux, or MacOS) doesn't find the lost paritions (in my case it didn't since the IMG changed boot sector and geometry of the drive), use a commercial 'recovery' tool that is capable of doing a deep analysis and discovery of NTFS.

2.a. I don't know what tools might be available to solve other file system types (for example, FAT32, Rieser, HFS, EXT4, ZFS, etc.).

Thanks again to Jaclaz for his devotion to this board and continued support.

Edited by online789
Link to comment
Share on other sites

You are very welcome, I am sure :).

Just to clear the matter re: Clonezilla, one must understand that each tool has it's own little "quirks" (and a designed scope) and every situation is a bit different.

In your particular case you had not a "failed/corrupted" filesystem, but rather you had a perfectly sound FAT32 filesystem (and you had it on an perfectly working disk).

Clonezilla, is designed for cloning of valid filesystems, and among it's features is to copy only used (meaning filled with data AND properly indexed by the filesystem) sectors, this is among it's "features" as it speeds sensibly the copy.

Filesystem supported: (1) ext2, ext3, ext4, reiserfs, reiser4, xfs, jfs, btrfs of GNU/Linux, (2) FAT12, FAT16, FAT32, NTFS of MS Windows, (3) HFS+ of Mac OS, (4) UFS of FreeBSD, NetBSD, and OpenBSD, (5) minix of Minix, and (6) VMFS3 and VMFS5 of VMWare ESX. Therefore you can clone GNU/Linux, MS windows, Intel-based Mac OS, FreeBSD, NetBSD, OpenBSD, Minix and VMWare ESX, no matter it's 32-bit (x86) or 64-bit (x86-64) OS. For these file systems, only used blocks in partition are saved and restored. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla.

the "mistake" or the "misleading" is to call this procedure a "clone" (as it is not, or better it is a clone at filesystem level, but not at physical disk one).

But Clonezilla does contain also dd and ddrescue, so you can use it as well to make such a copy, only you won't be "guided" by the scripted interface.

Still for the record, what you found was the actual $MFT (not the $MFTMirr), the $MFTMirr is a copy of the first four sectors of the $MFT and it's location is - in my experience - "variable", as such it is not easy to find without having a valid bootsector.

The location of the $MFT is on the other hand "almost always" (i.e. for any partition/filesystem) bigger than around 5-6 Gb in a given location on cluster 786432.

The bootsector on NTFS is actually a file, called $boot, 16 sectors in size that is at the very beginning of the filesystem.

The only part really needed to access a filesystem is it's first sector which is mirrored in a bootsector mirror.

This mirror of the bootsector was once (NT3.5 and 4.0) placed in the middle of the filesystem, on "modern" NTFS it is on the last section of the partition space (first sector outside the filesystem/volume) and as such normally easily found.

Using a disk editor (personally I use the good ol'Tiny Hexer on windows) or a "low level" tool like DMDE is of course not the easiest thing to do and a background on the innards of the filesystem that you want to recover are needed.

Free tools (like the mentioned TESTDISK, which is an exceptionally good/useful program) or Commercial tools like the one you used (which does have a "good reputation") are obviously much easier (though in some occasions more seemingly easy that what they actually are) but, on the other hand, they tend more or less to be targeted to "more common" situations.

TESTDISK was probably tricked by the fact that you had a perfectly good MBR and FAT32 filesystem (or possibly you :w00t: were tricked by it's seemingly "easy" way of use), as it is most peculiar that there was a valid $MFT and TESTDISK was not capable of detecting it :unsure:.

In any case it is obvious that if it was "so easy" to recover data with manual, free tools, Commercial "advanced" tools would have no reason to exist, the choice of using the simpler free tools comes at the price :ph34r: of needing to know what exactly to do with them, and such knowledge does have a cost (but is also, in my perverted mind, "fun" :yes:), on the other hand Commercial tools are often a quicker way, the essence is however that of first thing making the clone/image, this way if one tool fails, you can always restore the image and try with another tool, (and if you fail anyway, this gives you anyway an option to have an untouched copy to give to a professional data recovery service).

Some time ago I jolted down my personal "rules" ;):

http://www.msfn.org/board/topic/84345-data-recovery-tool/#entry572375

jaclaz

Link to comment
Share on other sites

  • 1 year later...

First I'd like to say: God bless both of ya, online789 and jaclaz!!!

 

Well, I had a linux iso on an external 1 TB ntfs drive. The drive was mounted into mnt. From this folder I just wanted to dd that linux iso to a usb stick but somehow the letters got mixed and I dd-d it to the drive itself (I just noticed that the usb stick is not blinking at all and after several seconds realised why). Well, yeah, everything was gone, it wiped out the ntfs partition, replaced it by a fat one and the drive booted as a linux live usb.

 

First I did try to make an image of the drive but after several hundreds Gig I had some i/o errors and it stopped (no idea why). Testdisk did not work for me either. Anyway this thread showed me the correct direction and in the end I tried dmde and lsoft active@ partition recovery.

 

While dmde did work fine, I realised that there were some empty folders it could not recover. Active@ partition recovery did find the partition I wanted to recover after a short search (as there was only one big ntfs partition to recover). Btw you need the pro version in order to use all the functions and you can use it to create an image too. However the option "recover to an other drive" gave me an error message and somehow it did not work. Therefore I tried Lsoft active file recovery and it was possible to recover the folders one by one to an other drive.

 

After that I've tried to recover the partition on the drive itself with active@ partition recovery (in supersearch it even showed the correct name of the drive and the file tree). In the side menü, where you can see the "given" state of the drive, it showed the fat partition for me, which I deleted first. After that I did run the recovery function, but somehow it did not seem to work (after I clicked it, it only showed a new volume on the disk, which was not recognized by the windows file manager). The solution was to close the software after recovery and run chkdsk /f on the drive. In the end all the folders and files were there again.

 

Long story short: If you had this kind of issue with an ntfs drive, you could consider the following: 1. Make an image (via active@ partition recovery or some other way you like) 2. Try active@ file recovery in order to recovery your folders to an other drive. 3. Try active@ partition recovery in order to recover the whole partition on the drive itself. After running the recovery function, if it does not seem to work, close the software and run chkdsk /f on the drive.

 

Well, online789 and jaclaz, God bless both of ya, thank you for this thread!

Link to comment
Share on other sites

You are welcome. I am sure. :)

 

The good thing about your misadventure is that very likely the .iso was a rather smaller file, either within the 700 mb or so size of a CD or the around 4 Gb of the DVD size, so that the $MFT was surely not affected by the overwrite.

 

Even more than that the "copying on self" very likely ended up in only a partial copy of the original .iso (as at some point during the copy process the "target" voliume is likely to have "vanished" :unsure:), and thus very little was overwritten anyway.

 

jaclaz

Link to comment
Share on other sites

Well, it was a 3.1 Gig iso of a linux distro and the dd process did last for a short period of time (maybe around 2 minutes) as I used ctrl+c after realising the mixed drives. Interestingly the drive was able to boot the distro live menü already. Now, after the recovery the drive is basically in the same state as it used to be, all the folders and files are there and working fine on Windows or Linux (yes, thankfully the $MFT was surely not affected).

It's interesting though that lately using the drive on Ubuntu still lead to a recognition of the fat-partition as it showed the distro name and the partition type. Plugging the drive in again it started to work fine with ntfs.

Well, I have a full backup of that drive now (and all the other drives for that matter). :cool::)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...