迅维网

标题: （个人原创）NTFS分区格式化后用WINHEX手工提取数据一例 [打印本页]

作者: 逆水寒 时间: 2008-8-30 19:56
标题: （个人原创）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-10-15 16:35
关于簇的计算比较难以理解呀！！！哥们的11648是怎么算出来的呀？？？别调哥们们的胃口呀，说的清楚一点，菜鸟不太容易懂呀

作者: 江苏杰瑞 时间: 2008-10-20 11:01
这个是如何计算的？

第一个为文件记录头，第二个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簇看

作者: mfgok 时间: 2008-10-20 12:00
我想知道，一开始怎么做的镜像呀

作者: 小罗花非花 时间: 2009-4-16 13:11
连续存储的应该可以通过文件类型文件头搜索出来的吧

如果不连续的就麻烦了 45。5M还是挺大的

作者: 终于来了 时间: 2009-4-26 14:20
本帖最后由终于来了于 2009-4-26 14:24 编辑

有一点有点不清楚，就是源文件与素材这个用WINHEX打开后为什么我电脑显示的16进制数值和楼主的不一样呢，这个真的好奇怪我的显示的是D4B4CEC4BCFED3EBCBD8B2C4

作者: 不动 时间: 2009-6-13 20:28
3# 爱死宝贝
我帮楼主回答

从17到24共8个字节表示起始的VCN即虚拟簇号 00 00 00 00 00 00 00 00

第25到32共8个字节表示结束的 7F 2D 00 00 00 00 00 00
计算的时候是反过来即开始是00结束是2D7F(转十进制11647)和楼主和11648差1,

作者: 不动 时间: 2009-6-14 13:25
有个疑问
楼主的这样做应该只能针对连续存放的数据有效.
请知道的解答下

欢迎光临迅维网 (https://www.chinafix.com/)