• 【转】对MFT偏移的修正 记硬盘数据修复


    先把问题描述一下吧:(这个问题之前在一些电脑类论坛发过,可没有高手给出一个比较好的答案,只好自己动手)

    一开始开机,正常使用,突 然就死机,试过只能强制重启。重启后,无法进入xP系统,于是用PE进去,发现C盘和E盘都提示“文件或目录损坏且无法读取”,于是重建mbr,仍进不了 系统。于是重启又进入PE,发现250G的5个分区硬盘中,E盘反而好了,其他分区都又上面那个提示。用PTDD重建分区表,没用。
    在网上也搜过“文件或目录损坏且无法读取”的解决方法,最多提到的是chkdsk /f, 但是在PE里,提示无法识别ntfs。

    不知道有高手能解决吗。有谁遇到这样的问题。或者能否介绍外面数据恢复比较好的专业的维修店,价格怎样?


    补 充:下午已经把硬盘接到室友电脑,用chkdsk修复,修复程序提示修复完毕。然后我在Xp双击这些分区,还是有原来的C盘,F盘G盘无法进入。后来挂接 到我电脑用ubuntu进,竟然能进F和G盘,在FOUND.000这类文件夹里找到了不少修复的文件,随机在不同目录点了几个都还能用。

    问题又来了,linux能识别用windows的chkdsk工具修复过却仍无法识别的的ntfs分区?什么原因?

    前阵子,我在一次正常开机后,打开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)里的分区表来描述。
    一个以C盘为主分区,DEF为扩展分区的硬盘数据结构如下所示:
    1 附图: 01



    关 于主引导记录MBR。一般都占用63个扇区,即从第0-62扇区(这里有个例外,虚拟机里我看过只有56个扇区),而实际有写入内容的一般只有一个扇区, 及常说的0柱面0磁道1扇区。1个扇区512字节,MBR其实分三部分,1.引导代码446节 2.分区表64字节 3.结束标记55AA,及2个字节。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了。
    附图: 03


    对红线进行分析(红线前面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文件系统的结构是

    2 附图: 04



    如何进入具体分区呢?选择winhex里的“工具—打开磁盘”,选中相应物理磁盘即可打开。我的硬盘(修复好后)显示如下:
    1 附图: 05



    双击想要看的分区即可,如partition 1,进入…

    2 附图: 06



    会看到很多此分区的文件,甚至包括一些即使你在文件夹选项里勾选“显示隐藏文件”都无法看到的文件。比如以$开头的文件。每个NTFS分区中都有这种文件,如下:

    3 附图: 07



    注意: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里定位的!!!这句话很重要。
    附图: 08



    而我自己C盘的情况是
    2 附图: 09



    对比这里的说明:
    附图: 10



    图 中第一条蓝色粗线是表示$MFT第一簇簇号,00 00 0C 00 00 00 00 00 ,倒过来是00000000000C0000,即16进制C0000转为10进制是786432,表示MFT在第786432簇(注意这里表示的是相对于 本分区的簇数,而不是整个硬盘)。接下来,转去786432簇,看看是不是
    附图: 11



    通过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盘出现了这种情况:
    附图: 13



    看来问题跟这个MFT是有些关系了的…进去后,傻眼了,没有其他的文件,只有以下这几个,郁闷。
    附图: 14



    方法一:用前面的方法,从分区引导扇区计算出MFT位置。所以,证明前面说的不算是废话。
    方法二:留意提示,看到了offset C0000000 和 offset 18158E000 字样,那就过去看看吧。


    附图: 15



    发 现C0000000里,不是一项文件记录的起始,文件记录的其实,一定是“46 49 4C 45”开头的,仔细找下,很明显偏移两行了!!!这就是故障所在。MFT里的第一项文件记录正是MFT本身,而现在本身位置都记录错了,如何定位其余文件 呢?所以,此分区下的所有文件不可见!接下来尝试修复了。至于另外一个18158E000,其实可以猜测到是$MFTMirr的…
    --

    其实我曾经想过找相关MFT的修复软件试下,但始终觉得会否因软件“误判”,反而搞乱了。毕竟对于数据修复,一般是“只需一次成功,不许多次失败的”。还是手动吧…
       其实到这里我已经找到了故障所在,和处理方法了,只是即使想手动也有点下不了手…期间在学校某个地方做过一次实验,也是一件坏事…呃,把它的某个分区,用 winhex写0了…写0了是什么概念应该猜到吧。不过也自私庆幸幸好不是在自己的硬盘这样操作!这款软件是有一定危险性的。
       拿修复$MFTMirr举例吧…$MFT的我忘了截图。找到18158E000的那个扇区里(可以看到偏移了三行)…选中46 49 4C 45开头的一段数据,多大好呢,我是一直选到非0的末尾,后面全0的就不选了。原因:记录一个文件其实有时候不需要用到1KB的。
    附图: 16



    粘贴到正确位置…

    附图: 17



    就这样,手工的找,手工的修复,看到就修复,反正间隔1KB就一个记录…所幸不是很多,10来个而已。

    保存退出,重启…以为应该好了,默默的等待一种喜悦。结果启动不了。没办法,只好到另一个硬盘的linux里进去看,久违的那个分区是出现了,可是挂载不了,如图提示:
    附图: 18



    有点郁闷,现在只好把硬盘挂到室友的XP下去chkdsk下了,懒了,不想再研究了。

    结果,在室友那里chkdsk修复后,把硬盘挂回自己电脑,启动,见到了久违的XP和久违的桌面!!!我成功了!!!也许对于牛人来说,这不算什么,但是毕竟对于我,因为是通过自己努力去尝试的,所以,有点成就感吧。

    写到这里基本完了...不过仍然有我不明白的地方,文中可能有些表述不当,还请指正下的,比较仅仅一个文件系统,还只是NTFS,都够研究很长时间了。我现在存在的疑问是:

    1.为什么有两个分区F和G,是NTFS的,在linux下可以是识别并正常读取里面的文件,但是在windows XP里不行。这是我至今还未解决的疑问。

    2. 在我用winhex修复并重启后,虽然在XP和linux下读取不了,但是在winhex里是可以看到完整的文件的,并且没有found.000这个文件 夹,如果我此时导出文件,相信文件位置不会出现错乱。但是用chkdsk扫描修复后,为什么多出这么多零碎的文件放进found.000里了...
                                                 希望可以得到论坛里懂的人的帮助!解答一下
    --

    此次事件的总结:
    1.一开始尝试修复时,重建MBR,重建分区表,都是很傻的做法。当时病急乱投医...当硬盘出现误操作而又想尽力恢复数据时,切忌再往里头写数据,最好是先把硬盘拆下来,再到网上,或相关书本查询。

    2.硬盘数据修复,一般是只许一次成功,不许多次失败。所以,在方案的取舍,切忌一个个的试,最好有其他硬件模拟试验。我以前曾经误操作而用一个XP镜像覆盖全盘,后来用移动硬盘试过可以用PTDD重建分区表,做过实验了,也就有大的把握确定成功率。

    3. 任何事情,只要投入时间,愿意琢磨下,即使不成功,也多少有点回报的。像我在某个网站看到的那句话,说“你要是不会手动16进制写mft,不知道他的规 则,计算方式。就别费劲了,你从现在学,学3个月有可能能学会” 看到后确实有点打击,不过其实现在我还没懂多少,至少能取回数据了。

  • 相关阅读:
    HTML5 JS 实现浏览器全屏(F11的效果)
    SpringMVC学习笔记之二(SpringMVC高级参数绑定)
    二十三种设计模式总结
    系统开发中使用拦截器校验是否登录并使用MD5对用户登录密码进行加密
    Mybatis学习笔记之二(动态mapper开发和spring-mybatis整合)
    Mybatis学习笔记之一(环境搭建和入门案例介绍)
    Java中clone方法的使用
    列举Java中常用的包、类和接口
    Spring中bean的注入方式
    [ SSH框架 ] Spring框架学习之三(AOP开发和注解的使用)
  • 原文地址:https://www.cnblogs.com/beyond100/p/2042166.html
Copyright © 2020-2023  润新知