corrupted disk partition, Start of MFT rotated 16 bytes

[damocles]

ok. I have a seagate barracuda 7200.10 hard drive. This was partitioned into two NTFS partitions and some unallocated space. windows xp was installed onto one partition and was running contentedly. Then it wasnt. After due muttering and cursing I put the disk to one side and installed and formatted another with xp.

However, I would like to recover some stuff from the disk. Windows xp is happy to list the drive and show correct information about the partition sizes. Seagate disk tester says the hard disk is fine. windows says the file or data is corrupted

Trying to figure out what is wrong I have hoiked up a demo version of winhex. Recommendations on something useful and free to examine and edit the disk would be appreciated. Im not that good at editing disks freehand and have never worked on one formatted to ntfs. However, I have just about managed to explore the working disk on this computer and locate the MFT. Then had a look at the bad one. What I see is that the initial MFT entries are not aligned on sector borders but are 16 bytes further in.

On my working disk I get MFT start at offset C0 00 00 00 with the signature 45 39 4c 30 03. (ascii 'File0') I take it these are standard values.

On the duff disk I get the same data pattern at c0 00 00 10 the first 16 bytes where the MFT ought to appear are 14 00's and then 56 04

at offset c0 00 10 00 the correct pattern seems to reassert itself with a 'FILE0' signature at the start of a record where it ought to be. The spare copy of the start of the MFT seems to have exactly the same offset problem.

Anyone know whats going on? I dont understand how the data gets to be misaligned displaced from sector boundaries.

What does anyone reckon that if this block of 8 sectors is 'rotated' by 16 bytes so that the extra block of 00's and what appears to be a record ending signature of 56 04 is placed as the last 16 bytes instead of the first, then the partition will be fixed?

[stans4]

ok. I have a seagate barracuda 7200.10 hard drive. This was partitioned into two NTFS partitions and some unallocated space. windows xp was installed onto one partition and was running contentedly. Then it wasnt. After due muttering and cursing I put the disk to one side and installed and formatted another with xp.

However, I would like to recover some stuff from the disk. Windows xp is happy to list the drive and show correct information about the partition sizes. Seagate disk tester says the hard disk is fine. windows says the file or data is corrupted

Trying to figure out what is wrong I have hoiked up a demo version of winhex. Recommendations on something useful and free to examine and edit the disk would be appreciated. Im not that good at editing disks freehand and have never worked on one formatted to ntfs. However, I have just about managed to explore the working disk on this computer and locate the MFT. Then had a look at the bad one. What I see is that the initial MFT entries are not aligned on sector borders but are 16 bytes further in.

On my working disk I get MFT start at offset C0 00 00 00 with the signature 45 39 4c 30 03. (ascii 'File0') I take it these are standard values.

On the duff disk I get the same data pattern at c0 00 00 10 the first 16 bytes where the MFT ought to appear are 14 00's and then 56 04

at offset c0 00 10 00 the correct pattern seems to reassert itself with a 'FILE0' signature at the start of a record where it ought to be. The spare copy of the start of the MFT seems to have exactly the same offset problem.

Anyone know whats going on? I dont understand how the data gets to be misaligned displaced from sector boundaries.

What does anyone reckon that if this block of 8 sectors is 'rotated' by 16 bytes so that the extra block of 00's and what appears to be a record ending signature of 56 04 is placed as the last 16 bytes instead of the first, then the partition will be fixed?

I've never used winhex and don't know its capabilities. As I stated in another post, my tool of choice is DFSee, www.dfsee.com. Free full-featured, but time-limited, demo. If you select the partition of interest and set it to NTFS file type, there are a number of diagnostics you can run. DFSee squawks all the time about non-aligned partitions, the later file systems have gotten away from cylinder/head/sector concepts(being a fiction these days, anyway) and use absolute sector numbers for finding things. Things don't HAVE to be aligned. So your current structure is probably fine, being NTFS.

If all you want is to recover what files you can, it'll make a list of what it finds from the MFT structures, you can select any or all files to copy to a work drive after that. There's a menu pick for recovering files, deleted or not. With a large drive, this can take a number of hours or days. Like 3 days with a 640G notebook drive. You will need a work drive of the same size or larger than the dud one to do that.

My first action would be to look at the partition table structure and see what the media type is. I've had Windows randomly change media types and then it won't boot anymore. Putting it back the way it was fixes things. I don't know why it does it, but I've had 98SE, NT, 2000 and XP all do it. Usually, but not always, it hits a USB mass storage device. It's messed up boot drives that way before.

Another thing I've done is to get another drive of the same make and model, partition it exactly the same as the dud, then use DFSee to save the partition tables off to the work drive. Make a copy of the dud, use DFSee to insert the partition structure from the file, reboot Windows to see the revised drive, do a chkdsk to check it out and see what can be seen. That usually works unless there's a hardware problem or things have been zeroed out.

The "magic matchbox" is a great tool for this type of thing, being a USB->IDE/SATA adapter. One I use can be seen here: http://kingwin.com/products/cate/accessories/adapters/usi_2535.asp, runs about $10. There are other makes. Or you can use eSATA or an empty drive position in your machine. I prefer not to have to tear the machine apart just to change drives for diagnostics all the time, YMMV.

Stan

[damocles]

I dont know how windows would react to finding a chain of 00's where it expects the MFT to start? would it simply ignore everything until it reached a 'file' identifier, or generate an immediate error? I would think there must be the correct identifier at the start of the MFT. I also dont know what the significance of the trailing 56 04 at the end of a record is. I note there is a different end signature for most of the MFt entries, but it occurs in all the odd block, which is why i think it has somehow rolled. In any event, even if the start of the last misaligned entry is recognised, the end of it is truncated and it runs into the start of the next.

[jaclaz]

I dont know how windows would react to finding a chain of 00's where it expects the MFT to start? would it simply ignore everything until it reached a 'file' identifier, or generate an immediate error? I would think there must be the correct identifier at the start of the MFT. I also dont know what the significance of the trailing 56 04 at the end of a record is. I note there is a different end signature for most of the MFt entries, but it occurs in all the odd block, which is why i think it has somehow rolled. In any event, even if the start of the last misaligned entry is recognised, the end of it is truncated and it runs into the start of the next.

Before using a disk/hex editor I would rather try more suitable programs.

Forget for a moment what you found and the 16 byte shift.

Things are usually much more complex than what you are assuming.

Can you simply get the MBR and bootsector with dsfo or hdhacker of the problematic partition and post them?

Check these two threads, to get an idea of the kind of data you should provide and of the tools that you will need to use, and how to use them:

http://www.msfn.org/board/index.php?showtopic=141687

http://www.msfn.org/board/index.php?showtopic=145574

Is the "other" partition allright?

Have you tried simply running CHLDSK on the partition with NO parameter BUT the drive letter?

Or the partition fails to get assigned a drive letter?

jaclaz

[damocles]

never done this before, so lets see what happens, i have attached a copy of the boot sector of the faulty ntfs partition. This partition is assigned a drive letter by windows but any attempt to access it generates an error. Chkdsk says 'The type of the file system is NTFS. Unable to determine volume version and state. Chkdsk aborted.'

The other partition has a letter and lists its files. I dont recall now whether I put something on it before the other failed or it was always blank. It was indended just for data.I dont remember whether at the time the boot partition failed I had even formatted the other. I may have done it afterwards to see if it would. Mostly I just put the whole disk aside until i had time to investigate it.

Not being absolutely certain what winhex is doing, I have also attached what I think is the MBR.

[damocles]

And for good measure an image of the start of the MFT on the duff partition

[jaclaz]

never done this before, so lets see what happens, i have attached a copy of the boot sector of the faulty ntfs partition.

Well, no.

You attached a screenshot of something. (but it's OK, you got the "right" sectors )

I would like to have the actual files.

Check the given threads, the use of Hdhacker is illustrated, but you can use Winhex allright, just select the sector (all 512 bytes of it) for the MBR and for the PBR and copy/paste them to two new files, then Zip the two files into an archive and post the compressed archive.

The only thing I can say without having the actual files and without manually copying the binary values I can say is that the NTFS partition was created under Vista or 7 (as the PBR invokes BOOTMGR).

jaclaz

[damocles]

it is quite possible the disk was on a computer running vista first. Ive rather given up on vista and prefer to go back to xp, but that would have been a different computer. Does this interesting chequered history make a difference? I had a look at hdhacker last night. it put up onscreen a boot sector image, but i noticed that when i typed in the cluster number of the MFT, it crashed. i think the number was too big. Fraid i cant find you a file dump until later as I am elsewhere. Do I take it you have some kind of program which will analyse the boot sectors?

Incidentally, i cant be absolutely certain, but offhand I dont think I ever 'just zipped' anything in my life. This is all very exciting!

Edited November 4, 2010 by damocles

[jaclaz]

it is quite possible the disk was on a computer running vista first. Ive rather given up on vista and prefer to go back to xp, but that would have been a different computer. Does this interesting chequered history make a difference?

The disk having been formatted by Vista originally may cause a misalignment (of whole sectors and not of the 16 bytes) that can lead to problems if used under XP.

I had a look at hdhacker last night. it put up onscreen a boot sector image, but i noticed that when i typed in the cluster number of the MFT, it crashed. i think the number was too big.

The initial part was "FORGET (temporarily) the MFT"!

Hdhacker is straightforward.

You want to select first sector of the PhysicalDrive (\\.\PhysicalDrive0 is first disk, \\.\PhysicalDrive1 second, etc.) and press "Read sector from disk", then press "Save sector to File" and save it - this is the MBR.

Repeat with first sector of the Logicaldrive - this is the PBR or bootsector.

Incidentally, i cant be absolutely certain, but offhand I dont think I ever 'just zipped' anything in my life.

Then get ANY compression utility compatible with the ZIP format and use it, 7-zip is advised, but virtually anything can do.

http://en.wikipedia.org/wiki/7-Zip

http://www.its.ipfw.edu/training/howto/7_Zip_EncryptionProcess.pdf

The compression is needed for two reasons (in this case NOT to save a few bytes, it is likely that the resulting archive will be bigger than original data):

1. .zip is an extension that is allowed for attachment on the board
   
2. if there is any corruption in the upload or download, the archive won't verify
   

Do I take it you have some kind of program which will analyse the boot sectors?

Yep but it's not a secret:

http://www.boot-land.net/forums/index.php?showtopic=8734

(had you actually READ the threads I pointed you to, you would ALREADY know that)

This is all very exciting!

I guess I am allowed to express some perplexities on your tastes when it comes to excitement?

What about this, then:

http://web.archive.org/web/20080331030514/http://www.somethingawful.com/fakesa/fetish/

jaclaz

[damocles]

finally got home, so perhaps here is what you were asking for. I did read the links yesterday but found them very long winded as explanations of where to find the specific programs..Im more accustomed to eyeballing the hex to figure out whats wrong with it then feeding it into a program but I shall try to investigate that too. But as I think I said I havnt indulged for years. I naturally assumed you would just be looking at it too.

afraid i dont forget the rolled cluster, which seems quite curious.

damocles boot sectors.zip

[jaclaz]

finally got home, so perhaps here is what you were asking for. I did read the links yesterday but found them very long winded as explanations of where to find the specific programs..Im more accustomed to eyeballing the hex to figure out whats wrong with it then feeding it into a program but I shall try to investigate that too. But as I think I said I havnt indulged for years. I naturally assumed you would just be looking at it too.

afraid i dont forget the rolled cluster, which seems quite curious.

Yep, but you really should read the second thread, which is about a situation VERY similar to yours, and does contains some info that may be of use to you.

The actual $MFT, according to your PBR/bootscetor is on cluster 786432 (normal for a NTFS volume).

You have 8 sectors clusters (again normal)

From BOTH your MBR and PBR the partition starts at LBA 2048.

786432x8+2048=6293504 <- This is where your $MFT should actually begin.

Can you check it?

jaclaz

[damocles]

was just faling asleep, which is not a good time to do hex arithmetic. However have woken up a bit. Using winhex I get a hex listing of the partition content which it gives addresses simply described as 'offset', counting upwards from 0. At 0 I see the ntfs boot record, which seems correct.

At offset 0C000000 which is equivalent to the start of cluster 786432 or sector 6291456, I get the skewed record which I posted earlier, which you have probably already looked at.

At sector 6293504 I get a string of file records, which is not surprising because if my assumption is correct, this would be somewhere within the MFT. winhex also has a record translator which presents MFT entries in a legible form. This claims that the record at sector 629504 is a file called A0003348.dll. i have no idea what that might be, but the entry seems reasonably valid. At sector 6291464 i find file $attdef, at ...466 i find '.', at ...468 i get $bitmap...470 i get $boot. The program will not translate the sectors at ...456 ...458...460...462 because although they look like file records, they are all skewed. However, this is all consistent with a MFT starting at sector 6291456.

Re what you said about an offset from the boot record, I would expect a different offset from the MBR and from the partion boot record to the actual MFT. the MBR sits in its own reserved space in front of the first partition, which is the one we are examining. The size of this might be 2048 sectors, i dont know.

hope I got all that straight. Im not that awake!

Still dont know how come I have 4 rotated records.

Edited November 4, 2010 by damocles

[jaclaz]

hope I got all that straight. Im not that awake!

It depends on HOW you access the disk.

If you access the \\.\PhysicalDrive:

1. the MBR is at LBA 0 (first sector)
   
2. the PBR is at LBA 2048
   
3. the MFT should be at 786432x8+2048=6293504
   

If you access the LogicalDrive or Volume:

1. the MBR is NOT available
   
2. the PBR or bootsector is at LBA 0 (first sector)
   
3. the MFT should be at 786432x8=6291456
   

It's years I don't use WinHex, and I am not familiar with it, but if it uses absolute byte addressing:

0C000000=201326592

201326592/512=393216

So it is NOT:

At offset 0C000000 which is equivalent to the start of cluster 786432 or sector 6291456, I get the skewed record which I posted earlier, which you have probably already looked at.

Now, be nice.

Get Tinyhexer.

Open the \\.\PhysicalDrive:

File->Disk->Open Drive

You will get to sector 0 or MBR.

Now:

File->Disk->Goto Sector/Position

6293504

Select the sector.

Edit->Copy.

Edit->Paste to new

Save the file, zip it and attach it to your next post.

Do the same for sector 63999999x8+2048=512002040 (which according to the PBR is your $MFTmirr)

If you access the Logicaldrive you DO NOT have the 2048 sectors before, thus addresses are:

786432x8=6291456

and

63999999x8=511999992

jaclaz

[damocles]

well here you are. Didnt think about what it meant, just followed the steps you describe, The results are exactly the same. Skewed records.

Perhaps I should make clear that with winhex when examining the MBR I used a window opened on the physical drive, and when examining the partitions was using a screen opened on that partition. The program is automatically using addressing relative to the partition start. I think this is exactly how it is designed to be read with regard to the information in the partition boot sector. The screen in front of me right now states offset 00c0000000 logical sector number 6291456, physical sector number 6293504, cluster number 786432. (the skewed MFT)

These seem to be logical rather than physical clusters. (though I suppose, what other sort could they be, since the cluster size might vary on different partittions?) if I scroll the window to offset 0, it then reads logical sector 0, physical sector 2048, cluster 0 and shows me the partition boot sector.

physical drive 1 sector 512002040 and 62935041.zip

[jaclaz]

These seem to be logical rather than physical clusters. (though I suppose, what other sort could they be, since the cluster size might vary on different partittions?) if I scroll the window to offset 0, it then reads logical sector 0, physical sector 2048, cluster 0 and shows me the partition boot sector.

Yep, that's correct.

Physical drives ALWAYS start at offset 0 as they are the "outer" container.

Logical drives starts werever the data in the MBR (part of the PhysicalDrive) say so, in your case you are accessing first logical drive, which has 2048 sectors (hidden) before it.

There is no such thing as "physical" vs. "logical" clusters (they are ONLY "logical" ), a cluster is simply a "group of sectors" and it's size (or better the number of sectors each of them contains) is defined in the bootsector or PBR and depends on:

1. SIZE of the logical drive
   
2. FILESYSTEM used in it
   

Now, back to work.

Besides the 16 bytes shift, the $MFT and the $MFT Mirror appear like identical.

Can you repeat what you did, but saving this time 5 sectors starting at the same addresses?

I just want to make sure that the rest of the $MFTmirr is still the same.

I have no idea HOW this shift may have happened, it seems like 16 bytes have been inserted "somewhere" (evidently before the $MFT), since the $MFTmirr is also shifted 16 bytes.

You should check also the bootsector copy (last sector of partition, i.e. absolute sector 1023999999 + 2048= 1024002047 or 2048+1024000000-1=1024002047 and a few sectors after it, the same 5 will do.

I mean, if the second partition works allright, and it starts at 1024015230, the "exceeding" 16 bytes of the bootsector copy should get as first 16 bytes of the first "unused" space between first and second partition, i.e. you should have first line of sector 1024002048 ending with the "Magic Bytes" 55AA.

Once made sure of this, we need to find WHERE the 16 bytes have been inserted, and this may prove tougher than it might seem.

If you are lucky, the bytes have been inserted *somehow* in the NTFS "complete" bootsector (first 16 sectors of the logical volume).

Save as before those 16 sectors +1, 17 in total and post them, together with the three sets of 5 bootsectors detailed previously.

jaclaz

Edited November 5, 2010 by jaclaz