数据恢复永远是电子数据取证中最重要的内容之一。每当客户问我：胡工，能帮忙恢复一下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会弹出提示，而其他大部分无法解析却没有任何警示信息！

电子数据取证工作中，加载、查看镜像文件数据是非常高频的需求，也是取证软件最基础最功能，但这并不意味着每个取证软件都能把这一功能做到极致。

大部分取证软件加载镜像需要比较长的时间。国内的取证软件，一般需要先新建案例后添加镜像，完成文件系统解析才能浏览其中的数据。个人一直不习惯这一逻辑，因为每天要加载查看很多的镜像，但大多数情况下都是临时分析，每次创建案例耗时容易打断思路，而且软件启动后看到一堆无用的案例对于我这种有强迫症的人来说看着非常不舒服。

免费的EnCase Imager查看镜像倒是不需要新建案例，双击打开EnCase Imager后，点击“Add Evidence File”或“Add Raw Image”即可添加镜像文件。但和EnCase一样，EnCase Imager让我无法忍受的是文件系统解析实在太慢了，一个NTFS分区MFT解析动辄几十秒甚至几分钟。

免费的FTK Imager同样打开软件后就可以直接加载镜像文件了，速度也比EnCase Imager及其他取证软件快不少。FTK Imager加载镜像文件后，并没有马上解析文件系统中的所有文件，当用户展开某个文件夹时，FTK Imager才去解析该文件夹下的文件记录，这一特性使得FTK Imager加载镜像文件速度远超其他软件。

虽然FTK Imager不需要创建案例就可以直接加载镜像文件，而且解析文件的速度也很快，但打开FTK Imager→点击加载镜像按钮→浏览选择镜像→点击完成→开始浏览数据这一整套浏览流程下来对我来说还是太慢了。有没更快的工具呢？答案是肯定的，X-Ways Forensics堪当此任！

设置“显示更多右键菜单功能（Items in Windows context menu）”后，在资源管理器中右击任意文件或文件夹，都会出现“打开X-Ways Forensics”的菜单。如果选中的是任意镜像文件（例如E01、dd、vmdk等），选择“打开X-Ways Forensics”后会自动打开X-Ways并加载该镜像文件，一气呵成，速度飞快！（注意X-Ways靠拓展名识别镜像，如果不是dd、E01、vmdk等常规拓展名，会按普通文件处理，及打开后显示文件十六进制数据。）对镜像进行分析后，如果觉得有必要，也可以随时将当前镜像或镜像中的某分区添加到当前活动案例或新建案例中。

那么，有么有操作同样简单最好还免费的工具呢？还真有！今天就给大家介绍一个低配版的工具——7-Zip。没错，就是开源的解压缩工具7-Zip！

直接看官网，7-Zip声称支持DMG、EXT、GPT、HFS、ISO、NTFS、QCOW、2、SquashFS、UDF、UEFI、VDI、VHD、VMDK等格式的解压，是不是很强大？上面列出的均为镜像格式或文件系统格式，这哪是解压软件，感觉简直是取证软件了，很多取证软件支持的文件系统还没这全呢！

7-Zip安装完成后，默认会在右键菜单中添加7-Zip相关的菜单选项，例如使用7-Zip打开压缩包。右击镜像文件，即可使用7-Zip打开浏览其中的数据了。

先打开一个阿里云镜像试试看。

这是一个Ext4文件系统的镜像，7-Zip可以完美支持！速度比X-Ways还快那么一丢丢！文件/文件夹的大部分属性都可以正常解析，不仅如此，还可以统计每个文件夹的子文件夹数（下图倒数第二列）、子文件数（下图倒数第一列）、链接数等信息。

再试试今年的能力验证镜像吧，这是一个带LVM的Linux镜像。

可以正常打开！

换一个Windows磁盘镜像试试看，里面有两个NTFS分区。

依然可以正常打开！

再打开一个手机镜像试试看，依然没问题！

看起来功能还是比较强大的，不过竟然说是低配版的工具，其缺点也很明显——只支持RAW镜像（与拓展名无关），而不支持E01等专业的镜像格式。当然了，作为一个解压缩软件，兼职功能做到这程度已经很不错了！

总结一下，7-Zip开源免费，可以识别MBR、GPT分区结果，支持NTFS、FAT、EXT、HFS等文件系统。对于DD镜像（常见拓展名可能有dd、001、bin、raw等），可以直接使用7-Zip快速打开进行文件浏览及数据导出。

电子数据取证中常用序列号来唯一标识检材。在检材的众多属性中，一般只有序列号可以出厂即固定且长期不变，所以理所当然被作为唯一标识信息的首选。但是，序列号真的就永远可以唯一标识一个检材？

一个案件中，被告对鉴定意见书中提到的优盘提出了质疑，称鉴定的优盘并不是他的优盘，因为序列号对不上。原来嫌疑人对电子数码比较感兴趣，平时有对优盘进行各种折腾操作的经历，正好对其优盘的序列号有印象。嫌疑人后来甚至还找到了一张以前的电脑截图，截图里是小工具USBTreeView的运行截图，里面可以看到优盘的序列号，确实与鉴定意见书中记录的不一致。

一番扯皮后，法院决定对有异议的优盘进行重新鉴定。鉴定人按照第一份鉴定意见书中提到的步骤，使用取证大师对优盘序列号进行获取，得到的结果和第一份鉴定意见书中的一致。使用FTK Imager进行检验，结果也一样。难道嫌疑人在说谎？但使用嫌疑人提到的工具USBTreeView查看，还真的可以看到另外一个序列号。

这一切到底怎么回事？为什么这么多取证软件在这里翻车？其实，这里的坑，会让不少取证软件都翻车，而且肯定已经翻车无数次了，只是没有被人注意到。

这一现象很容易复现。

下面一个朗科的优盘，本人之前常用的型号。

用取证大师加载优盘直接看，序列号为AA00000000000489。
​

用FTK Imager加载查看，序列号依然为AA00000000000489。

使用EnCase Imager查看，序列号却为AA00000000007275。

使用USB Tree View查看，序列号也为AA00000000007275。

在资源管理器中右击优盘，选择“属性”，然后依次点击“硬件”、“属性”，“详细信息”，然后在“属性”中选择“父系”，也可以看到和EnCase Imager中一致的AA00000000007275。

其实，造成这种情况的原因是Windows中使用不同方法获取优盘序列号，确实可能得到不同的结果。本人经过一番测试，通过PowerShell分别获取到了这两种序列号。

使用命令Get-WmiObject Win32_PhysicalMedia可以获取到序列号AA00000000000489。

使用命令Get-Wmiobject Win32_USBControllerDevice可以获取到序列号AA00000000007275。

其实，如果使用X-Ways，这两种序列号都可以获取到。新建案例加载优盘后，右击属性，即可在案件描述中看到这两个序列号。

一入取证深似海！