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