本帖最后由 zck699 于 2015-12-3 03:27 编辑
通过查找$MFT反推DBR位置手工构建DBR
——一次手工恢复误GHOST严重损坏的分区实例
昨天下午,在我的淘宝店(zck699.taobao.com)接到一个客户,他介绍说他用GHOST安装系统,结果安装两三次系统都不能正常启动,然后用他原来系统的GHOST备份恢复,系统起来了,但系统中就只有一个C分区了,还有两个分区D和E不见了,让我给他恢复误GHOST前的E分区中的数据。想到这种问题一般都很简单,就是恢复一下分区表就完事了,所以也没有先远程看一下,就接了下来。
远程连接到客户电脑上,打开事先下载好的winhex,再在Winhex中打开待恢复的硬盘,硬盘在Winhex显示就只有一个分区。根据经验,这种情况在Winhex中是看不到原来的分区的,于是决定先用PTDD扫描一遍看看再说。
用PTDD扫描分区信息,扫描完成后,只在硬盘的后面部分有一个原来的分区信息,大小为99.7G,这个分区可能就是原来的E分区。根据客户的描述,原来的三个分区是C分区45G左右,D分区25G左右,E分区230G左右。显然PTDD扫描出来的分区并不是原来的分区。但还是不死心,万一是客户记错了呢?于是重建这个分区。
接下来在Winhex中打开硬盘,此时在目录浏览器中显示出了刚才重建的那个分,但单击这个分区,跳转到它的起始扇区,结果发现这个扇区数据全是0,现在很明显重建的这个分区并不是客户的E分区。
看来用软件扫描不到原来的分区了,只得手工恢复了。
通常情况下,XP在分区时会将第一个分区分为主分区,甚于分区分为逻辑分区,盘D、E两分区很有可能是逻辑分区,于是首先尝试查找扩展分区表。在Winhex中打开待恢复硬盘,根据客户所说C分区大约45G,于是从40G位置开始,设置搜索条件为512=508,向下查找000055AA。通过一翻搜索,倒是搜索到一个扩展分区表,但经查看,却是PTDD中搜索到的那个分区,看来没有这两个分区的扩展分区表项。
搜索扩展分区表失败,接下来想到直接搜索DBR。搜索了一部分扇区后,想到PTDD都没能搜出来,这两个分区的DBR扇区应该是已被破坏没有了,于是停止了搜索。
由于客户要的是E分区的数据,E分区大小为230G左右,应该是NTFS文件系统。由于客户不清楚这个分区是什么文件系统,因此只有先按NTFS文件系统尝试。是NTFS文件系统就一定有$MFT这个原文件(当然前提是$MFT没被损坏),于是去搜索这个原文件的文件名的十六进制值24004D0046005400,这次从50G位置开始向后搜索,搜索到若干个24004D0046005400后,终于在155698795扇区找到了一个$MFT的文件记录。
接下来要确认这个扇区是$MFT还是$MFTMirr的起始扇区。由于$MFTMirr只是前四个MFT项的备份,因此只要确定一下155698795扇区之后的若干个连续扇区中的MFT项是不是超过四个就能基本确定155698795扇区是$MFT的起始扇区还是$MFTMirr的起始扇区了。于是搜索NTFS文件记录的特征字节值46494C45,结果在155698795扇区后的部分连续扇区中找到找到了二三十个MFT项,可以确定155698795扇区就是$MFT的起始扇区了,没再往下搜索了。在这些MFT项中随便找了几个文件名给客户看,确定了那就是原E分区的文件。
找到了$MFT的起始扇区,接下来的工作便是确定E分区的起始扇区号了。
首先计算簇大小。分别查看80属性偏移24字节处的8个字节的值(属性结束VCN)和偏移40字节处的8个字节值(属性内容分配大小)再用“属性内容分配大小/(属性结束VCN+1)/512”得到簇大小扇区数为8。这里对属性结束VCN和属性内容分配大小这两个值没做记录,只记得计算出来的簇大小扇区数了。
接下下需要根据$MFT的80属性中记录的$MFT起始簇号和从簇大小扇区数去反推E分区的DBR位置了。查看80属性的第一个运行,得出起始簇号为3754787(这个与常见的$MTF起始簇号786432还不一样),用3754787*8得到E分区的$MFT之的扇区总数为30038296(3754787*8=30038296),再用$MFT所在扇区号155698795减去30038296得出E分区的DBR扇区应在125660499(155698795-30038296=125660499)。
跳转到125660499扇区,显然这个扇区并不是E分区的DBR,看来得在这个扇区写一个DBR。为以防万一,先把125660499扇区做一个备份。
首先拷贝一个正常的NTFS的DBR到125660499扇区,接下来要修改的几个参数有:簇大小(前面已计算为8)、隐藏扇区数(即该分区前的扇区数,就为125660499),分区大小扇区数,$MFT起始簇号(为3754787),$MFTMirr起始扇区号,现在还差两个参数。
先查$MFTMirr起始扇区号。$MFTMirr的文件记录项是$MFT的后面一个MFT记录项,跳转到155698797扇区查看该扇区中的文件记录项,从文件名属性(30属性)可看到它确是$MFTMirr的文件记录项,查看80属性运行列表,得出它的起始簇为23979812。
然后确定分区大小值。根据客户所说E分区是最后一个分区,于是只需将后面的全部扇区全分配给E分区就行了,在这里我也没全部分配,从目录浏览器中看到有一个未分区空间起始扇区为625137282,与硬盘总扇区数相差不过数千盲扇区,于是便以它为E分区结束位置。则E分区大小扇区数取625137281-125660499=499476782。
跳转到125660499扇区,用NTFS的引导扇区模板修改以上参数(分区大小扇区数为499476781,一会儿在分区表中分区大小填写为499476782),保存,DBR就写好了。
最后要做的就是写分区表了。分区表的三个主要参数分别为分区类型(NTFS为07),分区起始扇区号和分区大小扇区数。经客户同意,D分区不要了,只要把C分区和原来的E分区的分区表写出来就好了。
确定C分区和原来的E分区的起始扇区和分区大小就可以了。C分区起始已有了的,为63,大小为原E分区起始扇区125660499-63=125660436。E分区起始即为125660499,大小为499476782(因为DBR的备份位于分区的最后一个扇区,这个要比DBR中描述的多1)。得到这些参数后,把两个分区表写上就行了。
跳转到63扇区,修改C分区DBR中的分区大小值为125660435(C分区也是NTFS格式,因此这个值比分区表中描述的少1)。
最后,跳转到125660499扇区,将该扇区中的DBR数据拷贝下来写到625137281扇区做一个DBR备份。
修复到此就结束了。在Winhex关闭硬盘,重新打开硬盘,分区打开两个分区,第一个分区就是原来的系统了,经客户确认,第二个分区就是原来的E分区的数据。
经客户重启计算机,确定数据完全正确,至此本次恢复完毕。由于远程操作太慢,此次恢复竟然用了6小时左右时间。
顺便抛出一下问题大小讨论一下:一般情况下,误GHOST后造成只有一个分区的情况下是不会损坏后两分区分的DBR的,而且客户的系统分区有45G左右,一个XP系统怎么也不会有45G吧,也就是说应该不会覆盖掉后两个分区的DBR,这两个分区的DBR怎么会损坏呢?这个问题到现在我都还没弄明白。
数据有灾难?请联系淘宝网店“海数数据恢复中心”,为您提供数据恢复支援!地址:http://hisuo.taobao.com,旺旺:zck699,QQ:2360574454 |