Windows注册表Hive文件恢复

[摘 要] 注册表是Windows操作系统、各种硬件设备以及应用程序得以运行的核心“数据库”，因此它记录着犯罪者进行犯罪的大量证据，成为打击计算机犯罪非常重要的线索和证据来源。本文对Hive文件的内部结构进行分析，具体探讨操作系统中各种Hive文件，并利用内部结构算法来恢复Hive文件。实验证明本文提出的方法在Hive文件恢复方面具有较高的准确性。

[关键词] 计算机犯罪 注册表 文件恢复

1.引言

最近几年，Windows注册表的取证分析技术逐渐成为计算机取证研究的重点之一。但是基于Windows注册表的取证分析技术还处于起步阶段，大部分的研究主要集中在注册表的分析，缺乏对注册表Hive文件恢复的研究。1999年，Russinovich在《注册表内部结构》中描述注册表的物理结构[1]。2005年，Harlan Carvey[2]提出了把注册表作为计算机取证的信息来源。2007年，Timothy Morgan在文献[3]中提出的算法能够从Hive文件中恢复出被删除的数据。对于操作频繁的Hive文件，此算法恢复效果就不是很理想。2008年，Jolanta Thomassen[4]在她的硕士毕业论文中深入浅出的介绍了Hive文件内部各组成部分的作用和原理，并且改进了被删除注册表数据的恢复算法。2008年，Brendan Dolan-Gavitt在文章[5]中详细说明了注册表存储在物理内存中的结构，并开发了基于内存的注册表取证工具。

2.Hive文件介绍

Windows XP的注册表逻辑上是以树形结构组织。它由两个注册表子目录树组成：HKEY_LOCAL_MACHINE（HKLM）和HKEY_USERS（HKU）。其实，在物理上注册表信息存储在多个独立的二进制文件中，这些文件被称为Hive。表1.1介绍注册表路径对应的Hive文件及其相关文件。

1999年，Russinovich首先描述Windows注册表Hive文件的的内部结构，并且说明各个组成部分的相互关系。具体内部结构如图1.1所示。注册表Hive文件包含头部块（Base block）和HBIN（Hive Bin）。头部块和HBIN的大小都是4096字节的整数倍。注册表的第一个块被称为头部块，在头部块后面是Hive文件所有HBIN块，每个HBIN包含一个HBIN头部和多个cell。头部块包含Hive文件的一些重要信息，如魔幻数“regf”、该Hive文件的名称、存储路径、修改日期和到根项的偏移量。HBIN头部包含魔幻数“hbin”、到第一个HBIN块的距离和该HBIN块的大小等信息。

图1.1 Hive文件内部结构

2.1分析

因为Windows系统中含有其它内部结构和Hive文件相似的文件，如：Hive文件的相关log文件和sav文件等，所以在对Hive文件恢复前，必要先对这些文件进行分析，研究它们之间的异同点。

在Windows XP SP2系统中，通过注册表路径HKLM\SYSTEM\CurrentControlSet \Control\Hivelist，可以找到全部的注册表Hive文件和相关的路径。其中HARDWAR存储系统启动的时候检查到的硬件信息，本文不对该文件进行恢复。SAM全称是安全账户管理，用来保存用户及用户组信息。SECURITY记录系统的安全信息。SOFTWARE存储每个应用程序的设置。SYSTEM记录磁盘驱动和服务配置。.DEFAULT记录关于用户的缺省设置。每一个用户都有NTUSER.DAT和UsrClass.dat，分别记录与用户的配置相关的信息和用户的文件类型关联信息。

除了Hivelist中包含的Hive文件之外，系统在其它地方也存储着和注册表相关的数据。log文件是Hive文件的修改事件日志文件。sav文件Windows XP安装过程中创建的Hive文件的备份文件。userdiff的作用是把用户的特征从前一个版本Windows NT更新到Windows NT 4.0。REGLOCS.OLD是Windows系统运行过程中产生的垃圾文件。hiberfil.sys是系统休眠文件。pagefile.sys是页面交换文件。repair文件夹下面的这些文件（default，ntuser.dat，sam，security，software和system）都是Windows系统第一次安装成功时生成的。剩余空间也包含Hive文件主要是由于删除操作系统或者系统用户遗留的。

如何从众多的干扰数据中把真正的Hive文件恢复出来。现在对这些非Hive文件的内部格式进行分析如下：

log文件在偏移量0X200处有标识符为“444952FF”，而Hive文件在该偏移量处全都是0。sav文件虽然它有魔幻数“regf”，但是它没有修改日期和文件名。userdiff文件可以通过文件名把userdiff文件和其它Hive文件区分开。REGLOCS.OLD文件头部没有修改日期和文件名。同样repair目录下面的文件头部只有魔幻数和校验值，没有修改日期和文件名。剩余空间、pagefile.sys和hiberfil.sys中可能含有部分的注册表头部信息，而且修改日期不是最近的。每一个用户，包括本地服务用户和网络服务用户，都有文件NTUSER.DAT和UsrClass.dat。NTUSER.DAT和UsrClass.dat中的路径名支持的长度是32个字母。因为NTUSER.DAT文件存放在用户文件夹下，因此它的路径中包含用户名，可以用于区分不同的用户的NTUSER.DAT。但是因为UsrClass.dat的路径太长，系统省略了用户文件名，因此每一个UsrClass.dat文件中路径都是一样的。UsrClass.dat文件的第一个项是和SID有关的。每个用户都有对应着一个唯一的SID。SID就是安全标识符（Security Identifiers）。例如：S-1-5-21-1390067357-1303643608-682003330-1003，其中第一项S表示该字符串是SID；第二项1是SID的版本号；第三项5是SID的签发者主代码（对于Windows XP来说，这个值永远是5）。在往后的四组数字是签发者子代码。最后是一个RID（Relative Identifier，相对标识符，即例子中的1003）。S-1-5-19表示本地服务用户；S-1-5-20表示网络服务用户；S-1-5-21-域-500表示系统管理员用户账号；S-1-5-21-域-501表示来宾账号；S-1-5-21-域-1001表示系统登录用户账号的RID从1001开始。对于每个系统登录用户账户，NTUSER.DAT文件的$$$PROTO.HIV\Software\Microsoft\Protected Storage System Provider含有一个以用户的SID命名的子键。

2.2恢复

文件恢复主要从两个层次进行：文件系统级和应用级。当文件系统被犯罪分子破坏的时候，文件系统级恢复就无能为力。应用级文件恢复可以在不依赖文件系统的情况下，利用文件的内部特征，达到恢复文件的目的。以下都是针对应用级的文件恢复技术。

注册表的Hive文件的头部块和HBIN块的大小都是4KB的整数倍。当文件系统中的簇大小为4KB时，注册表Hive文件的头部是不会被分片的。在现实中HBIN块之间经常发生分片。如图1.2所示。即分片点发生在两个HBIN块的连接处。Hive文件分片有两种情况：第一种是HBIN块后面不是HBIN块，但是这个HBIN块又有指针指向下一个HBIN块，这说明该Hive文件在此HBIN块后面发生了分片。第二种是HBIN块的后面是一个HBIN块，但是它们之间的到第一块HBIN距离之差不等于上一块HBIN块的大小。这说明Hive文件在此HBIN块分片。

图1.2 HBIN块之间发生分片情况

需要恢复的Hive文件名应该是SAM 、SECURITY、SOFTWARE、SYSTEM、HARDWARE、.DEFAULT以及每一个用户的NTUSER.DAT和UsrClass.dat。根据不同的文件名，依次搜索匹配。对于不同的用户的NTUSER.DAT可以通过路径中包含的用户名来区分。对于不同的用户的UsrClass.dat可以通过SID来区分。本地服务用户为S-1-5-19；网络服务用户为S-1-5-20；系统登录用户账号通过NTUSER.DAT文件的Protected Storage System Provider的SID命名的子键来获取SID。

当Hive文件不发生分片的时候，即Hive文件是连续的顺序存放在磁盘中。根据前面的分析，全部Hive文件可以被恢复出来。算法1的具体步骤如下：

（1）顺序搜索整个磁盘，找到前四个字节是“regf”开始的簇，并且该簇偏移量0X200处是标识符“00000000”，读取头部的文件名和修改日期。如果文件名相同的Hive文件有两个以上的，通过修改日期选择最近被修改的。

（2）判断Hive文件是否分片。如果不分片，Hive文件的全部hbin块都是在头部块后面，所以在找到正确的文件头部后，根据每个HBIN块的大小，找出Hive文件的全部HBIN。

（3）根据不同的文件名，重复操作步骤1和步骤2。

当Hive文件发生分片，并且分片位于两个HBIN块之间时。算法2具体恢复步骤如下：

（1）根据算法1的第一步，找到符合要求Hive文件头部块。

（2）判断Hive文件是否分片。如果Hive文件分片，找到分片点。通过前面的描述，可以知道下一个HBIN块到第一个HBIN块的距离。该距离是分片点前的HBIN块到第一个HBIN块的距离加上该HBIN块的大小。搜索整个磁盘，找到前四个字节是“hbin”开始的全部的簇，并且在该簇偏移量0X04处是该HBIN块到第一个HBIN块的距离。把符合条件的分片都找到，并把它们组合在一起，生成Hive文件。

（3）根据不同的文件名，重复操作步骤1和步骤2。

3.实验和结果

本文对Hive文件恢复进行实验。实验采用的数据集是Digital Corpora提供的nps-2009-realistic[6]。该数据集是一个正在运行的Windows XP系统，文件格式是NTFS，并且包含两个用户。该数据集一共有15个Hive文件，其中包括三个系统用户（adiminstrator、domex1和domex2）的六个Hive文件。这些Hive文件中只有DEFAULT和domex2的NTUSER.DAT文件发生了分片，分片点是在两个HBIN块之间。其它Hive文件都是连续的。

利用本文提出的算法对该数据集进行恢复，同时对比WinHex的恢复结果。WinHex没有提供对Hive文件的恢复，必须手动的添加Hive文件的特征，如：魔幻数“regf”和文件大小。假设最大的Hive文件能够达到1M，这样可以包含大部分的Hive文件。分别用这两个工具进行实验。结果表明这两个工具都可以能恢复Hive文件，但是效果有显著的差别。首先统计全部被恢复Hive文件的个数，文件大小，HBIN块、项和值的个数，如表4.12所示。

通过表4.12可以看到，本系统可以把全部需要的Hive文件恢复出来，并且Hive文件的项和值等数据没有丢失。本系统恢复的文件总大小要小于原有文件的大小。因为本系统是根据Hive文件头部信息来确定文件大小的，操作系统分配给Hive文件的大小有时候比Hive文件头部块中的标注的文件大小要大，尾部多余的数据没有任何意义。然而，WinHex恢复的文件数量超过原始文件，原因是系统中含有和Hive文件相似的文件，它把这些文件恢复出来了。而且WinHex只能获取固定大小的文件，产生的多余数据，有些不属于Hive文件，有些属于其他Hive文件。最重要的是当Hive文件发生分片时，WinHex不能成功找到分片。因此可以证明，我们提出的Hive文件恢复算法是准确且有效的，能够解决实际遇到的问题。其次，统计分片Hive文件的恢复情况，其中WinHex实际值表示WinHex恢复的数据中真正属于该Hive文件的值。如表4.13所示。

通过表4.13可以知道，本系统能够把DEFAULT中分片找到，并正确的和其它分片拼接一起。对该文件的恢复是准确的。但是，WinHex有部分数据是丢失的，究其原因是它只能找到DEFAULT文件的第一个分片，丢失了第二个分片。同样对于domex2的NTUSER.DAT文件，本系统可以正确的把全部数据恢复出来，但是WinHex就只能回复部分数据。恢复结果如表4.14所示。

4.结论

本文在结合前人研究的基础上，利用Windows注册表Hive文件的内部结构特征，提出了一种算法来恢复Hive文件。实验表明该算法能够提高Hive文件恢复效率，减少误报。

参考文献：

[1]Russinovich Mark.Inside the Registry [EB/OL]. [2009-06-17]. technet.省略/ en-us/library/ cc750583.aspx.

[2]Harlan Carvey.The Windows Registry as a forensic resource [J].Digital Investigation, 2005, 2(3):201-205.

[3]Morgan Timothy D. Recovering deleted data from the Windows registry[J].DigitalInvestigation, 2008, 5 (1):33-41.

[4]Jolanta Thomassen.Forensic analysis of unallocated space in Windows registry Hive files [D]. University of Liverpool, 2008.

[5]Dolan-Gavitt Brendan.Forensic analysis of the Windows registry in memory [J]. Digital Investigation, 2008, 5(1):52-57.

[6]Digital Corpora.nps-2009-realistic [EB/OL]. [2009-08-09].省略/corp/images/images_ info.php?imagesDir=nps-2009-domexusers.