前言

本节我们将进一步学习 FAT32 格式分区的损坏实例与恢复方式、技巧。

你可以在 https://winhex.im0o.top/ 中查看所有例题文件

知识点总览

  • FAT32 文件系统删除文件的分析
  • FAT32 文件系统删除文件后目录项起始簇号高位清零的分析
  • 实例:恢复 FAT32 中被删除的文件

FAT32 文件系统删除文件的分析

本案例中,在 FAT32 文件系统 中有文件 codingcat.gif

codingcat

文件删除前

从文件系统底层了解 FAT32 文件系统中文件各部分结构的管理。现在以 FAT32 分区中的文件 codingcat.gif 为例,讲解文件的底层结构。

image-20211022124227265

上图为文件在资源管理器内的截图。

image-20211022124911497

由于文件名超过了 8 个字符,目录项中就会存储两条名字,一条为长文件名目录项,一条为短文件名目录项。

从目录项中可以看出该文件开始于 05H(5 号)簇,文件大小为 1A B7 78H(十进制为 1750904)字节。

image-20211022130738474

FAT32 文件系统的 FAT 表是 32 位的,每个 FAT 项占用 4 字节

image-20211022131154308

从上图 FAT 表 中可以看出,文件 codingcat.gif 是连续存放的,该文件共占用了 107 个簇。

用 Winhex 跳转到分区的 5 号簇,其部分内容如图所示。

image-20211022131340664

从 5 号簇开始,往后连续的 1750904 字节( codingcat.gif 的文件大小),就是这个文件的所有数据。

删除文件

首先使用 Shift+Delete 将文件 codingcat.gif 删除(不是放入回收站)

无标题

删除后的文件目录项如图所示。

image-20211022133418736

从上图看出,codingcat.gif 的文件目录项的第一个字节已经被改为 E5 了,而文件名的其他字节没有发生变化,文件起始簇号 05H(5 号)簇看似没有改变,但因为 FAT32 文件系统是使用 4 个字节记录文件开始簇号的,当文件被删除后,文件开始簇号的高位 2 个字节是要清零的,所以 文件开始簇号 这个值实际上已经发生了改变,只是因为这个文件的高位簇部分本身就是 00 00H,所以看不出改变。另外文件大小 1A B7 78H (十进制为 1750904)字节没有改变。

在 FAT 表中查看原本 codingcat.gif占用的部分,我们发现:

image-20211022133947739

文件 codingcat.gif 在被删除后,其 FAT 表的簇链已经全部清零。

而跳转到 5 号簇查看文件的数据区

image-20211022134055794

如上图所示,数据区的内容并没有被改变。

恢复文件

将这个被删除的文件的数据区内容全部选中 → 编辑 → 复制选块 → 至新文件,选择保存路径,恢复文件。

2021-10-22_13-50-40

导出后的文件 recovery.gif 在资源管理器中的截图

image-20211022135409237

可以看到,这个就是被删除的 codingcat.gif 文件,以上也就是恢复被删除文件的过程。

补充说明

  1. 如果文件在数据区中存放的位置比较靠后,文件起始簇号就会很大,那么文件目录项中记录文件起始旗号的高位两个字节就会有数据, 当文件删除时, 这两个字节会被清零,该文件的起始簇号值也就丢失了,这种删除的文件比较难恢复。

  2. 文件删除后,其 FAT 表中的簇链也会清零,如果文件有碎片,也就是不连续存放,这种删除的文件也比较难恢复。

  3. 文件删除后,虽然文件的内容并不会被清除,但其所占用的簇会释放,这些簇就很容易被其他文件进一步占用,这样就覆盖了被删除文件的数据 这种情况下的数据将无法恢复。

FAT32 文件系统删除文件后目录项起始簇号高位清零的分析

上文提及到,如果文件在数据区中存放的位置比较靠后,文件起始簇号就会很大,那么文件目录项中记录文件起始簇号的高位两个字节就会有数据,当文件删除时,这两个字节会被清零。以下是高位簇目录项文件被删除的情况分析。

文件放入回收站后清空回收站

本小节实例来源《数据恢复深度揭秘》

针对文件放入回收站后清空回收站的操作分析。

在案例中的分区 G 下有一个文件 setupapi.log,该文件的信息,目录项如下图所示。

image-20211022203011824

image-20211022203514459

将该文件放入回收站后清空回收站(不是直接删除)。

查看该文件的目录项后。

image-20211022204104533

从目录项中可以看出,setupapi.log 文件的目录项仅仅首字节变成了 E5,其他位置都没有发生变化,起始簇号的高位簇也没有清零。

结论

在 FAT32 文件系统中,将文件先放入回收站,再清空回收站,这种删除方法并不清楚文件目录项中起始簇高位的两个字节。

直接删除文件

在分区根目录下有一个文件 river.bmp 如下图所示。

image-20211024193956062

文件目录项:

image-20211024194033229

​ 该文件起始簇号高位的两个字节是 00 3FH,低位的两个字节是 8D 10H,合并到一起,则该文件起始簇号的四个字节为 3F8D10H,转换为十进制为 4164880

​ 接下来用 Shift+Delete 组合键把文件彻底删除。

image-20211024194342701

image-20211024194539421

从目录项中可以看出,river.bmp 文件的目录项首字节变成了 E5,起始簇号高位的两个字节也被清零,如果用常规的数据恢复软件来恢复这个被删除的文件,软件会把该文件的起始簇号认为是 8D10H 簇,显然这样恢复出来的文件不可能正确。

结论

在 FAT32 文件系统中,将文件用 Shift+Delete 组合键直接彻底删除,这种删除方法将清除文件目录项中起始簇号高位的两个字节。

直接删除目录

在分区的根目录下有一个文件夹 789.

image-20211024195043126

该文件夹的起始簇号高位的两个字节是 002FH,低位的两个字节是 3427H,合并到一起,则该文件夹的起始簇号为 2F3427H,转换为十进制为 3093543

image-20211024201418926

在文件夹 789 下有两个文件 explorer.exeiis6.doc

image-20211024201430590

文件 explorer.exe 起始簇号的四个字节为 2F3428H;文件 iis6.doc 起始簇号的四个字节为 2F37E4H

image-20211024201855007

Shift+Delete 快捷键彻底删除文件夹 789

image-20211024202044463

从目录项中可以看出,789 文件夹的目录项首字节变成了 E5,起始簇号的高位两个字节也被清除。

image-20211024202353902

文件 explorer.exeiis6.doc 的目录项完好无损,首字节没有改为 E5, 起始簇高位也没有清零。

image-20211024202756025

结论

在 FAT32 文件系统中,将文件夹用 Shift+Delete 快捷键彻底删除,这种删除方法将清除文件夹的目录项中的高位簇,而文件夹里面的目录项不会改动。

实例:恢复 FAT32 中被删除的文件

从题库下载题目:FAT32-211026

本次实例没有对 MBR DBR 作破坏 仅对 Shift+Delete 删除的文件进行恢复

但实例教程中将以底层方式进行恢复,步骤会较为繁琐

本题需要找到的文件为 手工重建复合文档.doc

  1. 导入题目 FAT32-211026.vhd 后用 Winhex 打开

image-20211026200418189

  1. 跳转到 FAT32 分区 DBR

image-20211026200634443

从 DBR 获取到保留区大小FAT 表大小每簇扇区数3215,35232

  1. 向后跳转 30,736 扇区(保留区大小+ 2 * FAT 表大小)到达根目录。

2021-10-26_20-10-17

  1. 分析根目录

切换编码预览,在切换至 GB-2312 编码时发现根目录中有包含 工重~1DOC 字样的文件,其文件目录项第一个字节为 E5,初步推断该文件为我们需要恢复的文件。

image-20211026201611917

  1. 获取文件位置,大小

经过数据解释器查看,该文件的位置在 6 号簇,大小为 1,058,306 字节。

  1. 跳转至文件位置,选取大小进行恢复

向后跳转 128 扇区(每簇扇区数 * (6-2))

因为根目录簇号为 2,文件簇号为 6,则需要向后跳转 6-2=4 个簇

image-20211026201916310

跳转后发现文件为 复合文档,选中文件头,向后跳转1,058,306 字节,选中末尾。

2021-10-26_20-21-25

右键 → 编辑 → 复制选块 → 至新文件

image-20211026202226503

选取路径,进行文件恢复。

至此,你成功恢复了被删除的 FAT32 分区中的文件。