0x00 背景

公司接到一例鉴定报告意外丢失，需要进行数据恢复的紧急技术支援需求。

硬盘后面拍照如下图：

图1 硬盘盒的背面

将硬盘通过只读接口插到电脑上，如下图显示：

图2: F盘的文件

图3 分区的占用空间

    可以看出，分区F只有两个系统文件夹，分区的可用空间几乎是100%，此分区几乎没有任何数据了。

0x01 技术分析

    用管理员权限打开Winhex并加载这个硬盘，对相关的分区进行基本的磁盘快照，快照后，结果如下图所示：

图4 磁盘快照后发现了删除的文件

        从上图我们可以看到一个删除的文件，文件名是2020-0291.zip。正好是检材之一，只不过检材没有附加扩展名而已，同样也可以分析到，剩下检材的文件名及扩展名，先分析下此检材，看看这个文件的占用簇，但愿此文件是连续存储的。

    理论讲解：文件在硬盘上存储时一般会有两种情况，一是连续存储的，另外是分段存储到硬盘的不同区域。

    第一种情况产生的原因是，把文件直接复制进空分区中（此分区之前没有反复存放文件，删除文件的操作）。

    第二种情况产生的原因是，把文件复制进正在使用的分区中，分区之前有过大量的存储及删除操作。这样，分区中存储文件的区域是不连续的（删除文件所占用的空间可以被二次使用），存储新文件时，有可能就是不连续的。

    如果文件是连续存储的，那么，只需要定位文件的开始和结束就能把文件取出来。

图5 列出所有的簇

图6 好幸运，文件是连续的

图7 这个删除的文件可以获取到文件开始及文件大小

    恢复出这个文件后，直接做MD5校验，计算其哈希值。可以看到和硬盘盒背面标记的md5值一模一样。

    由于winhex的目录中没有剩下的三个文件的文件名，同样我们也得不到它的大小字节数，对于剩下的三个zip文件恢复就有点麻烦。

0x02 其它三个文件的恢复过程

    由于第一个文件正常恢复，根据此文件看看能不能有一些蛛丝马迹能帮助恢复剩下的三个文件。

       首先，这4个检材的报告都是由同一家鉴定公司出具的，所以我们可以大胆地猜测，它的文件结构及目录结构也是一样的，同时，由于第一个文件是连续存储的，所以我们也大胆猜测，复制这4个检材时，硬盘是空的。

    基于上面两点，我们开始分析恢复出来的这个zip文件。

图8 zip的内部目录结构

    它的一级目录是以检材命名的文件夹，一级目录里面是所有的检材信息。

图9 zip的二级目录

    有了这些信息，我们看一下这个zip文件的底层结构：

图10  zip文件的内部信息

从图10可以看出，每一个文件名/目录名都以ascii字符PK开始。编码改成CP 936后就能看到中文的目录名。我们可以总结到，每一个文件名都是从一级目录开始描述的。例如本例中的“2020-0291/“，第一级目录出现在文件的偏移30处（黑色箭头所指处）。剩下的只要能搜索到”2020-0291/“就能找到相关的结构。因为这个文件是连续的，所以只要确定文件头以后，搜索一定的连续区域就能把这个文件从磁盘上提取出来。

由于第一个文件能获取到它的文件大小（在NTFS的$MFT中记录），所以确定这个文件的结尾也比较简单（winhex已经帮我们完成了）。提取的这个文件经验证和硬盘盒上的校验值一样。

对于其它三个文件（以2020-0286为例），根据上面的分析，直接搜索它们各自的一级目录，在特定位置（offset mod 512 = 30）搜索相关的文本信息（2020-0286），如下图所示：

图11 在分区的特定位置搜索关键字

图12 在160485616扇区找到了特征值

    找到这个特征值后和恢复的第一个文件进行对比，发现这个结构和刚才恢复的文件的结构是一模一样的，这个开始地址正好位于一个扇区的开始，所以就获取到了这个文件的正确的开始扇区。

    然后从此扇区开始向下搜索一级目录的文本值，如图13所示：

图13 从当前扇区开始往下搜索一级目录的文本值

图14 搜索过程

图15 搜索到的最后一个文本值

    但是问题来了，怎么确定文件的最后一个字节呢？之前我们测试过，大多数情况下，在一个正常的文件结尾附加一些其它信息后，这个文件仍然能正常打开。所以本着宁多不少的原则，我们选择结尾时多选几个字节，选中磁盘的开始到结尾，并复制到一个新文件中。

    现在我们要做的是完全确定这个文件的最后一个字节，由于在硬盘盒上有这个文件的md5值，从文件的开始到计算相关的md5值，看看到哪个字节才能得到正确的哈希值。

原理解析：

根据Md5的原理，可以一个字节一个字节的计算相应的md5值。我们可以先计算除最后N个字节的md5值，然后再一个字节一个字节的更新其md5值，直到得到盒子上的哈希值。然后我们就能得到最后一个字节的偏移地址。

校验脚本如图16所示。

图16 判断文件结尾的脚本

    其它的几个文件都以此方式进行恢复。恢复结果如下图所示：

图17 恢复结果

0x03 反思

图18 恢复结果纪念

本例的四个文件能正常恢复，客户方面也是起到了重要的作用。

1、文件删除以后直接和我们联系了，客户对删除后的现场保护的很好。

2、鉴定结果的zip结构比较有规律。

3、zip文件包是连续存储的（这个170G+的zip也是连续存储的）。

4、根据zip文件的结构，能确定其在磁盘上的开始扇区。

5、确定文件的结尾是个体力活，如果没有做哈希值的话，恢复文件的哈希值就不一定了。

6、整个恢复过程，3小时，大多数时间都在搜索相关的文本值。

来源：河北阮咸科技有限公司

原文始发于微信公众号（电子物证）：【数据恢复一例】