用Winhex手工定位NTFS文件系统下的文件

用 Winhex 手工定位 NTFS 文件系统下的文件

 

相信很多朋友在认真看完数据恢复书籍中，关于 NTFS 文件系统中讲述的一系列属性以后，或多或少还是有些范迷糊。确实， NTFS 文件系统结构比较复杂，且书中也没有讲到如何利用这些属性来定位文件，这对于初学者来说 , 无疑是一个缺憾 . 为弥补这一缺憾 , 我根据我个人对 NTFS 文件系统的理解，制作了本分析过程。申明，这只是本人的理解，难免会有错误的地方。仅供大家参考。

现在我就以我电脑里的一个叫“ MFT 结构分析”的图片文件，其存储路径为 E:\ 教程\ 数据恢复。

接下来我们一层一层的去定位文件 . 以对所学的属性做一个融会贯通 . 或许有的朋友会说 : 在实际操作中 , 可以通过在 MFT 中搜索文件名的方式来做出定位 , 这样也是可以的。我制作本分析过程的初衷也就是给初学者对 NTFS 的理解提供一个思路。

     学过 FAT 文件系统的 , 一定知道如何定位分区以及 DBR, 那好 , 我们就直接从 DBR 开始

从 DBR 中得出，每簇扇区数为 08H ，（ $MFT 一下简称 MFT ） .MFT 的起始簇为： 00000C00H ，转换为十六进制分别为 8 扇区和 786432 簇。现在跳转到 786432 簇，如下图：

我们可以看到，这是 MFT 的第一个记录，记录的是它自己。，接下来我们跳转到 MFT 的关于根目录的记录，也就是第 5 号记录。根目录一般存储的文件以及文件夹比较多。所以，它是非常驻的，关于这些文件夹的信息记录在了其它的位置。而记录在什么位置是由索引分配属性来记录的，也就是 A0 属性，接下来着重看一下 A0 属性，如图：

上图红色的标注的位置是运行（ Data run ） 31H 表示用三个字节描述的是索引的位置的起始 LCN （ 3E9002H ），一个字节描述的是长度 (02H) 。下一个运行的位置描述的是 00H 表示到此结束，只有一个运行。（提示：如果下一个运行由内容，那么它描述的 LCN 加上前一个运行描述的 LCN 才是其真正的 LCN ，如果由三个运行，用第三个运行的 LCN 加上前两个的 LCN 就是第三个运行的真正的 LCN ，以此类推！）

我们将其转换为 10 进制数值得到这样一个信息，索引项的起始位置为 167998 簇，乘以每簇扇区数 8 ，等于 1343984 扇区，长度为 2 个簇，跳转到 1343984 扇区，如图：

这个位置是根目录的索引项，可以看到里面索引的文件名为元数据。“教程”这个文件夹也存放在根目录里面，我们搜索该文件名，以找到相对应的索引项，由于 NTFS 里面文件名是用 Unincode 字符来表示的，所以该文件名转换为 16 进制数值为 59650B7A8765H ，我们在根目录索引项里搜索此文件名：

 

在 1343994 扇区找到了“教程”的索引项，（ 1343994-1343984=10 ，每簇扇区数为 8 ，说明次索引项存放在第二簇里面）从上图可以看出，其文件记录存放在第 6B3500H 号扇区，转换为十六进制为 13675 号记录，一个 MFT 占用 2 个扇区，其文件记录的开始为，从 MFT 第一号记录向下数 27350 个扇区，就其文件记录存放的位置，计算方式为： 6291456 + （ 13675*2 ） =6318806 ，跳转到 6318806 扇区，如图：

 

图中描述的本 MFT 号正是我们要找的，看下面的运行 31011BEB01H ，转换为 16 进制数值为： 125723 ，再乘以每簇扇区数 8 等于 1005784 扇区，现在跳转到 1005784 扇区搜索“数据恢复”这个文件夹的十六进制数值 70656E6362600D59H ，结果没找到，难道是此文件夹没有记录？不可能。猜想，会不会是被驻留了。存放在 MFT 里面，跳回 6318806 扇区，搜索 70656E6362600D59 ，在该 MFT 的第二个扇区里面找到了该文件夹的记录。

跳转到文件的“数据恢复”文件 MFT 记录号： 23A100000000H ，十进制为 41251 号，乘以 2 加上 6291456 ，等于 6373958 。如图：

对 NTFS 多少有点了解的人都会发现，这并不是 MFT 。为什么？看一下我的 MFT 的分布情况，如图：

 

我的 MFT 是分三大块来存放的，（我自己的命名）接下来计算一下：

第一块： MFT 从 786432 簇开始 , 到 796687 结束用了 10255 个簇 =82040 扇区，每 2 个扇区为一个完整的 MFT 。

第二块： MFT 从 397607 开始到结束 397686 ，用了 79 个簇 632

第三块： ……

 

第一块 MFT 只用了 10255 个簇来记录，（我用簇为来但来计算）而我们要找的文件“数据恢复”存放在 41251 号，（ 41251*2/8= 10312.75 簇）已经超出了第一块的记录范围，超出 75.75 个簇，经计算，在第二块里面才是存放的“数据恢复”的 MFT 。第二块的开始位置为 397607 簇，加上 75 簇，等于 397664 簇，由于硬盘是从 0 开始记录数据的，所以，这个地方应该还要减去 1 。跳转到 397663 簇的四分之三（ 0.75 ）位置，也就是第 6 个扇区

根据运行，得知其起始 LCN 为 A08AH(35488*8=283904), 占用一个簇。跳转到 283904 扇区：搜索文件名“ MFT ”结构分析 4D0046005400D37E7E00H

 

其文件 MFT 号为 26A1H （ 41254 号记录），根据前面的 MFT 记录块的计算，在“数据恢复” MFT 记录向下数三个记录，就是“ MFT 结构分析”这个文件的 MFT 记录了。跳转到该位置

 

其运行为 3281000F8F00H ，起始 LCN 为 0F8F00 （ 36623*8=292984 扇区），长度为 8100H （ 129*8=1032 扇区），那么结束位置为 292984+1032=294016 扇区

跳转到文件的开始 292984

跳转到 294016 ，选取上一个扇区的结尾

编辑 - 复制 - 植入新文件 - 保存文件名为“ MFT 结构分析 .jpg ”。双击，能够正常打开。

说明定位是正确的，而且也没有计算错误。

大家可以看到 NTFS 要比 FAT 复杂的多，但是只要是对文件系统的结构充分了解，然后再通过逆向分析，发现也不是很难。 NTFS 文件系统是学系 RAID 的基础，要想学习 RAID 的朋友，一定得充分熟悉 NTFS 的结构。文中有明白的地方请加 QQ 群 11391767 讨论。如有错误的地方，也欢迎各位网友加我的 QQ 共同讨论 86081166 。