大多数时候，取证要解决的无非是弄清楚什么人在什么时间在什么地方做了什么事情，也就是4W问题（Who，When，Where，What）。所以时间在取证领域是非常重要的问题。

计算机中是怎么存储时间的呢？首先我们来看看Windows的安装时间。

以Windows 11为例，要查看Windows系统安装时间，我们可以打开设置，在“系统”→“系统信息”中可以看到，当前这台电脑的系统安装时间是2023年3月31日。如下图所示。

通过上述方法，我们可以得知这台电脑上当前操作系统的安装日期，那么能不能得知具体的安装时间呢？

按Win+R快捷键打开“运行”窗口，输入并执行“cmd”打开命令提示符，或输入并执行“PowerShell”打开PowerShell。我们也可以按Win键或点击开始菜单图标，然后直接输入“cmd”或“PowerShell”按屏幕提示打开命令提示符或PowerShell。

在命令提示符或PowerShell中，我们执行“systeminfo”，即可查看系统的各种信息，其中就包含操作系统的安装时间。如下图所示，此电脑的系统安装时间是2023-03-31 11:14:26。

那么，systeminfo命令又是怎么知道系统安装时间的呢？其实系统安装时间保存在注册表中。

我们按Win+R快捷键打开“运行”窗口，输入并执行“regedit”打开注册表编辑器，然后在左边的目录树展开到“计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion”，可以看到右边有个名称为“InstallDate”的记录，对应的值为0x64265012(1680232466)，即用十六进制表示为64265012，对应的十进制值为1680232466。如下图所示。

我们可以用PowerShell的相关命令来解析上图的时间。

按Win+R快捷键打开“运行”窗口，输入并执行“PowerShell”打开PowerShell。在PowerShell中执行“(Get-Date -Date "1970-01-01 00:00:00Z").toUniversalTime().addSeconds(1680232466)”，即可得到可读格式。如下图所示。

上述PowerShell命令，用途是显示在UTC时间1970年1月1日00:00的基础上加上1680232466秒的时间，各函数的具体功能可以很方便地在搜索引擎中检索到。考虑计算机当前的时区是北京时间（UTC +8），上述PowerShell命令解析的时间正好与systeminfo命令得到的系统安装时间一致。

通过上述命令可以得知，注册表中保存的Windows系统安装时间实际记录的是自1970年1月1日00:00以来经过的秒数。其实，这一时间格式就是在计算机中广泛使用的Unix时间戳。

在计算机中，绝大多数时间格式都是类似的原理：①选定一个时间起点；②确定一个时间间隔单位；③记录从时间起点以来经过的时间间隔数量。

我们再看看WPS表格（Excel相同）中的时间，它们同样符合上述规律。

我们在A1单元格中输入当前的时间，例如“2023-04-16 18:35”，输入完按回车键后，我们可以注意到A1单元格中的内容自动变成了“2022/4/16 18:35”，重新点击A1单元格，则可以在编辑栏中看到“2022/4/16 18:35:00”。显然，WPS已经将我们输入的“2023-04-16 18:35”识别为了时间类型的数据并以默认的格式显示。如下图所示。

接下来，右击单元格A1选择“设置单元格格式”，或选择A1单元格后直接按Ctrl+1快捷键设置单元格格式。我们可以注意到当前数字格式为“自定义（yyyy/m/d h:mm）”。我们将其更改为“常规”，可以发现A1单元格中的数据已经变成了“45032.7743055556”。如下图所示。

我们将当前文档保存为“工作簿1.xlsx”，然后用7-Zip等软件打开（也可以将扩展名改为“zip”然后双击打开）。找到“xl”目录下的“worksheets”，此目录中保存着各工作表中的文字内容。如下图所示。

找到“worksheets”目录下的“sheet1.xml”，打开后即可找到刚刚A1单元格的数据“45032.7743055556”。如下图所示。而刚刚A1单元格默认显示的是2023年4月16日18时35分这一日期。这说明，在xlsx文件内部，日期是用数字来记录的。

我们继续测试。

、打开“工作簿1.xlsx”，在A2单元格输入“45031.7743055556”，正好与A1单元格的数字小1。接下来选择A列（A:A），右击，选择“设置单元格格式”。将数字格式设置为“自定义”，并手工输入“yyyy-MM-dd hh:mm:ss”。如下图所示。

设置显示格式后，我们可以发现，A2单元格的时间为“2023-04-15 18:35:00”，正好比A1单元格早一天。如下图所示。

上述实验说明xlsx文件中的时间，基本间隔单位为1天。那么，Xlsx文件中的“时间起点”又是什么时候呢？

我们在A3输入“0”、A4单元格输入“1”，可以发现A3单元格显示的是“1900-01-00 00:00:00”，A4单元格则是“1900-01-01 00:00:00”，如下图所示。

所以，xlsx文件中时间的“起点”是1899年12月31日00:00:00。

第八届全国取证赛马上就要开始了，不少人都在摩拳擦掌积极备赛。今天突然有人问我Linux 软RAID的相关问题，我直接推荐UFS Explorer RAID Recovery，但试用版无法导出大文件（其实可以变通地先导出分区镜像，然后用其他工具加载并分析）。由于日常使用X-Ways Forensics更多一些，便尝试了一番，发现X-Ways其实处理软RAID也挺方便的。

Linux下的软RAID一般是Mdadm（全称Multiple Disk and Device Administration），2017年取证赛和2018年取证赛的团队赛中均有涉及，下面以2017年为例，介绍一下X-Ways的详细处理步骤。

三个镜像文件分别为“efc-hd1.E01”、“efc-hd2.E01”、“efc-hd3.E01”，大小分别为21.5GB、21.4GB、21.5GB。
X-Ways中新建案例，添加三个镜像文件。如图1所示。

X-Ways没有直接解析出RAID中的分区，但识别出了软RAID（MD RAID Container）。对于每个镜像，X-Ways均列出了RAID头及RAID容器，并对RAID头虚拟分区添加了RAID信息注释（见图一名称列的黄色图标），注释中包含RAID的UUID、RAID类型、磁盘数量、条带大小等信息。

双击打开每个镜像中的MD RAID Container分区，保证这些分区处于活动状态。此时这些分区中的数据暂时还无法查看。
点击主菜单“Specialist”→“Reconstruct RAID System”，如果当前使用普通权限打开的X-Ways，会弹出需要管理员权限的提示，可忽略。

在RAID设置界面，组件选择各镜像中的MD RAID Container分区，RAID头大小保持默认（0）。通过图2 X-Ways注释信息可知RAID类型为RAID 5 (backward dynamic)，条带大小为1024。如图3所示。

点击“OK”后，X-Ways 目录浏览器（Directory Explorer）中会多出一个磁盘，里面有三个分区，其中分区1为LVM2容器，分区2、分区3存在于LVM2容器中，大小分别为25.1GB、27.0GB。如4所示。

此时X-Ways已经成功解析了RAID，但双击分区2、分区无法正常打开，尝试将识别的分区添加到案例，提示“Component partition cannot be remembered”，不知道是不是Bug。如图5、图6所示。

分别双击打开RAID中的分区2、分区3，然后点击主菜单中的File→Save As，将整个未识别的分区保存为单个文件，并作为镜像重新添加到案例，即可查看其中的内容。如图7所示。

总结一下要点：
1、X-Ways的RAID重组功能，数据源只能是磁盘或分区（可以是本地设备，也可以是X-Ways解析得到的），不能直接加载镜像。
2、对于软RAID，数据源应该是RAID容器分区，而不是磁盘。
3、软RAID参数，可以从X-Ways解析的RAID中查看。
4、对于本案例，X-Ways无法直接解析RAID中的两个卷（Volume）。RAID中看起来是两个卷，但是单独保存后重新加载，发现实际是分区（Partition）。

数据恢复永远是电子数据取证中最重要的内容之一。每当客户问我：胡工，能帮忙恢复一下xx文件吗？大部分时候我的回答是：很遗憾，这些文件已经彻底无法恢复了。

无法恢复的原因是如今操作系统（无论是Windows、macOS，还是Android、iOS）均支持固态硬盘的[[2-电子取证:2.基础知识:trim|TRIM]]功能，且会默认启用。这意味着文件删除后，系统会在空闲时间将对应区域置零，也就是彻底删除。

以Windows为例，判断文件是否恢复的方法很简单。使用X-Ways Forensics（其他取证工具亦可）加载镜像，将某个分区进行递归浏览（Explore recursively），然后按大小排序，找到体积最大的“空余空间(net)”或“Free space (net)”，以“File”视图查看十六进制内容，如下图所示。如果内容全为零，意味着文件不可恢复。

原理很简单。X-Ways Forensics中显示的“空余空间(net)”，并非具体某一个文件，而是分区中未分配空间的集合，他们甚至都不是连续的（FTK Imager中的“unallocated space”节点就是X-Ways Forensics中“空余空间(net)”按实际情况分段显示的结果）。文件删除后，占用的空间被释放，成为未分配空间（X-Ways Forensics中的Free space，FTK Imager中的unallocated space）的一部分，如果未分配空间为全零，文件自然就无法恢复了。

当我说恢复的希望很渺茫或科普完TRIM的相关知识后，对方往往不甘心地问我，会不会这台电脑正好没有启用TRIM功能呢？也不是没有可能。那就检查确定一下吧。

管理员权限打开命令提示符，执行“fsutil behavior query DisableDeleteNotify”，如果执行结果为“DisableDeleteNotify = 0”或“NTFS DisableDeleteNotify = 0 (已禁用)”，意味着TRIM已启用，反之若执行结果为“DisableDeleteNotify = 1”或“NTFS DisableDeleteNotify = 1 (已启用)”，意味着TRIM未启用。

以上内容网上很容易搜到（顺便吐槽一下微软，上图中的“已禁用”真的很容易引起误解）。开机情况通过命令提示符或PowerShell可以直接查询TRIM状态，那么关机情况呢？

网上搜了一下，基本没有收获。所以只好自己想办法了。

管理员权限打开命令提示符或PowerShell，先执行“fsutil behavior set disabledeletenotify 1”关闭TRIM。然后输入“fsutil behavior set disabledeletenotify 0”备用。

打开RegistryChangesView，点击Creat Registry Snapshot创建当前注册表快照。

马上回到命令提示符或PowerShell，按回车键执行刚刚输入的启用TRIM命令。

接着回到RegistryChangesView，点击OK按钮对比当前注册表和刚刚创建的注册表快照。如下图所示。

很明显，启用TRIM后，HKEY_LOCAL_MACHINE\System\ControlSet001\ Control\FileSystem\DisableDeleteNotification的值由“1”变成了“0”。

我们来验证一下。

打开注册表，定位到HKEY_LOCAL_MACHINE\System\ControlSet001\ Control\FileSystem\，将DisableDeleteNotification的值由“0”改为“1”。

回到命令提示符或PowerShell，执行“fsutil behavior query DisableDeleteNotify”，结果显示NTFS文件系统的TRIM已禁用。如下图所示（请忽略图中容易让人误解的“已启用”）。

至此，Windows系统下TRIM是否启用的标记已经找到了。X-Ways Forensics加载后定位到“C:\Windows\System32\config\SYSTEM”,打开后定位到HKEY_LOCAL_MACHINE\System\ControlSet001\Control\ FileSystem\，若DisableDeleteNotification值为0，则意味着TRIM已启用。

今天在使用X-Ways处理工作的时候，不经意间注意到X-Ways提示框弹出了Archive bomb的相关提示，内容大致如下：

仔细回想，貌似前几天就出现过类似的提示，只是太忙直接忽略了。

Archive bomb是什么？根据经验，推测是X-Ways遇到了处理不了的文件。个人猜测应该是这个压缩包里面有逻辑错误，导致软件无法解析。什么错误会被称为“bomb”呢？好奇心让我忍不住打开谷歌一探究竟，结果发现挺有意思的。以下内容部分来自维基百科等网站。

Archive bomb是指让解压软件（或其他处理软件）处理时会崩溃或无法正常处理的压缩包，大致原理是这类文件解压需要极大的资源（例如时间、磁盘空间或内容）。早期压缩包炸弹被用来过隐藏恶意代码，杀毒扫描时会崩溃或自动跳过检查。

一个比较经典的Archive bomb是“42.zip”，该文件仅42KB大小，但打开后发现里面又有16个压缩包，继续打开任意一个压缩包，会发现里面又有16个压缩包……，一共有5层嵌套，最终的压缩包里面是一个4.3G的压缩包。

那么这个42.zip完全解压有多大呢？最内层，4.3G×16=68GB；到倒数第二层，68G×16=1TB；到倒数第三层，16GB×16=17TB；到倒数第四层，17TB×16=281TB；到第五层（最外层），281×16=4.5PB。一个小小的压缩包，处理起来估计没有哪台电脑的内存或硬盘够用。

上面这个文件可以从网站“42.zip”（域名https://unforgettable.dk/）下载得到，解压密码为42。压缩包炸弹除了42.zip，还有很多，大家可以网上搜搜看。

这个例子让我再次意识到取证工作中人才是最重要的，软件不是万能的，如果条件允许最好使用多种工具进行交叉验证，必要的话，直接手工分析！据我了解，对于这种压缩包炸弹，X-Ways会弹出提示，而其他大部分无法解析却没有任何警示信息！