1、这是我们这里的一同行转到我这里来的一个数据，据客户描述故障为：盘分了三个区在一次意外死机后重启电脑后客户继续死机前的工作打开最后一个区（前两个区是正常的）提示未格式化（其实大多数朋友知道这时的问题简单得多也许重建 DBR 后整个盘里面的数据都在，这里暂且就不谈这种问题的解决方法了），要命的是这时客户鬼使神差地点击了格式化了，结果大家当然就知道了，数据肯定是没有了 。据转到我这里的那同行说他用各种搜索软件对整个区搜了好几遍（这也是大多数所谓专业的数据恢复商所用的恢复方法了），当然也搜到了很多数据，尽管很乱但还能正常打开。最后客户确认搜出来数据大部份正常，但客户最重要的的一个压缩文件损坏了，（据客
2、户说那压缩文件是他多年搞设计购买的素材库的精华）。大家知道压缩文件损坏了是很难很难修复的了。首先我用 WINHEX 把他搜出来的那个压缩文件打开分析了下，文件头乱了，中间的数据也不正常。无法修复，只好从原盘着手了。竟然搜索软件搜出来的是损坏的，那就只有用手工来做了，当然用手工做这种格式化了的数据很费时，且计算量也很大，只能针对像这样的个别特重要的数据。对原盘的那个格式化掉的分区做完镜像后，用 WINHEX 打开镜像，设置镜像文件为磁盘。如下图所示：1.jpg分区是 NTFS 格式的，整个分区大小为 25.4G。对 NTFS 分区格式研究过的朋友会知道，在 NTFS 文件系统中，文件亦是按簇进行
3、分配的， 文件通过主文件表 MFT（Master File Table）来确定其在磁盘上的存储位置、大小、属性等信息。相当于 FAT 系统下的 FAT+FDT 的功能。每文件都有一个文件记录。其中第一个记录就是 MFT 自己本身。我们转到第一个文件记录也就是 MFT 了直接点可以看到如下图所示：2.jpg通过第一个文件记录往下观察发现格式化了后对文件记录没有产生破坏。那么这时我们就可以有一个恢复的思路了：找客记所说的那个压缩文件的在 MFT 中的记录，再通过对文件记录的分析来确定文件在磁盘中的位置及大小，就可以直接从中提出文件了。想到做到，据客户告之，压缩文件名为：源文件与素材。那好，我们可以
4、新建一个文本记事本只输入压缩文件名源文件与素材！保存，再用 WINHEX 打开可以看到如下图：3.jpg然后再转回来，直接从第一个文件记录往下开始搜索十六进制数值 90 6E 87 65 F6 4E 0E 4E 20 7D 50 67 搜索到了一个地方停下来了，看看是不是那个压缩文件的记录呢看下图：4.jpg根据观察可以看出正是客户要的那个压缩文件的记录，那么我们又如何来确定这个压缩文件在磁盘上的那一个扇区？占用了多少的扇区呢？这个就需要对 NTFS 格式有所了解了。NTFS 将文件作为属性、属性值集合来处理，这一点其他文件系统不一样。可以看到在 MFT 中用了不同颜色的段来区分，5.jpg如
5、上图所标记的，第一个为文件记录头，第二个 10H 表示标准属性，第三个 30H 表示文件名属性，最后一个 80H 表示数据流属性也就是关键所在了。这里我们只分析数据流属性，其它属性就不一一分析了，可以查看相关资料。每一个属性都为两部份：属性头和内容。先来分析数据流属性的属性头：从第 1 第 4四个字节表示属性的类型，第 5 第 8 四个字节这里的值是 48 00 00 00 表示属性的长度（包括属性头和内容）为 72 个字节。从 17 到 24 共 8 个字节表示起始的 VCN 即虚拟簇号，第 25 到 32 共 8 个字节表示结束的 VCN 此处为 2D7FH 也就是 这个压缩文件占用了 1
6、1648 个簇。再往下分析从 33 到 40 共 8 个字节表示数据运行的偏移。此处为 40H 也就是从第 64 个字节开始了。我们就直接来分析数据运行也只有这一个运行 32 80 2D D5 58 17 所以起始的 LCN 即逻辑簇号为 1758D5H1530069，长度为2D80H11648。接下来我们转到 1530069 簇看6.jpg第一个字节右键选块开始，上面算出来了这个文件的大小为 11648 个簇，也就是1530069+116481541717 再转到 1541717 簇，所在的扇区的上一扇区也就是文件的结尾了。最后一个字节右键选块结尾。再在所选块中右键编辑复制扇区到新文件即指点到路径保存。然后改扩展名为RAR7.jpg解压成功8.jpg。至此恢复完成。经检查没有一个损坏的。后记：由于本人的数据恢复完全是自学，也许有些东西只是自身所理解的，文中如有不当之处请高手指点。谢谢！
