Overclock.net banner

Help Restoring Win7 File Structure?

1K views 13 replies 2 participants last post by  joeybuddy96 
#1 ·
OS: Win7 x64 Professional

tl;dr: Get my drive un-reformatted.

I did a Quick Format in Disk Management, and I need to restore it to the normal file structure.

I don't have any recent system restore points. It all started when I noticed that there were two drives when there were supposed to be one in My Computer. One was the normal drive where all the files and Windows installation are stored, and the other drive had a different letter and was labeled System Reserved and had 100MB of space allocated. It was a partition of the main drive. One article I read said that the System Reserved drive is only used if you utilize BitLocker, which I do not. The article said the volume could be safely deleted from Disk Manager. I deleted the volume from disk manager, but there were still two partitions. I rebooted to make sure everything still worked, but it would no longer boot from that drive. So I followed more instructions from the Internet that said to format the 100MB partition and label it System Reserved, and from there I planned to copy-paste the files I'd copied off the drive prior to the deletion. What that ended up doing was renaming both partitions (despite being told from multiple sources it would only do it to the selected partition), and started to format the entire larger partition of the drive. I immediately closed Disk Manager, but the file directory had already been changed, and the drive contents couldn't be accessed from a completely different hard drive I'm using now. We used testdisk to restore write-capability to the System Reserved partition, and to make it appear as a separate drive from the larger portion, and now shows up as 98.9MB instead of 100MB. I copy-pasted the files back from the emergency backup windows bootable drive to the System Reserved partition. The goal now is to restore the file directory for the main drive so that the contents are accessible from any other drive booting into Windows, and restoring the System Reserved partition back the way it was before deleting the System Reserved partition. Do you know how to get the file structure and bootability back?

Please think before you post.
 
See less See more
#2 ·
That could be difficult. First of all, the second partition (the large one) needs to begin exactly where it previously did, so that old MFT offsets remain good. Next, the MFT offset data in the header of the partition needs to point to the old MFT. However, part of the MFT (including the important beginning which says where all the MFT's fragments are) could possibly be overwritten with the new blank MFT, which could make repair nearly impossible. Succeeding that, you will probably need to write a new boot sector to both the 1st and 2nd partitions.
For your information, the MFT file on the disk begins with "FILE0", which is also the beginning of a file record. The file records are usually 1,024 bytes long, and each one begins with "FILE0". The filename that the record is storing starts at the 243rd byte in after the "FILE0". Perhaps you could find the old MFT by searching for "FILE0" in a hex editor (I like HxD). I don't know where in the partition's header the MFT's offset is stored, however. And this would only work if the beginning of the old MFT was not overwritten with the new one.

Do you currently see both partitions, with the larger one being empty due to formatting? If so, it would might be easier to recover the files from the drive, reformat it, and put the recovered files back on the drive. I'm not certain how we would handle complicated reparse-point folders and linked files, however (I'm thinking of the mess in the Users folder). Try recovering files with Piriform Recuva. Go its settings dialog and turn on "Recover non-deleted files" and "Deep scan (increases scanning time)" before scanning the larger partition. Make sure that you recover the files to a totally different drive, or you will overwrite your data.
 
#3 ·
Let me know if I understand what is going on and what needs to be done before I do anything else:
"First of all, the second partition (the large one) needs to begin exactly where it previously did, so that old MFT offsets remain good." I need to find where the second partition originally began or if the beginning of the second partition has been moved or overwritten. You mentioned how to find the beginning of the MFT, but not how to find out the start of the partition.

Are the beginning of the partition and the beginning of the file record two different things?

I can find where the MFT begins by using HxD to search for "FILE0" and then counting 243 bytes after the FILE0 flag.

"Succeeding that, you will probably need to write a new boot sector to both the 1st and 2nd partitions." Earlier, you mentioned that overwriting the MFT would break the MFT and make it not bootable. I still have the contents from the smaller partition, and copy-pasted it from the backup drive to the first, smaller partition. How do I write the new boot sector without breaking anything?

I want to avoid having to extract the files rather than just restore the drive. I'm fine with doing it the hard way if it will restore bootability, since I don't have enough backup hard drive space to keep the extracted files. I'm wondering if Testdisk will help at all in restoring the drive. It has boot sector and MFT recovery, but right now the problem is that the larger partition reads as Free Space, because of the split-second reformat. I need to get it back to being a regular partition before it will be able to boot into the drive.

---
http://pastebin.com/CXeuf0jD
After running HxD, I searched for FILE0, and found it in Sector 16. I don't know how to go about counting exactly 243 bytes aside from doing it manually. The text bar next to the raw hex readout says near the middle of Sector 16 "$.M.F.T.". Other text of note says near end of Sector 0, "BOOTMGR is missing...BOOTMGR is compressed...Press Ctrl+Alt+Del to restart."

I ran a TestDisk cylinder analysis of the whole drive. It says that there are invalid FAT boot sectors, but the drive has always been formatted in NTFS. After it finished running the long scan in about three hours, it says that the harddrisk seems too small (see log). It also says that none of the partitions can be recovered (see log again). I'm thinking it's because TestDisk is not reading the disk geometry correctly. I don't want to actually change the geometry on the disk, just how it's being read to get TestDisk to perform a proper analysis.
 
#4 ·
Quote:
Originally Posted by joeybuddy96 View Post

Let me know if I understand what is going on and what needs to be done before I do anything else:
Quote:
Originally Posted by Techie007 View Post

That could be difficult. First of all, the second partition (the large one) needs to begin exactly where it previously did, so that old MFT offsets remain good.
I need to find where the second partition originally began or if the beginning of the second partition has been moved or overwritten. You mentioned how to find the beginning of the MFT, but not how to find out the start of the partition.
I mentioned this because you said something about partition 1 getting smaller. If all that was done to partition 2 was a quick format, and you did not run any programs that would change the offsets for partition 2 in the process of fixing partition 1, we shouldn't need to worry about this.
FYI, though, an NTFS partition begins with EB52904E 54465320 20202000 (ëR.NTFS .). In HxD, you would open the "Hard Disk 1" (or whichever one it is) to open the raw HDD with all the partitions. There should be 1 instance of the NTFS filesystem header for each partition on that disk. If there are more instances, that may indicate that a partition has been moved.

Quote:
Originally Posted by joeybuddy96 View Post

Are the beginning of the partition and the beginning of the file record two different things?
Absolutely. A NTFS formatted partition begins with the NTFS filesystem header (that's what I just mentioned above), whereas file records are stored inside of a file on the partition, namely, the ?:\$MFT file.

Quote:
Originally Posted by joeybuddy96 View Post

I can find where the MFT begins by using HxD to search for "FILE0" and then counting 243 bytes after the FILE0 flag.
I'm glad you can find it, but I need to mention that "FILE0" is the beginning of a file record. Each record's header is "FILE0". The offset of 243 bytes is the offset to the filename, the record itself begins 243 bytes earlier with "FILE0". These file records are the actual contents of the MFT. The problem is, the first file record you encounter may not be the first record in the MFT (also known as the beginning of the MFT).
Also, the old MFT may have been fragmented, and if the quick format overwrote the beginning of the old MFT, we would have interpret the MFT fragments to differentiate between the new, empty MFT and the old MFT that has your files! While I know how to identify MFT pieces, a gaping hole in my knowledge of the NTFS filesystem is how the file extent (fragment) information is stored. We would need this if we had to reconstruct the beginning of the old MFT (which would be needed if the new empty MFT was written on top of the old one).

Quote:
Originally Posted by joeybuddy96 View Post

Quote:
Originally Posted by Techie007 View Post

Succeeding that, you will probably need to write a new boot sector to both the 1st and 2nd partitions.
Earlier, you mentioned that overwriting the MFT would break the MFT and make it not bootable. I still have the contents from the smaller partition, and copy-pasted it from the backup drive to the first, smaller partition. How do I write the new boot sector without breaking anything?
Use the FixBoot and FixMBR commands in a Windows Recovery environment (I know XP, Vista and 7 all have one, and I'm sure 8 does as well). However, I wouldn't do this until we've fixed partition 2 and it is readable. And then, only if the BIOS is telling us "Please insert system disk and press any key" when we try to boot the system.

Quote:
Originally Posted by joeybuddy96 View Post

After running HxD, I searched for FILE0, and found it in Sector 16. I don't know how to go about counting exactly 243 bytes aside from doing it manually. The text bar next to the raw hex readout says near the middle of Sector 16 "$.M.F.T.". Other text of note says near end of Sector 0, "BOOTMGR is missing...BOOTMGR is compressed...Press Ctrl+Alt+Del to restart."
You can go to "Extras\Options" in HxD and change the file offsets to decimal, if that would be easier to read. Then you would select the data from "FILE0" and move the selection forward until the "Length" readout in the status bar showed a length of 242. In the options, you can also set the data grouping to 4, which is a D-Word (32 bits, a commonly used size in Windows).

Perhaps I should make a MFT scanner/parser; this would probably help us access the situation better, and it could be used to interpret MFT fragments that you see in HxD. To be honest though, I believe this will take more expertise then I have to fix manually. Perhaps you should look into "unformatting" utilities on the web.
 
#5 ·
    Thinking about it more, I think it would be a good idea to at least scan the partition with Recuva as I mentioned before.  Use the "deep scan" and "recover non-deleted files" options.  Don't recover anything, just scan.  I would like to see if it can find anything.  I believe it does a low-level scan for MFT fragments and B-tree structures when in deep scan mode.  If Recuva can find the original contents of the drive, that will signify a good chance of success for us (if we can figure out all the right things to do); but if it can't find anything, that may indicate that any manual attempts at filesystem repair would be a waste of time.
 
#6 ·
Quote:
There should be 1 instance of the NTFS filesystem header for each partition on that disk. If there are more instances, that may indicate that a partition has been moved.
I searched the small partition for EB52904E 54465320 20202000 and it found one instance. I then ran the search on the large drive which took over an hour, but found only one instance. This suggests that the partitions have not moved. The original size of the smaller partition was 100MB, and after the format there are two 1MB segments that are unallocated. I'm wondering if I should leave those as they are to avoid messing up the offsets, but I'm also wondering if the presence of those segments indicates that the offsets have been overwritten.
Quote:
You can go to "Extras\Options" in HxD and change the file offsets to decimal, if that would be easier to read. Then you would select the data from "FILE0" and move the selection forward until the "Length" readout in the status bar showed a length of 242. In the options, you can also set the data grouping to 4, which is a D-Word (32 bits, a commonly used size in Windows).
Using that technique, I'm able to locate where the first file record starts, which is immediately after the hex 46494C45 30 (FILE0), and continues until 243 characters later, when the file name starts (which is "$.M.F.T.").
Quote:
The problem is, the first file record you encounter may not be the first record in the MFT (also known as the beginning of the MFT).
So I need to find out what the first file record in the MFT is, and the one I found that appears first linearly in the drive is just some random file record, and might or might not be the first one. Moreover, every single MFT visible on the drive now are just for the post-format partition. The problem is that the original file extent information has been overwritten, and hasn't been backed up anywhere. This includes the contents of the original smaller partition, which only contained boot information. The only known solution is to find an un-formatter to get it back to normal. I started running a deep scan with Recuva, and as previous scans with Puran showed, the files are still present on the drive. The scan will take 24 hours to complete, but I'm going to let it run. I did not select the "Restore file structure" option because I don't know if it offers the kind of partition recovery I'm looking for, and might cause more damage.

I tried posting a duplicate of these posts on TestDrive's forums, but it either hasn't been approved by the admins or was denied a post. Their forum has several discussions of partition recovery, but it looks like the shortcut of asking how best to recover the partition from a Quick Format won't be happening today.

EDIT: The scan finished, so I just need to know what files to search for, and how to tell if they are the pre-format or post-format MFTs and B-tree records.
 
#7 ·
Quote:
Originally Posted by joeybuddy96 View Post

I searched the small partition for EB52904E 54465320 20202000 and it found one instance. I then ran the search on the large drive which took over an hour, but found only one instance. This suggests that the partitions have not moved. The original size of the smaller partition was 100MB, and after the format there are two 1MB segments that are unallocated. I'm wondering if I should leave those as they are to avoid messing up the offsets, but I'm also wondering if the presence of those segments indicates that the offsets have been overwritten.
Good. And both instances were right at the beginning of each partition and at the same offset on each partition (when looking at the drive at partition level).

Quote:
Originally Posted by joeybuddy96 View Post

Using that technique, I'm able to locate where the first file record starts, which is immediately after the hex 46494C45 30 (FILE0), and continues until 243 characters later, when the file name starts (which is "$.M.F.T.").
$MFT is the first record stored in the MFT. In that record, the MFT is describing itself (i.e. how large am I, where are my fragments, and so on). We need to find two of these on the 2nd partition, an old one, and a new one. If there's only one (i.e, the old one was overwritten), recovery will get much harder (and you'll need someone with more NTFS filesystem knowledge then I to create a new $MFT entry). The difficulty with hunting for them manually is that the Unicode string "$MFT" occurs many times on a disk, so you would have to ignore most of the search results, and only go with the ones that have "FILE0" 243 bytes earlier. If you're anxious to scan manually anyway, press [Ctrl]+[F] in HxD and type "$MFT" for the search term (without quotes and with no periods in between the letters). Make sure that "Unicode string" is ticked, and click [OK]. We need to find two instances of this on partition 2 (so you would be opening the disk at partition level for this search).

Quote:
Originally Posted by joeybuddy96 View Post

So I need to find out what the first file record in the MFT is, and the one I found that appears first linearly in the drive is just some random file record, and might or might not be the first one. Moreover, every single MFT visible on the drive now are just for the post-format partition. The problem is that the original file extent information has been overwritten, and hasn't been backed up anywhere. This includes the contents of the original smaller partition, which only contained boot information. The only known solution is to find an un-formatter to get it back to normal. I started running a deep scan with Recuva, and as previous scans with Puran showed, the files are still present on the drive. The scan will take 24 hours to complete, but I'm going to let it run. I did not select the "Restore file structure" option because I don't know if it offers the kind of partition recovery I'm looking for, and might cause more damage.

EDIT: The scan finished, so I just need to know what files to search for, and how to tell if they are the pre-format or post-format MFTs and B-tree records.
I did a quick search for un-formatters, and all the ones I found were like Recuva: "Yes, we will recover your files to a different disk, but not actually unformat the disk for you."
The "Restore file structure" option in Recuva doesn't affect anything when scanning; all it does is make Recuva (when you start actually recovering data) restore each selected file to its subfolder, instead of recovering them all in a flat hierarchy.
The B-tree records will come with the MFT, they are files just like any other file that you have stored on the partition (except that they are super-hidden so that Windows Explorer won't show them). So that concern is off of the table for now. If you could see the B-tree structures (and some of the other metadata files as well) in Explorer, it would look like this:

e6b19630_NTFSmetafilesonroot.png


Please give me a little time; I am going to write a MFT record scanner that will greatly help with recovery (I already wrote a disk defragmenter, so most of the MFT parsing code is already written). I expect it to take a day or two for me to write it.
 
#8 ·
Unfortunately, in all my experiments with quick formatting, Windows always overwrites the beginning of the old MFT with the new one. That means that there will be a dozen unrecoverable files where the old MFT data was overwritten (this could make the recovered disk fail to boot), and that we would have to recreate the overwritten entry for the original MFT (we could find the MFT fragments with a disk data scan). The problem is, I don't know how to write MFT file extent data. I've got some documentation and could probably learn how; but it's not exactly a priority for me right now.
What are your thoughts on this?
 
#9 ·
Quote:
What are your thoughts on this?
The goal is to get the drive into situation normal operating status. The methodology isn't as important. I won't pressure anyone to write free code for me, but I don't mind waiting for it either if it's something someone wants to do anyway. If there's an easier way than coding it without losing the keys that give me access to programs, that's fine. I'm thinking of several other plans. The simplest would be to buy a hard drive big enough to fit 500GB worth of content on, and then run Recuva to restore the file structure and contents to it.

Instead of reinventing the wheel, what about modifying TestDisk so it works as an MFT fragment search and accumulation program? Do you know of any site that does know how to write MFT data?
 
#10 ·
Well, I learned how to read MFT data extent information. That means that I should be able to write it as well...
Here is my NTFS utility program: NtfsRepair 1.0.6.zip. Unfortunately, the program triggers 5 out of 47 of the virus scanners at https://www.virustotal.com/en/. I promise that it is not malware; you are welcome to scan it yourself. The program will have to be run as Administrator to gain low level read access to the disk. Currently, the program is "read only" except for the [Write header] button in the NTFS header tools page (it gives a warning if you click it).
One of the things the program can do is scan for MFT fragments. Run a MFT scan on the partition that we're trying to recover (i.e don't run it on the physical drive). When it is done scanning, save the resulting list somewhere (not on the partition we're trying to recover!) and then click "Privatize filenames" and save the list again. Over the next few days, I hope to experiment with restoring an MFT on a virtual drive. If it is successful, I will proceed and let you know-and I will then need a copy of the "privatized" MFT scan in order to piece together the locations of the original MFT file.
 
#14 ·
I ran the executable, picked the smaller "System Reserved" partition, and clicked MFT Scan. I saved an unprivatized and privatized version of the list in a text file on a different drive. After saving the privatized version, an error box popped up saying "Error opening "blah blah file name", Overflow!" The privatized list file is blank. It does the same thing if I privatize the file names immediately after running the MFT scan and try to save it. It also did the same thing with the larger partition. I'm sending you a PM with an unprivatized version of the smaller "System Reserved" partition and the unprivatized version of the larger partition.

EDIT: I sent you a PM with a link to the latest scan along with the other two smaller sections of the first part of the scan requested earlier.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top