对 MFT偏移 的修正 ---亲历一次数据修复.doc

对 MFT偏移 的修正 -亲历一次数据修复前阵子，我在一次正常开机后，打开QQ空间，突然系统死机。点击鼠标无反应，按键ctrl+alt+del想杀进程确无反应，于是只好按主机reset键强制重启，结果RP爆发，百年一遇 重启后，无法进XP系统，用PE光盘进，发现C盘和E盘都提示“文件或目录损坏且无法读取”，于是用ptdd重建mbr，仍进不了系统。重启又进入PE，发现此250G的5个分区的硬盘中，E盘反而可以正常读取了，其他分区出现上面那个提示。用PTDD重建分区表，没解决。 后来在网上搜过“文件或目录损坏且无法读取”的解决方法，最多提到的是chkdsk /f, 但是在PE里，提示无法识别ntfs。于是只好把硬盘挂载到室友的电脑里，用chkdsk /f修复，修复后我在Xp双击这些分区，原来的C盘，F盘G盘依旧无法进入，还是那个错误提示。而D盘可以了。后来挂载到我电脑另一个硬盘的linux里，竟然能进F和G盘，里面有FOUND.000这类文件夹，在里面找到了不少修复回来的文件，随机在不同目录点了几个都能用。 于是接下来要解决的问题有： 1.同样全部是ntfs系统，为什么XP无法读取F和G分区，而linux可以？（虽然不可以在windows里读取，但至少在linux下可以把数据导出备份，成功了一点点） 2.如果从数据修复的角度看，现在只剩下C分区了。头疼 PTDD，DISKGEN，还有用过一些磁盘错误扫描，都检查不出什么错误。（这里明显我是病急乱投医） 本着不修复好不罢休的精神吧，虽然C分区的数据真的没有了也不至于损失多惨重，可恰好我可以在另一个硬盘linux里的虚拟机里的XP上网，所以也不需要急用电脑而不得不重装系统。（双系统的好处之一 o(_)o ）之后是上网找专业论坛，搜索期刊。顺便做下广告，我觉得中国硬盘基地技术论坛不错。我也是第一次从这里知道可以用winhex修复数据。并且也通过搜索得知我的故障可能是MFT有错。在里面看过一句话，“你要是不会手动16进制写mft，不知道他的规则，计算方式。就别费劲了，你从现在学，学3个月有可能能学会”。天啊，估计我没这耐性，更主要是我还有不少事情做不过我试着去了解吧，趁机能懂点东西也不错。于是，从一开始不懂mft，然后慢慢的去了解ntfs的文件系统其实一共也不需花多少时间，中间快20天都忙着考试和找工。这里还有个小插曲，因为看过这方面的书，那时候印象较深，还去笔试面试了一个数据修复公司，吹吹自己会用winhex和其他修复软件，通过了。说1月中旬给个回复去不去，去的话开始实习了，不过待遇感觉太低所以不想了的。毕竟生活压力吧，还有综合考虑兴趣与待遇，还有发展。 说点硬盘ntfs文件系统的，或许很多人也听过了。之前我没怎么了解，后来借此机会也趁机学学了。硬盘由引导扇区（Boot Sector）与各分区组成。不超过四个主分区，原因是主引导记录（MBR）里的分区表里只有64字节，一共只可描述4个分区表项，从winhex里看，描述一个分区表项用16字节。有人可以分七八个分区是因为用到扩展分区，现在我们的普遍分法是一个主分区+一个扩展分区，然后扩展分区又是由相应的EBR（即扩展MBR）里的分区表来描述。一个以盘为主分区，为扩展分区的硬盘数据结构如下所示：关于主引导记录MBR。一般都占用63个扇区，即从第0-62扇区（这里有个例外，虚拟机里我看过只有56个扇区），而实际有写入内容的一般只有一个扇区，及常说的0柱面0磁道1扇区。1个扇区512字节，MBR其实分三部分，1.引导代码446节 2.分区表64字节 3.结束标记55AA，及2个字节。 如果，两蓝色竖线把第一个扇区划分为三部分，及上述的MBR三部分。两蓝竖线间为分区表。每16字节为一个分区表项，两个紧挨着的数字为一个字节。第一个分区中：第一个红色框内80代表活动分区。绿色框01 01 00代表磁头号、扇区号、柱面号。第一个蓝色框07代表NTFS分区。紧接着三条绿横线，分别是本分区结束磁头号、扇区号、柱面号，然后是本分区之前已用的扇区数（3F000000，必须倒过来，即0000003F，转为10进制63，即MBR要占用63扇区，注意MBR是不属于磁盘第一个分区!），最后是本分区的总扇区数（E5588101,倒过来，018158E5,即是25254117个扇区，25254117*512/1024/1024/1024=12.04G）第二个分区：第二个红色框00表示非活动区。绿色框00 C1 FF代表磁头号、扇区号、柱面号。第二个蓝色框0F代表扩展分区。三条绿线所表达的也与上面相同。（注意这里的第二个分区代表扩展分区，切勿与通常的D盘相混淆！）因无其他主分区，所以第三、第四个分区表项为0。最后以55AA结尾，代表MBR结束。到这里，给道题目，如何知道D盘的EBR在哪里？很简单，从第一个分区表项得知，第一个分区有25254117个扇区，而在第一个分区前的MBR有63个扇区，因为整个硬盘扇区数从0记起，所以MBR扇区数+第一个分区扇区数=63+25254117=25254180，即通过转到25254180扇区即可。这里就是D盘前面的EBR了。对红线进行分析（红线前面446个字节，因为是扩展分区，不需要启动代码，用0填充）：00：非活动分区01 C1 FF 起始磁头号、扇区号、柱面号07：NTFS分区FE FF FF:本分区结束磁头号、扇区号、柱面号。其实可以发现，实际不需要理会这一项，所有分区表项都用这三个字节来表示本分区结束磁头、扇区和柱面的。3F 00 00 00：如前面分析MBR，倒过来是00 00 00 3F ，即63个扇区。8D 0D 23 03:倒过来是03 23 0D 8D,转为10进制是52628877，即本分区有52628877扇区，25.09G。为计算第二个EBR在哪里只需将前面的“MBR扇区数+第一个分区扇区数”+“EBR扇区数+第二个分区扇区数”略去对后面几个分区的计算。刚刚是对MBR，EBR（EBR实际与MBR类似，只是少了启动代码）的分析，现在对具体分区分析（以修复好的C盘为例）。通过翻阅资料得知，NTFS文件系统的结构是如何进入具体分区呢？选择winhex里的“工具打开磁盘”，选中相应物理磁盘即可打开。我的硬盘（修复好后）显示如下：双击想要看的分区即可，如partition 1,进入会看到很多此分区的文件，甚至包括一些即使你在文件夹选项里勾选“显示隐藏文件”都无法看到的文件。比如以$开头的文件。每个NTFS分区中都有这种文件，如下： 注意：MFT里的11到15号记录是为以后的元数据文件保留的。以上是的截图来自网上，补充下$Boot 、$MFT 、$MFTMirr的一些资料，因为此次修复与这几个有关。$Boot:NTFS的卷启动扇区，也叫分区启动扇区，卷启动记录等。虽叫扇区，其实包含了16个磁盘扇区（8KB），即你看到的$Boot文件大小是8KB。在winhex里双击相应的分区后，进去看到的该分区的第一个扇区就是$Boot所占的第一个分区。包含了BIOS参数块（BIOS Parameter Bloce，即BPB）和卷启动代码。BPB里包含此分区基本信息，如分区格式，大小等。至于卷启动代码，是表示如何装载WIN NT，2000等系统的NTLDR，把控制权交给它，得以继续装载系统其他部分。 对于$Boot里的BPB用以下的截图说明下，彩色部分就是BPB，对于$MFT文件，就是从BPB里定位的！这句话很重要。而我自己C盘的情况是对比这里的说明：图中第一条蓝色粗线是表示$MFT第一簇簇号，00 00 0C 00 00 00 00 00 ,倒过来是00000000000C0000，即16进制C0000转为10进制是786432，表示MFT在第786432簇（注意这里表示的是相对于本分区的簇数，而不是整个硬盘）。接下来，转去786432簇，看看是不是通过Go To Sector到786432，与单击$MFT去到的扇区都是一样的。说明定位没错。接下来看下$MFT吧$MFT：（Master File Table）文件。主文件列表。此文件是NTFS分区中最重要的文件，记录了分区中所有文件（包括$MFT自身）的基本信息。通过$MFT就可以访问分区中的所有文件和系统数据。$MFT由多个MFT记录单元组成，每一个文件的描述占用一到多个（一个不够的情况下）$MFT记录单元。其中前十二个记录单元中记录着这里的十二个系统文件的信息。每个记录单元记录着文件的建立时间、在分区中的位置、长度、属性、文件名等信息。MFT中的第一个记录就是$MFT自身，编号为0。每个文件记录占用1KB，即两个扇区。识别一项MFT的起始很简单，看开头的4个字节是否46 49 4C 45 ，其相应的ASCII码是FILE。现在就看MFT怎样记录其本身$MFT吧。同理，MFT的镜像$MFTMirr用同样的方法也可以计算得出和定位，$MFTMirr是对MFT里的重要文件备份，只有4K，即备份了4个文件记录单元而已。其实说了上面这些，还没涉及到故障的解决，有人会说，明明可以在winhex里选中$MFT就定位了，为何这般复杂，实际上，我此次故障，就是遇到MFT偏移了！说了前面这么多，只是为NTFS文件系统结构做个很大概的描述，实际上真的很复杂。在故障处理前，我双击C盘出现了这种情况：看来问题跟这个MFT是有些关系了的进去后，傻眼了，没有其他的文件，只有以下这几个，郁闷。方法一：用前面的方法，从分区引导扇区计算出MFT位置。所以，证明前面说的不算是废话。方法二：留意提示，看到了offset C0000000 和 offset 18158E000 字样，那就过去看看吧。发现C0000000里，不是一项文件记录的起始，文件记录的其实，一定是“46 49 4C 45”开头的，仔细找下，很明显偏移两行了！这就是故障所在。MFT里的第一项文件记录正是MFT本身，而现在本身位置都记录错了，如何定位其余文件呢？所以，此分区下的所有文件不可见！接下来尝试修复了。至于另外一个18158E000，其实可以猜测到是$MFTMirr的其实我曾经想过找相关MFT的修复软件试下，但始终觉得会否因软件“误判”，反而搞乱了。毕竟对于数据修复，一般是“只需一次成功，不许多次失败的”。还是手动吧 其实到这里我已经找到了故障所在，和处理方法了，只是即使想手动也有点下不了手期间在学校某个地方做过一次实验，也是一件坏事呃，把它的某个分区，用winhex写0了写0了是什么概念应该猜到吧。不过也自私庆幸幸好不是在自己的硬盘这样操作！这款软件是有一定危险性的。 拿修复$MFTMirr举例吧$MFT的我忘了截图。找到18158E000的那个扇区里（可以看到偏移了三行）选中46 49 4C 45开头的一段数据，多大好呢，我是一直选到非0的末尾，后面全0的就不选了。原因：记录一个文件其实有时候不需要用到1KB的。粘贴到正确位置就这样，手工的找，手工的修复，看到就修复，反正间隔1KB就一个记录所幸不是很多，10来个而已。保存退出，重启以为应该好了，默默的等待一种喜悦。结果启动不了。没办法，只好到另一个硬盘的linux里进去看，久违的那个分区是出现了，可是挂载不了，如图提示：有点郁闷，现在只好把硬盘挂到室友的XP下去chkdsk下了，懒了，不想再研究了。结果，在室友那里chkdsk修复后，把硬盘挂回自己电脑，启动，见到了久违的XP和久违的桌面！我成功了！也许对于牛人来说，这不算什么，但是毕竟对于我，因为是通过自己努力去尝试的，所以，有点成就感吧。写到这里基本完了.不过仍然有我不明白的地方，文中可能有些表述不当，还请指正下的，比较仅仅一个文件系统，还只是NTFS，都够研究很长时间了。我现在存在的疑问是：1.为什么有两个分区F和G，是NTFS的，在linux下可以是识别并正常读取里面的文件，但是在windows XP里不行。这是我至今还未解决的疑问。2.在我用winhex修复并重启后，虽然在和linux下读取不了，但是在winhex里是可以看到完整的文件的，并且没有found.000这个文件夹，如果我此时导出文件，相信文件位置不会出现错乱。但是用chkdsk扫描修复后，为什么多出这么多零碎的文件放进found.000里了.此次事件的总结：1.一开始尝试修复时，重建MBR，重建分区表，都是很傻的做法。当时病急乱投医.当硬盘出现误操作而又想尽力恢复数据时，切忌再往里头写数据，最好是先把硬