Jump to content

Seagate 750Gb one partition is RAW after BSY fix


Recommended Posts


You mean like photorec? Where all files are just dumped into folders while losing the file name?

Yep, but there also several apps that may be able to get the filename.

But we need a $MFT, for this. :(

http://memberwebs.com/stef/software/scrounge/

http://memberwebs.com/stef/software/scrounge/guessing.html

The sector you found is definitely part of the $MFT or of it's mirror.

However it's position makes no sense to me, right now.

Was the disk originally "Vista" or "Windows 7"?

Maybe the $MFT position has been shifted on these systems? And somehow the position was reverted in the bootsector to the default XP ones?

Try going on searching and take note of which sectors have this leading "FILE0" tag, maybe we can find a pattern. :unsure:

jaclaz

Link to comment
Share on other sites

Was the disk originally "Vista" or "Windows 7"?

Maybe the $MFT position has been shifted on these systems? And somehow the position was reverted in the bootsector to the default XP ones?

The disk was Vista 64, but I'm nit sure if it was XP before that.

Try going on searching and take note of which sectors have this leading "FILE0" tag, maybe we can find a pattern. :unsure:

I will search starting that that sector.

Link to comment
Share on other sites

They're everywhere...

1083587

1083589

1083591

1083593

1083595

1083597

1083599

1083601

1083603

1083605

1083607

1083609

1083611

1083613

1083615

Then starting at sector 10833634 they show up somewhere in the middle of sectors (always somewhere different) not at the beginning...and not every other sector. Sometimes the next sector or sometimes 3-4 away.

Then they start having multiple FILE0's in the sectors.

If you need all the sector number I can do that...there's probably like 50 more. It's just scanning now and has not found anything in a while.

Edited by SkylineRB26DETT
Link to comment
Share on other sites

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/ntfs-system-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) :unsure:

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

Link to comment
Share on other sites

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? :unsure:

jaclaz

Link to comment
Share on other sites

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

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?

Edited by SkylineRB26DETT
Link to comment
Share on other sites

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.

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. :unsure:

jaclaz

Link to comment
Share on other sites

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.

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. :unsure:

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?

Link to comment
Share on other sites

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:

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

As you can see quite a lot of assumptions :ph34r:.

jaclaz

Link to comment
Share on other sites

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:

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

As you can see quite a lot of assumptions :ph34r:.

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.

sectors.zip

Link to comment
Share on other sites

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 :ph34r: 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 :ph34r: 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/forums//index.php?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/board/index.php?showtopic=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 :unsure:

This would make sense IF you did not (high probability :whistle: ) 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

Edited by jaclaz
Link to comment
Share on other sites

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

BINGO!!!! :thumbup

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?

6291521.zip

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...