[jaclaz]

It's very strange.
The sectors you posted do contain some references to $Quota, $ObjId, $Reparse (i.e. typical objects of a $MFT):
http://www.ntfs.com/...ystem-files.htm

Now, with reference to your posted file:
$Quota is on sector #16 which translates to Record #8 (should be Record #24)
$ObjId is on sector #18 which translates to Record #9 (should be Record #25)
$Reparse is on sector #20 which translates to Record #10 (should be Record #26)

Which should mean that the actual $MFT beginning is 24-8=16*2=32 sectors before the chunk of sectors you posted, i.e.
1081543-32= 1081511 (which still makes very little sense)

To be on the safe side, try saving 200 sectors (100 sectors before first found occurrence and 100 sectors after it).

I.e.:
Sectors 1081443~1081643
Sectors 1083487~1083687
etc.

jaclaz

[SkylineRB26DETT]

jaclaz, on 31 July 2010 - 01:07 PM, said:

Sectors 1081443~1081643
Sectors 1083487~1083687

Attached are the sectors...two files with 200 sectors each.

Also...more FILE0 sightings...



Sectors
6185824(pictured)
6185837
6191570
6193371
6193386

maybe more...it's scanning

Attached File(s)

•  sectors.zip (26.72K)
  Number of downloads: 2

[jaclaz]

Sectors 1081443~1081643 seem like being NOT the real thing/not usable.
Sectors 1083487~1083687 seem better, at offset 50176 (sector 98/200 of "1083585" file) there is a "full" $MFT.
Only it seems like having been created on 15/02/2005, would it be possible?

jaclaz

[SkylineRB26DETT]

jaclaz, on 01 August 2010 - 12:56 PM, said:

Only it seems like having been created on 15/02/2005, would it be possible?

So it would mean that all files created after that date will not show up?

Are the other sectors irrelevant? There got to be about 100 sectors with FILE0 in them.

How do we proceed?

This post has been edited by SkylineRB26DETT: 01 August 2010 - 06:41 PM

[jaclaz]

SkylineRB26DETT, on 01 August 2010 - 06:26 PM, said:

So it would mean that all files created after that date will not show up?

No, it simply means that the found $MFT was created on that date, which translates - IF that is the "right" $MFT - to the fact that the volume was formattted on that day (which I am presuming to be unlikely).
Knowing the "history" of that system/drive may give hints to understand if this is likely or not.

SkylineRB26DETT, on 01 August 2010 - 06:26 PM, said:

Are the other sectors irrelevant? There got to be about 100 sectors with FILE0 in them.

How do we proceed?

Continue gathering them, it is possible that the one till now found is part of something else, and that we find later the "real" one.

jaclaz

[SkylineRB26DETT]

jaclaz, on 02 August 2010 - 02:09 AM, said:

Knowing the "history" of that system/drive may give hints to understand if this is likely or not.

The date code on the drive is 09122 so a date of 15/02/2005 is not possible.

jaclaz, on 02 August 2010 - 02:09 AM, said:

Continue gathering them, it is possible that the one till now found is part of something else, and that we find later the "real" one.

Should I post screenshots of the individual sectors with FILE0 or post zip of 200 sectors? There are probably 50-100 more sectors with FILE0 (not all next to each other). Can I disregard most of those sectors? Should I be looking for other syntax with FILE0?

[jaclaz]

The screenshots are of no practical use, the .zip files may .

Actually a $MFT first sector has the "$.M.F.T." (Unicode) string at offset 0xF2, but if for any reason that string has been overwritten, you won't obviously find it, the "FILE0" is a more generic string that occurs on each sector of the $MFT and thus allows to find also "fragments" of a $MFT.

The real problems is that I still have not any idea about the WHY/HOW this mix-up occurred, quite frankly, we are "grasping at straws", hoping that somehow:

• the $MFT was originally in a "non-standard" position,
  
• that it is still there
  
• that TESTDISK somehow used (wrongly) in the bootsector the "standard" address

As you can see quite a lot of assumptions .

jaclaz

[SkylineRB26DETT]

jaclaz, on 02 August 2010 - 09:29 AM, said:

The screenshots are of no practical use, the .zip files may .

Actually a $MFT first sector has the "$.M.F.T." (Unicode) string at offset 0xF2, but if for any reason that string has been overwritten, you won't obviously find it, the "FILE0" is a more generic string that occurs on each sector of the $MFT and thus allows to find also "fragments" of a $MFT.

The real problems is that I still have not any idea about the WHY/HOW this mix-up occurred, quite frankly, we are "grasping at straws", hoping that somehow:

• the $MFT was originally in a "non-standard" position,
  
• that it is still there
  
• that TESTDISK somehow used (wrongly) in the bootsector the "standard" address

As you can see quite a lot of assumptions .

jaclaz

Once again I appreciate your help!!

Attached is a zip folder which contains 7 files. The name of the files are the actual sectors which contain FILE0. Two files have many sectors with FILE0 in them...those file names contain "and a lot" in the file name.

There are more sectors I keep finding.

Attached File(s)

•  sectors.zip (92.57K)
  Number of downloads: 3

[jaclaz]

SkylineRB26DETT, on 02 August 2010 - 11:40 AM, said:

There are more sectors I keep finding.

Yep , keep 'em coming, the ones you just posted seem completely unlike "them".

There is a possibility that has just come to my mind.

If the drive was originally partitioned by Vista or Windows 7, it might have had a "wrong" (from the old "standard" view-point) sector alignment.

I.e. it could have been aligned to the "cluster size" instead of on cylinder border.
Just a guess, but if the recovery partition was made with an older OS, it would have had the "normal" 0/1/1 start and n/254/63 end (in this case 1023/254/63 .i.e. "a suffusion of yellow" since recovery partition is bigger than the CHS limit), and your recovery partition does have this values.

Then comes into play a "standard" Vista or 7 that aligns partitions differently.
A "normal" first partition starts at 0/1/1 and ends at n/254/63.

The same if created on an unpatched NT 6/7 will start on different address, aligned with 128 sectors before:
http://www.911cd.net...showtopic=21186
most probably 0/2/3 but normally end on border, like m/254/63, see here for an example:
http://www.msfn.org/...ic=119963&st=17

Cannot say if non-first partitions would be as well aligned like that, but if they are, then it is possible that the "actual partition" starts not at 20482875 LBA, but rather at 20482875-63+128=20482940.

Then TESTDISK "thought" that partitions were bounded to cylinder borders and when you told it to create the bootsector, it re-created the bootsector in the "wrong" place, also adjusting the partitioning data.

If this is the case, the $MFT should be at sector 6291456-63+128=6291521

This would make sense IF you did not (high probability ) go into "Options" and changed "Cylinder Boundary" from the default "Yes" to "No" and the "Allow partial last cylinder" from the default "No" into "Yes".

I do know that the above seems complex and confusing (actually it is complex and confusing ).

jaclaz

This post has been edited by jaclaz: 03 August 2010 - 03:11 AM

[SkylineRB26DETT]

jaclaz, on 02 August 2010 - 12:49 PM, said:

If this is the case, the $MFT should be at sector 6291456-63+128=6291521

BINGO!!!!

I started searching for FILE0 again starting at the last sectors I posted and before I found 300+ sectors with FILE0. I was writing them all down and I ran out of room on the paper. I still had 40000 sectors to go till 6291521.

So I decided to skip to sector 6291521 just to check it and you are right...that's where the $MFT is.

I attached a file with 1000 sectors (100 before 6291521 and 900 after )because there were many FILE0's.

Should I still be checking?

Attached File(s)

•  6291521.zip (44.53K)
  Number of downloads: 2

[jaclaz]

SkylineRB26DETT, on 02 August 2010 - 04:24 PM, said:

BINGO!!!!

Good.

SkylineRB26DETT, on 02 August 2010 - 04:24 PM, said:

Should I still be checking?

NO, it seems like we've found the actual thing.
Date is 11/10/2008.

Now we have to find out how to fix the thingy.

If everything is like I presume, the actual original bootsector is at LBA 20482940, to check, post first 200 sectors of the partition.
From the original bootsector we should be able to understand if not only the start position but also the end position was changed.
The other check is to (opening the \\.\PhysicalDrive and NOT the partition) to go near the end of the partition, say sector 1,465,140,000 and from it start searching for the backup bootsector, in search use hex string EB52904E54465320.
I need the sector number where you find it.

With the new (please read old ) verified addresses it should be just a matter of changing a couple of numbers in the MBR.

jaclaz

This post has been edited by jaclaz: 03 August 2010 - 03:29 AM

[SkylineRB26DETT]

jaclaz, on 03 August 2010 - 03:29 AM, said:

If everything is like I presume, the actual original bootsector is at LBA 20482940, to check, post first 200 sectors of the partition.
From the original bootsector we should be able to understand if not only the start position but also the end position was changed.

Attached.

jaclaz, on 03 August 2010 - 03:29 AM, said:

The other check is to (opening the \\.\PhysicalDrive and NOT the partition) to go near the end of the partition, say sector 1,465,140,000 and from it start searching for the backup bootsector, in search use hex string EB52904E54465320.
I need the sector number where you find it.

String EB52904E54465320 shows up in sectors 1,465,144,064 and 1,465,145,343.

Attached File(s)

•  first 200 of partition2.zip (2.87K)
  Number of downloads: 2

[jaclaz]

SkylineRB26DETT, on 03 August 2010 - 05:02 AM, said:

Attached.

No joy.
Try searching the same EB52904E54465320 starting form first sectors of partition.
It is very possible that the "shift" is bigger than expected.
If you find it, post that sector (and it's position).

SkylineRB26DETT, on 03 August 2010 - 05:02 AM, said:

String EB52904E54465320 shows up in sectors 1,465,144,064 and 1,465,145,343.

Good
The one on 1,465,144,064 should be the "current" one (backup bootsector of "current" partition).
The one on 1,465,145,343 might be the "original" one (backup bootsector of "original" partition), which should mean that (if the actual partition size is exactly the same) that the shift is of 1,465,145,343-1,465,144,064=279 sectors and not of the 128-63=65 sectors I guessed.
Post these two sectors.

jaclaz

[SkylineRB26DETT]

jaclaz, on 03 August 2010 - 05:33 AM, said:

No joy.
Try searching the same EB52904E54465320 starting form first sectors of partition.
It is very possible that the "shift" is bigger than expected.
If you find it, post that sector (and it's position).

What I did before was open the first 200 sectors of partition 2 and not the physical drive. The partition does begin with EB52904E54465320.

When I open the physical drive to sector 20482940...the 200 sectors are all empty.

Ok so when I open partition 2 the first string is EB52904E54465320 then I search and find it again on sector 1221, which is attached.

jaclaz, on 03 August 2010 - 05:33 AM, said:

The one on 1,465,144,064 should be the "current" one (backup bootsector of "current" partition).
The one on 1,465,145,343 might be the "original" one (backup bootsector of "original" partition), which should mean that (if the actual partition size is exactly the same) that the shift is of 1,465,145,343-1,465,144,064=279 sectors and not of the 128-63=65 sectors I guessed.
Post these two sectors.

1,465,145,343-1,465,144,064=1,279

Sectors attached.

Attached File(s)

•  1465144064 and 1465145343.zip (1.11K)
  Number of downloads: 2
•  1221.zip (571bytes)
  Number of downloads: 2

This post has been edited by SkylineRB26DETT: 03 August 2010 - 05:52 AM

[jaclaz]

SkylineRB26DETT, on 03 August 2010 - 05:51 AM, said:

1,465,145,343-1,465,144,064=1,279

Yep slip of the fingers.

The good news are that "1221" and "1,465,145,343" do match
(as well as "0" and "1,465,144,064")

In the bootsectors:
"Sectors before" are 20,484,096
"Total Sectors" are 1,444,661,247 (+1 outside the actual filesystem: the backup bootsector)

20,484,096+1,444,661,247=1,465,145,343



Now all that it should be needed is to use a partition editor, like PTEDIT32 or beeblebrox, or maybe this one (just found):
http://www.dtidata.c...tion_repair.htm

and change the values:
07-80-1023-254-63-1024-254-63-20482875-1444661190
to
07-80-1023-254-63-1024-254-63-20484096-1444661248

Please note that the current first sectors of the "current broken" partition will remain untouched but will be in a "no-man's-land" between first and second partition, and that the sector 1,465,144,064 will remain - unindexed - inside the partition.

Maybe, once hopefully everything has gone back to normality, it would be a good idea to fill them with 00's, just to avoid confusion should there be any future occasions of attempting recovery.

Obviously, crossing fingers, holding a rabbit foot and the like when editing the MBR is advised...

jaclaz

[SkylineRB26DETT]

jaclaz, on 03 August 2010 - 06:49 AM, said:

and change the values:
07-80-1023-254-63-1024-254-63-20482875-1444661190
to
07-80-1023-254-63-1024-254-63-20484096-1444661248

This is what it comes up as...


Does it seem correct? Main difference is that it shows 1023 instead of 1024 like you posted.

If everything seems alright then I'm about to change...

20482875 to 20484096
-and-
1444661190 to 1444661248

Holding a rabbit's foot btw.

[SkylineRB26DETT]

It works it woks!!! You are the man with the master plan!!!

So now...fill everything from 20482875-20484095 and 1465144064 with zero's?

[jaclaz]

SkylineRB26DETT, on 03 August 2010 - 07:09 AM, said:

Does it seem correct? Main difference is that it shows 1023 instead of 1024 like you posted.

If everything seems alright then I'm about to change...

20482875 to 20484096
-and-
1444661190 to 1444661248

Holding a rabbit's foot btw.

Yep, another slip of the finger , 1023 is of course right, the only things to be changed are the red numbers with the bolded italics ones.

You may need to re-boot to see the effect.

Anyway re-check the MBR with Tiny Hexer and PTview (just in case).

jaclaz

This post has been edited by jaclaz: 03 August 2010 - 08:04 AM

[jaclaz]

SkylineRB26DETT, on 03 August 2010 - 07:57 AM, said:

It works it woks!!! You are the man with the master plan!!!

Good , another happy bunny in the basket :
http://www.msfn.org/...ic=128727&st=10

SkylineRB26DETT, on 03 August 2010 - 07:57 AM, said:

So now...fill everything from 20482875-20484095 and 1465144064 with zero's?

Yep, that's the idea.

It's optional, but it won't do any harm.

jaclaz