数据恢复者Rss 2.0
您当前位置:一盘数据 >> 技术文库 >> 故障案例 >> 浏览文章

WinHex手工恢复目录乱码

时间:2009年03月03日 信息来源:www.intohard.com 点击:收藏此文 【字体:

打开分区目录全部变成乱码的恢复

描述:一移动硬盘,整盘分为一个分区,FAT32格式,磁盘属性中显示已使用容量正常,但打开后所有文件夹和文件呈现乱码状态,无法访问,如图1所示:

用软件进行扫描后,恢复的目录结构不理想。需要恢复的文件为专用应用程序生成的文档,数量很大,如果按RAW方式恢复,则文件名将无法复原,从文件的可用性来讲是不可行的。

分析:一移动硬盘,整盘分为一个分区,FAT32格式,磁盘属性中显示已使用容量正常,但打开后所有文件夹和文件呈现乱码状态,无法访问,如图1所示:

Winhex 恢复打开分区乱码

图1

用软件进行扫描后,恢复的目录结构不理想。需要恢复的文件为专用应用程序生成的文档,数量很大,如果按RAW方式恢复,则文件名将无法复原,从文件的可用性来讲是不可行的。

分析:因磁盘内文件容量显示正常,所以判断FAT表应该正常。而根目录下的目录及文件呈现乱码,应该是根目录下的目录项出现了问题。

恢复方案:用WINHEX进行底层分析,手工修改目录项,使数据得以还原。

过程:对原盘进行全盘镜象,并复制并保存一份副本。

用Winhex打开镜象:

方法一:可以用“文件――打开”选项(图2)或点击“打开文件”快捷键(图3)打开镜象文件。

Winhex 恢复打开分区乱码

图2

Winhex 恢复打开分区乱码

图3

通过这种方式打开后,必须选择“专用――解释映象文件为磁盘”选项使WINHEX把镜象文件解释为以512字节为一个扇区单位的磁盘。如图4:

Winhex 恢复打开分区乱码

图4

方法二:WINHEX还有一个“容器”功能,可以以目录树的方式呈现磁盘内的目录和文件结构,可以依次打开“查看――显示”菜单,勾选“容器数据”选项(图5),即可调出容器窗口,图6:

Winhex 恢复打开分区乱码

图5

Winhex 恢复打开分区乱码

图6

然后单击“容器数据”窗口内的“文件”,在弹出的下拉菜单中选择“创建新的容器”,在弹出的“容器数据”窗口的“容器标题/数字”内为新创建的容器输入一个名字,在此我们为容器输入的名字是“1”,然后“确定”,如图7,可以看到容器“1”已经出现在窗口中:

Winhex 恢复打开分区乱码

图7

接着再次点击“容器数据”窗口内的“文件”,在弹出的下拉框中选择“添加映像”,即可将映象加入到容器中,Winhex已经直接将镜象解释为磁盘,图8:

Winhex 恢复打开分区乱码

图8

现在打开的是整个物理磁盘,为了便于分析,可以依次选择图8所示的“访问――分区1(37.3GB,FAT32)――打开”来打开逻辑磁盘。打开过程中,弹出如图9所示的错误提示:

Winhex 恢复打开分区乱码

图9

很明显,提示中所列出的偏移处的值均是不正常的,现在先转到第一个错误的偏移954C00H处,可以选择“位置――转到偏移量”,在弹出的“转到偏移量”对话框内输入“954C00”,跳转到这个偏移处,如图10:

Winhex 恢复打开分区乱码

图10

这个偏移量是19110号扇区的起始位置。请注意图中加亮处的各个“E5”值,很明显这是删除标记。删除标记应该是目录项的首字节,而目录项的首字节应该是在本扇区内偏移00H、20H、40H等位置,现在都向后位移了16个字节,而前一扇区内偏移954BE0H处的E5位置是正确的。也就是说,偏移954C00H~954CFFH这16个字节是被异常加入的字节。向下翻看,以确定这种位置的偏差情况一直延续到什么位置。翻过8个扇区,到19118号扇区的起始处时,发现这个位置的目录项已经是正常的了,也就是说异常偏移持续了8个扇区:19110~19117。

Winhex 恢复打开分区乱码

图11

回头看一下图9的错误列表,发现所有的错误偏移都在这8个扇区的范围内。而由DBR信息得知根目录为19102扇区开始的64个扇区,这8个扇区确实处在根目录内,这就是根目录下的文件和目录乱码的原因。

将19110号扇区~19117号扇区这8个扇区除前16字节以外的其他内容复制并写入19110号扇区起始偏移处,也就是向前提16个字节,恢复其原来面目。

保存更改后,用虚拟磁盘软件加载后,所有根目录内容恢复正常。如图12(图中有关私人或单位信息做了隐藏处理):

Winhex 恢复打开分区乱码

图12

重新用Winhex打开此逻辑磁盘,又弹出新的错误提示。图13:

Winhex 恢复打开分区乱码

图13

转到错误提示的943B93C00H偏移处,可见图14所示:

Winhex 恢复打开分区乱码

图14

从图中第二行开始应该是一个子目录,和前面的破坏方式一样,在前面加了16个字节的无用信息,导致正常记录向后偏移。那么为什么在图9所示的错误提示中没有发现这信位置的错误呢?因为,Winhex在打开逻辑分区时,首先会根据磁盘的各个逻辑参数罗列所有内容,先列举根目录,根目录下的某个子目录项如果错误,则不会继续列举其子目录的内容。即便列举,因为目录索引不正确,也不可能正确链接到它所指向的子目录,所以下级子目录中的错误是不会被发现的。而经过第一步的修复,根目录恢复正常后,正确链接到了它所指向的子目录,从而能够发现并提示子目录内容的错误了。

解决方法一样和前面修复根目录一样,移回去就可以了。

我有话说