文档标题：基于winhex数据恢复文件系统的脚本实现与智能恢复系统

文档介绍：

1绪论

1.1 研究背景与意义

信息技术飞速发展之际，数字化数据已然成了个人记忆、企业资产以及国家重要资源的主要承载形式。从日常办公文档、珍贵的照片、重要的业务数据库等处的数据都有它的价值，远远不止于储存的介质本身。但是数据丢失的风险无处不在，硬件老化故障、软件逻辑错误、用户误操作、病毒攻击、自然灾害等都会造成重要的数据瞬间消失。据不完全统计，在全世界范围内由于数据丢失造成的经济代价每年超过数千亿美元，而且个人用户对于数据丢失的应对也常常无能为力。所以研究高效、可靠、易用的数据恢复技术有重要的现实意义和经济价值。

传统的数据恢复方法依靠专业的技术人员进行手工操作，用WinHex这样的十六进制编辑器来分析磁盘底层数据。该种方式不但要掌握文件系统原理、数据结构甚至汇编语言，而且恢复过程繁杂、时间长、成功率很低。普通用户使用专业的数据恢复服务所付出的昂贵费用，也成了很大的阻碍。虽然市面上已经出现了不少的商业化恢复软件，但是它们大多把核心恢复逻辑封装成一个黑箱，用户不能够根据具体的场景做出灵活的选择，在复杂多样的碎片文件以及分区损坏的情况下效果不好。

以WinHex为基础，对数据恢复进行研究，试图解决该类软件出现的困境。WinHex是公认的专业的磁盘编辑软件，具有很强的底层访问能力以及灵活的脚本接口。本文用WinHex底层操作能力加智能化恢复算法来把其封装成高级语言，不但保持了专业的深度分析功能，而且以图形化界面+自动化流程的形式大幅降低使用门槛。系统可以自动识别数据丢失情况，智能选择最合适的恢复策略，在恢复效果、操作便捷性、成本控制三个因素上找到最佳平衡点，给高效的数据恢复能力普及带来新的技术途径。

1.2 国内外研究现状

1.2.1 国内研究现状

国内对于数据恢复的研究起步较晚，早期主要是为军工、保密、司法取证等行业提供服务，在没有自主技术的基础上，只能依靠进口的工具和技术来使用。随着信息化建设和网络安全意识的提高，国内学者以及企业也越发重视自主的数据恢复技术研究。近几年来，在windows平台下NTFS、FAT系列文件系统恢复工具已经比较成熟，有的产品在易用性、中文本地化支持方面也优于国外同类型软件。从学术上来说，国内高校在文件系统底层解析、磁盘坏道处理、文件签名库创建等各方面都做了大量的研究工作，并且取得了不少的理论成果。

但是，国内研究还存在着一些共同点。首先对于非Windows平台文件系统支持很少，不能满足跨平台数据恢复的需要。第二，就智能算法的应用而言，在基于内容特征的碎片文件自动重组、复杂损坏环境下的恢复策略改进等各方面同国外的先进研究还有较大差距。除此之外，已有研究大多只重视单一的技术点，缺少将底层操作、多文件系统兼容、智能算法和友好的用户界面综合起来的系统化、产品化的研究成果，这也是本课题努力实现的目的。

1.2.2 国外研究现状

国外对于数据恢复以及计算机取证领域所进行的研究起始时间较早，且形成了较为完善的理论体系和工程应用。早在二十世纪末，以SleuthKit、Scalpel为代表的开源工具就为基于文件签名的“雕复”技术打下了基础。学术界出现了很多有关文件系统结构分析、磁盘哈希比对、文件碎片分类和重组方面的研究结果。Carrier博士的著作系统地论述了文件系统取证分析的理论基础，Garfinkel等人的文件雕复、对象有效性验证等研究给深度扫描技术的发展带来了重大的影响。

目前国外主要的课题是智能化和自动化。一方面，用文件的字节频率分布、熵值等统计特征来训练分类器，用机器学习模型做文件类型的识别、碎片分类等工作，从而达到提高识别准确率的目的。另一方面，固态硬盘TRIM命令、垃圾回收机制给数据恢复带来新的挑战，加密文件系统、数据库文件等没有元数据情况下数据恢复问题也受到关注。但是大多数先进的研究结果都集成在昂贵的商业取证平台上，面向普通用户免费或者低价的工具在综合性能和智能化方面还存在欠缺，并且很少会和WinHex这种拥有编辑与脚本双重功能的底层工具深度融合。

1.3 主要研究内容

本课题意在设计并实现一个基于WinHex脚本化封装和智能算法的数据恢复系统，以底层访问、结构解析、智能识别、场景适配、友好交互为主线进行研究。主要研究内容就是将WinHex底层的功能进行封装和扩展。使用Python接口调用WinHex脚本来实现磁盘镜像的打开、读写扇区、字节级搜索等基础操作，建立统一、易用的磁盘操作层，给上层高级功能提供稳定的读取数据的基础。

其次研究并实现多种主流文件系统的解析。系统需要兼容Windows环境下的NTFS、FAT32、exFAT，Linux环境下的Ext2/3/4，以及macOS环境下的APFS文件系统。对各自的分区引导记录、元数据表、分配结构进行解析，快速恢复文件系统完好的已删除文件，给深度扫描提供必要的文件布局参考。

最后就是对文件的智能化识别与恢复算法进行研究。创建包含文档、图像、音视频、压缩包等多种类型的文件签名库，建立采用头尾签名与内容特征双重验证的方式文件类型识别器，并对没有文件系统元数据的碎片文件开展基于内容语义和结构特征的碎片重组工作，从而改善碎片文件的恢复状况。最后，对以上技术进行综合，开发出智能场景检测与恢复引擎，可以判断误删、格式化、分区丢失等场景，调度相应的任务，用图形化界面给用户提供便捷稳定恢复的体验。

2相关技术基础

2.1 数据恢复技术概述

数据恢复技术的主要原理就是依靠这样一个事实，即操作系统删除文件或者格式化磁盘的时候，并不会马上清除用户数据所占有的物理存储区，它只改变存储区的标记成可重用了，并且更新文件系统的管理结构。除非这些区域被新的数据所覆盖，原数据就会一直存在于存储介质中。按照这个原理，数据恢复技术可以分为两种：基于文件系统元数据的恢复、基于文件内容签名的恢复。

基于文件系统元数据的恢复适合于分区表、目录项、文件分配表等结构还在一定程度上可以被访问到或者部分被访问到的情形。恢复工具依靠解析结构找到文件数据存放的地方以及大小，进而把文件全部提取出来。该方法准确性好，速度也快，可以恢复文件名和时间戳等属性。但是前提条件是文件系统结构不能遭到严重破坏，执行了高级格式化或者文件系统重新创建之后，原来的元数据就会消失，该方法就不再适用了。

基于文件内容签名的恢复并不需要文件系统元数据，直接对磁盘上的原始数据进行扫描，找到有某种文件格式特征的文件。识别出文件头和文件尾，就可以得到文件的起始和结束位置，提取中间数据块。本方法在分区表丢失、磁盘重新格式化或者文件系统严重损坏的时候效果最好，是深度扫描技术的主要手段。但是对于碎片化的文件或者没有尾标记的文件格式，这种方法就存在很大困难，必须依靠更为复杂的方法来重组。

2.2 WinHex脚本化操作原理

WinHex是一款专业的十六进制编辑器以及磁盘编辑器，常被用来做数据恢复、计算机取证以及底层数据分析。其主要能力就是直接访问物理磁盘或者磁盘镜像文件，可以对数据进行字节级的修改操作，还可以按照十六进制数值来搜索和定位数据，并且能够对各种不同的数据结构进行解释。WinHex最强的一个特性就是它的内置脚本语言，用户可以编写脚本来自动执行一系列复杂的磁盘操作任务来达到恢复的目的。

WinHex脚本语言有各种各样的命令，可以进行文件的打开、定位到指定的偏移量处、读取或者写入数据、查找模式、循环等等。用户可以用脚本命令来使WinHex读取指定的磁盘扇区，在该扇区内找到一个十六进制的特征串，再把找到的数据段保存成一个新文件。因此脚本化使得WinHex由原来的一个交互式图形程序变成了一款可以编写的底层数据处理工具。脚本可以同时在WinHex图形界面中执行，也可以用命令行方式静默调用，方便与其它程序结合使用。

本研究根据这个特点，使用高级编程语言自动生成WinHex脚本，调用WinHex进程执行脚本来完成特定的任务。脚本化封装方案既具有灵活性又具稳定性能，一方面把复杂度高的扇区级操作细节封装成脚本的形式，屏蔽底层实现的差别；另一方面用 WinHex 成熟稳定的磁盘访问机制做为操作基础，防止从零开始实现磁盘驱动时遇到的兼容、安全等难题。该种模式就是用高阶的逻辑与底层的引擎相结合的方式，来创建专业级别的数据恢复软件。

2.3 磁盘结构与分区表

硬盘等存储介质在逻辑上可以分成若干层。最上层是物理扇区，传统的扇区大小是512字节，新型的大容量硬盘采用4K字节扇区。所有的数据读写操作都用扇区来表示。在扇区之上，磁盘是按分区的方式组织起来的，即把连续的扇区范围划分出一个逻辑单元来供操作系统独立地进行管理。主引导记录以及全局唯一标识符分区表为目前主流的两种分区表方案，二者位于磁盘的起始处，用来表述磁盘的分区结构。

MBR历史悠久，兼容性好。它占据磁盘第一个扇区，有两个部分，一个是引导代码，一个是分区表。分区表占据64字节，可以容纳4个主分区记录，每一个记录都有分区类型、起始柱面/磁头/扇区、起始扇区号和分区总扇区数这些信息。MBR用两个固定字节做结束标记，如果该标记有误，那么操作系统就会认定磁盘无效。MBR的不足就是不能管理超过2TB的磁盘，并且最多只能有4个主分区。

GPT是较为新的分区表标准，属于UEFI规范的一部分。使用保护性MBR结构来保证与旧工具的兼容性，真实分区信息存储在后面的GPT头、分区表阵列中。GPT头定义了分区表阵列的位置和大小，每个分区条目有分区类型GUID、唯一GUID、起始LBA和结束LBA这些信息。GPT理论认为可以有无数个分区，而且可以处理超过2TB的磁盘。数据恢复系统必须正确解析MBR和GPT结构，找出每一个分区的起始位置、大小、类型，这是后面访问分区内文件系统的前提。

2.4 常见文件系统结构分析

文件系统是操作系统用来管理和组织磁盘上文件、目录的结构化的办法。不同的操作系统使用不同的文件系统，每一个都有它自己的数据组织逻辑。NTFS是Windows系统自Windows NT以来的主流文件系统，其核心是主文件表。MFT是文件，由许多1KB大小的记录组成，每一个记录对应磁盘上一个文件或者目录。文件的元数据以及数据存储的位置信息都是以属性的形式保存在文件对应的MFT记录里。NTFS可以支持大文件、大数据卷、数据压缩、加密以及日志等。

FAT32以及exFAT更多地被用作移动存储设备或者具有跨平台兼容性的场景中使用。FAT32的文件分配表是文件的核心，它是大数组，每一个数组元素指向文件数据下一段的簇号，从而形成簇链。删除文件的时候只对目录项的第一个字符进行特殊的标记，然后清除FAT表中的簇链。FAT32单个文件不能大于4GB，而且每个卷的容量有限制。exFAT是它的改进版，专门设计给闪存存储使用，可以增大文件和卷的大小，减小FAT表的体积。

ext2、ext3、ext4都是Linux文件系统类。Ext文件系统把磁盘分成很多块组，每个块组有超级块、块位图、inode位图、inode表、数据块。inode是Ext文件系统的中心，每个文件都对应一个inode，保存了除文件名以外的所有元数据，即文件大小、权限、时间戳、指向数据块的指针等。Ext4与前几代不同之处在于其用区段树的方式来实现对大文件块的管理。另外，APFS是由苹果公司为替代HFS+而开发的一种新的文件系统，它主要是为闪存和固态存储而设计的，主要强调加密、快照、克隆、空间共享等功能，它的容器和卷的设计比较特别。理解这些结构就是设计有针对性恢复算法的基础。

2.5 文件签名与文件类型识别技术

文件签名，又叫“魔数”，是存储在文件头部的一段固定字节序列，用来唯一标识文件格式。以“%PDF”为开头的PDF文件，以8个字节的特殊签名为开头的PNG图片。这些签名是文件格式规范的一部分，即使文件系统元数据丢失之后，扫描磁盘原始数据中这些签名也可以找到相应的文件。

以签名为基础的文件类型识别就是深度扫描恢复技术的基础。识别流程通常包括两个阶段：签名匹配和边界确定。先对磁盘上的每个扇区进行扫描，然后得到扇区的数据，再将得到的数据和预设的签名库中的头部签名进行比较。一旦匹配成功，即认为发现了一个文件的可能起始点。程序要确定文件的结束位置。对有尾部签名的格式进行向后扫描直到尾部签名出现为止。对没有明确尾部签名的格式来说，则要依靠其他的手段，比如解析文件内部的长度字段或者按照文件类型设定的最大最小长度来截取。

为了提高识别的准确性、鲁棒性，单个头签名匹配不能满足需求。先进的识别技术会把尾签名验证、内容熵分析和内部数据结构一致性校验等综合起来使用。验证找到的PDF文件片段里是否有正确的对象定义结构。即便有头部匹配，如果后续的内容没有合法的PDF语法特征，那么它的置信度就会变低。本系统创建起多层次、多特征的文件签名识别体系，把签名契合结果同简单的语义剖析融合起来，进而提升文件种类判定的可信度。

2.6 碎片文件重组技术

文件碎片是文件数据分布在磁盘物理上不连续的许多地方。因为文件系统在分配空间的时候，会先用已标记为空闲的散落簇，所以文件会被分成了多个片段。当文件系统元数据完整的时候，可以利用簇链或者区段信息直接获取所有的碎片，并重新组合，不会出现重组失败的情况。但是，在深度扫描的情况下，只找到第一个碎片之后，后面各个碎片的位置就变得不明了，重组就是数据恢复领域最难的问题之一。

碎片重组技术可以分为两类，一类是根据文件系统知识，另一类是根据文件内容特征。前者在分区或者文件系统中存在时可以利用，例如从残留的FAT表片段或者日志文件中恢复出文件的原簇链。后者则更为通用且困难，完全不依赖文件系统信息。常用的有利用某个文件格式内部结构连续性进行片段拼接。JPEG文件是由一系列标记段组成的，每一个标记段都有一定的顺序和特征。重组算法将待恢复的多个数据块按照标记的出现顺序以及它们所具有的逻辑排列情况，排列成最合理的方式。

更加先进的碎片重组用到机器学习的方法，把碎片分类问题转变成决策问题。首先对于每一个碎片提取特征向量，即字节频率分布、小波分析系数、熵值等。接着训练分类器来判断两个连续的碎片是不是同一个文件。除此之外还可以采用类型识别的方式对碎片进行处理，在类型识别的基础上再使用匹配规则进行拼接。虽然技术的复杂程度很高，并不能保证100%成功，但是它们对于处理无元数据情况下严重的碎片化文件有明显的提高恢复率的作用，是数据恢复技术前沿的重要研究方向。

3系统需求分析与总体设计

3.1 系统需求分析

3.1.1 功能需求

本系统属于面向普通用户和专业人士的智能数据恢复软件，必须具有完备的磁盘镜像管理功能，即可以对常见的镜像格式实现打开和信息查询，能对底层数据进行扇区级别的读取。系统应该能够正确地识别人们所采用的MBR和GPT两种分区表来获取各分区的起始地址、大小以及类型，并以此作为之后文件系统的访问提供支持的基础。即便分区表损坏或者丢失，在系统中也应当可以利用扫描的方式找到可能的分区边界。

在文件系统层面，系统需要兼容Windows、Linux和macOS三大平台的主流文件系统，包括NTFS、FAT32、exFAT、Ext系列以及APFS。系统应该可以对各种文件系统解析出其核心管理结构，遍历目录树，提取文件名称、大小、时间戳等元数据，并找到文件数据在磁盘上的存放位置。对已经被删除但还没有被覆盖的文件，系统应当可以识别出它的目录项标记或者MFT记录状态，从而试图恢复它。

系统要提供快速扫描和深度扫描两种工作方式，在恢复能力上也得表现出色。快速扫描模式依靠文件系统的元数据，在分区结构正常，只出现误删的情况下，能迅速显示出可以恢复的文件，并且可以重建目录结构。深度扫描模式不需要任何文件系统信息，只通过文件签名来遍历磁盘原始数据，适合于分区丢失或者格式化之后的情况。除此之外，系统还要有文件类型的自动识别功能，可以对文件头、文件尾进行分析来判定文件类型，也可以进行简单的文件拼接工作。从用户界面来讲，系统应该具备图形化操作界面，用户可以借助鼠标点击来执行镜像加载、扫描开启、结果挑选以及文件恢复这些基本的操作，并且可以借助进度条以及日志的形式对任务的状态进行即时的显示，从而缩减用户的入门难度。

3.1.2 性能需求

数据恢复系统在实际使用当中一般要应对大容量存储介质，包括几十GB的个人U盘以及数TB的企业硬盘等都属于它的覆盖范围。所以扫描效率是系统可用性的重要指标之一。系统在快速扫描模式下应该可以在短时间内对上百G级的磁盘镜像进行全部遍历，让用户不用等太久就可以得到初步的可恢复文件列表。由于深度扫描模式需要逐扇区地对文件进行签名匹配、内容分析等操作，在这种模式下，扫描耗时一般会大于标准模式，但是扫描耗时仍然在用户的合理接受范围内，可以通过合理的设计算法以及使用缓存的方式来控制扫描耗时。

系统在普通的个人计算机上可以平稳地运行，不会占用太多的CPU、内存等资源造成计算机卡顿或者影响其它的任务。这就需要系统在设计时考虑到I/O操作的合理性，采用合理的分批读取策略而不是一次性加载所有的数据，并控制并发任务的线程数量来保证处理速度和资源消耗之间达到平衡。超大容量镜像时还要允许用户指定扫描的磁盘区或者搜索的文件类型，在不需要做全盘扫描的情况下提高恢复速度。

准确率是判断恢复好坏的标准。文件识别准确率指的是主流文件格式要达到较高的识别水平，即系统扫描到的文件同实际存在的文件具有较高的一致性，不能出现遗漏重要文件的情况，也不能导致过多的误报，防止把随机产生的数据当作有效的文件。碎片重组上，应该可以对常见的JPEG、PNG、PDF等有内部结构规律的文件进行重组，重组成功率要高于简单的头尾截断法。稳定性以及容错性也属于性能需求的一个方面，在系统遭受损坏扇区、读取超时或者出现畸形数据结构的时候可以妥善处理而不致崩溃，并把相关的异常信息告知用户。

3.1.3 用户需求

本系统目标用户群体分为个人用户、企业IT运维人员和计算机取证分析人员，不同类型的用户对于系统的使用需求是不同的，但是共同的诉求就是降低使用难度、提高恢复成功率。个人用户的个人用户数据丢失一般是由意外删除或者错误格式化引起的，在这种情况中用户一般没有专业的文件系统知识，并且对复杂的恢复工具也没有足够的使用经验。因此系统需要有简明的操作过程，引导用户逐步完成镜像的选择、扫描的启动、结果的查看以及文件的恢复等操作，每一个步骤都要给出明确的提示，不能出现过于专业的表述来引起用户的不便。

企业IT运维人员对于服务器或者员工工作站的故障处理情况会碰到更为复杂的状况，磁盘硬件故障前兆、权限被篡改、勒索病毒加密等都会出现在这里。他们需要对系统提供更详细的恢复日志、文件元数据信息和恢复结果的校验机制等来评价恢复的效果，并且将它记录在事件处理报告里。批量恢复能力以及灵活的筛选排序功能也一样重要，可以大大加快大批量文件恢复的速度。

专业的计算机取证人员对于数据是否完整、原始性高会有很高的标准。他们不但要恢复出文件的内容，而且还要得到文件在磁盘上的原位置、时间戳等元数据，在司法或者内部审计的时候可以作为证据使用。所以系统应该支持把恢复结果以结构化的格式导出，并记录完整的恢复过程日志，保证每一个操作都可以被追溯。另外脚本化的操作接口对于高级用户来说也有着一定的价值，可以编写出自动化脚本来执行批量处理镜像或者在服务器上进行无人值守的恢复任务。综合以上用户的使用需求，本系统的界面应该具有良好的用户体验同时又不能过于复杂，应有分层的设计理念来适应不同层次专业用户的使用习惯。

3.2 系统设计原则

为了保证系统的可用性、可维护性、可扩展性，本系统设计的原则有以下几个。模块化设计原则就是将系统划分为功能相对独立、接口清楚的各个模块。每个模块只完成一项具体的功能，磁盘访问模块只做底层的读写，文件系统解析模块只做元数据提取，恢复引擎模块只负责任务流程的协调。该种设计减小了模块之间的耦合度，即单个开发者可以对某个模块进行修改或者更换，而不会影响整个系统的运行，还可以便于多人共同开发以及后期的功能扩展。

分层架构原则，把系统抽象成若干个逻辑层次。最底层为数据访问层，是对磁盘镜像的扇区级操作做封装；中层为文件系统层，给各类文件系统解析的能力，上层为算法层与引擎层，完成签名检测、碎片重组、任务调度等复杂的逻辑，最上面层是用户界面层，实现与用户的交互。这样分层结构使得每层只依赖它直接下层的服务，不同层次之间的关注点互相隔离。

面向接口编程原则，也就是模块间用抽象的接口而不是具体的实现来互相联系。例如定义文件系统解析器的统一基类，所有的具体解析器都继承该基类并且实现相同的方法签名。因此，恢复引擎不需要关心当前处理的文件系统是哪个，只需要调用解析接口就可以。添加对一种新的文件系统的支持也十分简单，只需要编写一个新文件系统解析器类并进行注册，就不需要修改引擎的任何代码。因此该设计使得系统有很强的可扩展性。

高内聚、低耦合原则。每一个模块内的功能应当彼此联系、相互依存，模块间的关系也应该清楚、简单。比如，签名检测模块只是对给定的数据进行签名的匹配判断，不能执行读取或者写入文件的操作。这些职责应该由调用方或者其他专门模块来完成。经过明确的职责分工，能够很好地避免出现由于一处修改造成其它模块出错的情况，从而使得系统长久保持良好的维护水平。最后就是实用性、性能并重的原则，不能为追求理论上的完美架构而牺牲实际使用的体验，在重要的路径上用合理的优化手段来保证系统响应及时。

3.3 系统总体架构

本系统使用分层模块化的架构，由上到下分为用户界面层、业务逻辑层、算法支持层、文件系统抽象层、基础数据访问层。各个层之间利用定义好的接口进行通信，下层给上层提供服务，上层只调用下层接口，不直接依赖具体实现。这样层次结构使系统每一层都可以独立发展并加以改进，从而利于单元测试以及功能测试。

用户界面层属于架构的最上层，是同用户进行交互的地方。它用图形化的窗口来展示镜像的选择、扫描参数的设置、进度的追踪、结果的显示这些主要的界面元素。用户在这个层次上发出的指令会被转给业务逻辑层，而界面层本身并没有恢复的功能，只是对数据进行显示以及接受用户的输入。因此，该种设计方案使将来在开发命令行版或者Web版时能够直接复用下层所有的模块，无需更改核心代码。

业务逻辑层是系统调度的中心，是恢复引擎、场景检测器以及任务调度器这三个组件所组成的结构。恢复引擎是对整个恢复过程进行编排的引擎，在用户启动恢复之后，会先初始化各个模块、然后依次执行分区识别、文件系统解析、签名扫描等步骤，并且会协调各个阶段产生的数据流向。场景检测器对磁盘分区状况，文件系统的特性以及被删除过的记录加以综合考虑，从而作出当下数据丢失类型的判定，之后将此判定传达给引擎，再由引擎决定最恰当的恢复手段。任务调度器对并发执行的任务进行管理，调节并发度来防止出现资源竞争状况，任务进度也会及时反馈给界面层。

算法支撑层+文件系统抽象层就组成了系统的全部能力。算法支撑层由签名检测器、文件识别器、碎片重组器、恢复优化器等组成，它为具体的文件系统提供一个通用的智能恢复算法。文件系统抽象层使用基类以及插件的方式来解析NTFS、FAT32、exFAT、Ext和APFS等各种不同的文件系统，并给出统一的解析接口，将各个文件系统特有的数据结构转换成系统共有的文件对象模型。基础数据访问层处在最底层，封装了对于磁盘镜像文件以及WinHex脚本的操作，向上层给出扇区读取、字节范围读取这些原子性的操作。经过这样的分层设计，上层模块无需关心数据是由哪种介质、使用哪些底层工具得到的，因而使得整个架构显得更为清楚并且更具灵活性。

图3-1 系统架构图

3.4 系统模块划分

本系统分成七个主要的功能模块，每一个模块都有独立的实现单元。磁盘操作模块将所有的底层存储交互操作封装起来，即打开或者关闭磁盘镜像文件，按照扇区或者字节偏移量读取数据，获得镜像的大小等基本信息，并且为上层提供一种可选的数据缓存服务来提升连续读取性能。本模块会将WinHex脚本的调用封装成内部，上层模块无法看到WinHex的存在，只需要调用标准的读取接口就可以。

分区解析模块主要读取磁盘镜像的第一个扇区或者后续的GPT头和分区表，解析出磁盘上所有的分区的起始扇区、大小、类型和属性。该模块可以自动识别磁盘使用的是MBR分区或者GPT分区，然后返回格式化的分区信息列表，给文件系统解析模块提供统一的分区信息。分区表损坏的时候，该模块还要给予简化的分区搜寻功用，经由查阅某个签名从而推测有可能的分区界线。

文件系统解析模块，是文件系统最核心、也最复杂的一个部分。本模块按插件化思想来设计，是用以一个抽象基类以及多个具体的实现类。基类里有初始化、文件系统遍历、已删除文件扫描以及文件数据读取等常规接口。每个具体的解析器类都对应着一种文件系统，内部会根据该文件系统的要求来解析引导扇区、超级块、目录项或者MFT记录等结构。上层恢复引擎只需要得到当前分区对应的解析器实例，调用它的遍历接口就可以得到该分区下所有的可恢复文件列表，不需要知道底层到底是NTFS还是FAT32。

智能算法模块由签名检测器、文件识别器、碎片重组器、恢复优化器等部分组成。签名检测器加载文件头尾签名库，对给定的数据块进行签名匹配。文件识别器在签名匹配的基础上利用简单的语义分析给出综合置信度判断。碎片重组器针对JPEG、PNG、PDF等格式做简单的重组，把分散的数据块有条理地拼接成完整的文件。恢复优化器会依据文件类型、置信度、大小等要素来对恢复的结果实施排序并加以筛选，从而帮助用户尽快得到较为重要的文件。

恢复引擎模块是系统控制中心，它把各个模块整合起来完成从端到端的恢复工作。本模块在初始化阶段首先调用磁盘操作模块打开镜像，接着调用分区解析模块得到分区列表，然后为每一个分区实例化对应于它的文件系统解析器，最后初始化场景检测器、任务调度器等其它部分。用户启动恢复之后，引擎按照用户选取的模式以及场景检测的结果，规划出任务执行的先后次序，并对全过程的进展状况加以监督，最后把各个阶段所产出的文件汇集起来，然后交给结果管理子模块来存放与呈现。

用户界面模块、工具和配置模块分别用图形框架创建主窗口及交互控件，日志记录、加载配置以及通用辅助函数等由后者来提供。经过这样的模块划分之后，系统中各个部分之间的职责界线分明，便于分工完成开发工作，也利于以后功能上的添加与改进。

4系统详细设计与实现

4.1 底层磁盘操作模块

底层磁盘操作模块属于系统数据访问的根基，它给上层提供字节级以及扇区级的读取服务。模块有直接文件读取和WinHex脚本调用两种模式，前者的适用范围广，速度快；后者适合于需要使用WinHex特有的功能。双模式设计具有效率和兼容两个特点。

为了解决大容量磁盘频繁读取造成的性能问题，本模块中采用了LRU缓存的方式，把最近使用过的扇区数据保存到内存里，从而达到减少I/O操作的目的。缓存容量可以自由设置，用户可以自行选择内存使用与读取的速度之间哪一个优先。模块还可以对多片磁盘上连续扇区进行扫描，大大提高了顺序扫描的吞吐量。

分区表解析属于本模块的主要功能，它对MBR以及GPT这两种分区表实施了完整的解析工作。模块先读取0号扇区来判断分区类型，然后调用对应的解析器去遍历分区条目。当分区表损坏的时候，模块可以凭借搜索已经存在的引导扇区特点来判定分区的位置，从而为之后恢复工作提供入口。

4.2 文件系统解析模块

文件系统解析模块用策略模式来达到多平台兼容的目的。模块中创建了一个通用解析器基类，里面定义了初始化、目录遍历、文件数据获取等抽象方法。对于NTFS、FAT32、exFAT、Ext、APFS等文件系统，分别编写具体的解析器子类来实现这些方法，上层完全不需要感知底层的差别。

NTFS解析器以主文件表为起点，先从引导扇区里读取MFT起始位置，再一个接一个地遍历所有的MFT记录。解析器对记录签名以及删除标志展开检查工作，从中取得标准信息属性和文件名属性的相关数据，并且提取元数据资料，之后再从数据属性处解析出运行列表，从而把虚拟簇对应到具体的物理扇区上，并且读取文件的内容。

FAT32解析器主要是对文件分配表和目录项进行解析。解析器先从引导扇区得到FAT表和数据区的位置，然后从根目录簇开始遍历目录项，检验每一个条目的有效性及是否被删除。读取文件时，从起始簇号开始在FAT表里找到簇链，在逐个读取各个簇的数据之后再将其拼接成完整的文件。

exFAT、Ext、APFS解析器各有特点。exFAT使用位图来管理簇的分配，目录项的结构也更加灵活。Ext系列要处理间接块寻址以及区段树这两种映射形式。APFS使用的是容器加卷的方式，需要按照对象映射机制解析。采用统一基类接口，所有的解析器对上层透明，实现了多文件系统统一。

图4-3  文件系统解析界面

4.3 智能算法模块

智能算法模块对文件系统元数据完全丢失的时候具有重要的恢复作用。签名检测器会把JSON格式的签名库加载进来，保存各种文件的头尾签名。在匹配阶段把磁盘数据转成十六进制并和库里的签名相比较，找到所有可以匹配的前缀，给文件识别提供原始候选。

单纯依靠头签名匹配很容易产生误报，文件识别器加入了很多维度的验证。它可以检测尾部签名是否相符，对没有尾签名的格式就解析内部结构字段。校验ZIP文件的中央目录位置是否合理、PDF文件是否有合法的对象定义等。可以很好地排除随机数据产生的假匹配。

碎片重组器对JPEG、PNG和PDF进行基础重组逻辑的实现。JPEG的重组器先找到第一个碎片，分析末尾标记来确定是否结束。如果还没有结束，就在候选块中搜索标记序列匹配的后面碎片，用标记顺序约束来评价衔接的可能性，把分散的片段按照正确的顺序拼接成完整的文件。

4.4 恢复引擎模块

恢复引擎模块属于系统调度的中枢，用状态机和任务队列相融合的方式设计。初始化时分别实例化磁盘操作模块和分区解析模块，给每一个分区创建相应的文件系统解析器。任何一个环节出现致命错误都会给出明确的提示并终止初始化，防止之后出现不可预知的崩溃。

一旦开始恢复进程，在检测到用户选择的模式与场景后就会创建一个恢复任务。在快速扫描模式下遍历各个分区的文件系统解析器，把已经删除的文件过滤出来。深度扫描模式另外又创建了一个签名扫描任务，对磁盘上未被覆盖的每一个扇区都进行匹配签名，用置信度评价来排除误报。

任务调度器使用线程池来执行扫描任务，以独立单元的方式异步执行扫描任务，周期性报告扫描任务的进度。调度器使用线程安全结构对各个任务产生的文件记录进行收集，然后一起传给结果管理器存入数据库。用户勾选文件之后，引擎就创建起恢复任务，从中读取镜像数据并写入到输出目录当中，而且一直保持记录日志的状态以便于问题排查。

图4-5  恢复引擎界面

5系统测试与评估

5.1 测试环境

为了保证测试结果有较好的代表性、可重复性，本文以一台中等配置的个人计算机进行全方面的测试。测试用主机使用的是主流多核处理器和大量的内存，配备了固态硬盘来保证测试数据的读取速度不会成为瓶颈。操作系统使用最新的Windows 10或者Windows 11，使用相应的版本的Python来安装所有的依赖库。测试环境里还安装了WinHex软件，在需要的时候可以对底层操作进行对比验证。除此之外，测试环境不需要使用任何特殊的硬件或者商业软件，测试结果可以在同样的配置下用普通的计算机进行重现。

为了对系统在各种文件系统、不同的数据丢失情况下的恢复能力有一个全面的了解，测试人员事先制作了各种具有代表性磁盘镜像。包含NTFS、FAT32、exFAT、Ext4和APFS等众多主要的文件系统，镜像大小从几百MB到几十GB不等，适应于各种各样的测试环境。每个镜像里都会预先存放若干个已经知道内容的测试文件，包含各种常见的文档格式、图片格式、音视频格式和压缩包格式。部分镜像模拟数据丢失，比如删除一些文件并且不会在上面写入新的数据、删除并进行快速格式化之后再写入少量的新文件、删除MBR分区表等等。经过有意识地构造测试镜像之后，在可控环境下可以对系统的功能以及性能展开验证并作出评价，并且可以凭借与原文件内容的对比，实现客观量化的测试结果。

5.2 功能测试

功能测试目的在于检查系统能否正确实现设计文档里所描述的各项功能。测试按模块划分逐个执行，先做底层磁盘操作模块的测试。测试人员输入各种格式的合法镜像、非法文件，检验系统能否对镜像格式进行正确的判断，能否获取镜像大小，能否成功打开指定扇区并读取其中的内容。对于损坏的镜像或者读取越界的情况，模块应该给出明确的错误信息而不能导致程序崩溃。此外还要对WinHex脚本调用路径进行测试，在直接文件读取模式不可用时，系统可以从脚本模式平滑切换到继续工作。

然后测试分区解析模块和文件系统解析模块。测试人员加载包含MBR和GPT分区表的镜像来检测系统能否识别出所有的分区条目并正确解析出分区表。验证每一个分区对应的文件系统解析器可以被正确实例化，能正确遍历根目录以及子目录，从中找到所有的正常文件和已经删除的文件的元数据。特别对NTFS解析器进行了测试，保证其可以处理常驻数据、非常驻数据，可以正确解析数据运行列表并顺序读取分散的簇。对FAT32解析器进行验证，可以证明该系统是否能够跟踪FAT表链并将表链上的所有簇内容提取出来。验证了Ext解析器对于间接块、区段树这两种数据映射方式的正确支持。所有的文件系统解析器都通过了基本功能验证，可以给出合理的可用恢复文件列表。

智能算法模块功能测试主要是对签名检测、文件识别这两个功能进行检验。测试人员准备了一些已知格式的文件样本，把它们的内容写入原始磁盘区域，并清除文件系统元数据，再运行系统深度扫描模式。检验系统是否能在各个文件样本的开始处找到正确的头签名，以及如何依据签名及内部结构特点来判定文件的种类。对于带有尾部签名的格式还要检验系统能不能正确地判定文件结束的位置。测试人员手动生成JPEG、PNG文件分成若干个片段后分别存放在镜像不同位置，之后运行重组算法。验证重组器能否通过对文件内标记段顺序、特征的分析，将分散的片段按正确顺序拼接成完整的图片文件，拼接后的图片能正常打开。

恢复引擎以及用户界面的功能测试采取的是端到端的集成测试方式。测试人员使用图形界面操作恢复全过程，即加载镜像、选择恢复方式、开始扫描、查看扫描进度、结果表里选择需要恢复的文件、恢复并确认、核对恢复后输出目录是否有正确文件。同时测试了批量恢复功能、结果导出功能以及紧急停止功能，保证所有的辅助功能均按照要求正常运行，界面的响应及时，进度的反馈正确。所有的主要功能都通过了测试，可以完成从扫描开始一直到恢复结束的一系列操作。

测试模块	测试内容	测试结果
底层磁盘操作模块	加载合法及非法镜像，检查镜像格式识别、大小获取、扇区读取的功能，测试损坏镜像、越界请求的错误处理，验证WinHex脚本调用及模式切换	通过
分区解析与文件系统解析模块	解析MBR/GPT分区表，验证NTFS、FAT32、Ext等解析器的实例化、目录遍历、元数据提取、常驻/非常驻数据处理、FAT表链追踪、间接块与区段树映射	通过
智能算法模块	清除元数据后运行深度扫描，验证头尾签名检测、文件类型判断、JPEG/PNG碎片切割重组及拼接后文件可打开性	通过
恢复引擎与用户界面模块	端到端集成测试：镜像加载、模式选择、扫描监控、结果筛选、文件勾选、批量恢复、结果导出及紧急停止功能	通过

5.3 性能测试

性能测试主要是针对系统在真实环境中的性能进行考察，主要测试两个指标即扫描速度和资源消耗。扫描速度测试用不同的容量以及不同内容密度的测试镜像，执行快速扫描和深扫两种模式，得到从任务启动到所有任务完成所用的时间。从测试结果来看，快速扫描模式下耗时主要是文件系统解析器遍历目录树所花费的时间，和镜像总容量关系不大，但和文件数量有关。而深度扫描模式则是对用户指定的较大范围的磁盘数据区域进行扫描，并对每一块数据都进行签名比对，因此深度扫描的耗时同扫描范围大小呈线性增长关系。当合理的分配了扫描范围、并且采取了使用优化方法时，在主流硬件上可以达到系统的可操作性。

资源占用测试是利用系统运行过程中进程的CPU占用、内存占用等来衡量系统性能的一种方法。测试人员对测试过程中CPU、内存的变化做详细的记录，分别对空闲状态、快速扫描、深扫描以及大批量恢复做了CPU、内存变化的记录。快速扫描过程主要是对文件系统的结构进行解析，而深度扫描过程则是密集的计算，因为签名匹配会涉及到大量的字节数组转换以及字符串比较的操作。内存使用了分批读取、缓存淘汰的方式，不会因为扫描大镜像就一次性将全部镜像加载到内存中。经过测试发现，在默认的并发配置下系统对于CPU、内存的占用都是在一个合理的范围之内，不会对计算机上其他的任务造成太大的影响，即便是在扫描的时候，用户也可以正常地进行文档编辑或者网页浏览这些日常的操作。

除此之外测试还有缓存机制对于重复读取的性能改善分析。当上层多次请求同一个扇区的数据的时候，磁盘操作模块可以从LRU缓存里直接取出不需要再从镜像文件中读取。对于那些需要反复读取元数据以及数据区的碎片重组来说，这样可以很大程度上缩减I/O等待的时间。测试人员将开启缓存的恢复时间同关闭缓存的恢复时间做比较，得出结论，即缓存在现实当中对提高性能有明显的帮助。

表5-2 性能测试项目与结果

测试指标	测试内容	测试结果
扫描速度	使用不同容量镜像测试快速扫描和深度扫描模式，分析耗时与镜像容量、文件数量、扫描范围的关系	快速扫描耗时与文件数量相关，深度扫描耗时与扫描范围呈线性关系，速度满足可用性要求
资源占用	监控空闲、快速扫描、深度扫描、批量恢复时的CPU和内存使用情况	CPU和内存占用保持在合理范围，不影响计算机其他任务的正常运行
缓存机制	对比开启与关闭LRU缓存时重复读取相同扇区数据的恢复耗时	缓存机制显著减少I/O等待时间，对性能有明显改善作用

5.4 测试结论

经过全面系统功能测试、性能测试、对比测试可知如下结果。首先就功能完整性来说，在本系统的设计阶段中所规划出的所有功能都得到了实现，即磁盘镜像管理、多文件系统解析、快速扫描、深度扫描、文件签名识别、基本碎片重组、图形化用户界面等。系统在正常使用流程下运行稳定，没有出现造成崩溃或者数据损坏的严重缺陷，各个功能可以正常使用并产生预期的结果。边界情况处理较好，系统会给出错误提示并安全退出异常路径，不会出现无响应或者崩溃的情况。

从性能上讲，系统在主流硬件配置下表现出来。快速扫描模式可以以较快的速度对常用的文件系统进行遍历，而扫描范围和速度成正比。资源占用处于合适的程度，不会对用户的计算机其它工作造成太大的影响。

但是测试过程也暴露出一些不足之处。碎片重组算法目前只实现了部分文件格式，对于其他的格式支持还不是很全面。签名库虽然包含了常用的格式，但是对于一些使用私有签名的专业软件所生成的非标准格式，由于系统没有对此种类型的签名进行识别，所以会失败。就超大容量镜像全盘深度扫描来讲，总体耗费的时间仍然会超出用户的期望值，从而对匹配算法以及采用的更先进的采集手段做出进一步改良。但是本系统由于毕业设计的限制，只能验证一个基于WinShell脚本封装、智能算法创建的数据恢复系统的可行性，为之后的研究和工程的进一步改进打下了基础。