IMEI号，普通人可能感觉陌生，但对于电子数据取证从业者来说则不然。IMEI是手机的“身份证号”之一，在通信网络中用于唯一识别某台设备。网上传言的通过某个代码即可通过运营商对手机进行挂失，这个“代码”就是IMEI号。但准确来说，IMEI并不是“设备身份证号”，更像是SIM卡卡槽的身份证号。早期一部手机一般只有一个IMEI号，但为了满足监管需求，差不多十年前开始，设备厂商必须为每个SIM卡卡槽注册一个IMEI号。

今天不聊IMEI号的历史，而是站在一个电子数据鉴定人的角度记录一下最近遇到的一件与IMEI相关的有意思的事情。

大模型的兴起，让普通人也能从科技的发展中受益，我也不例外。为了加快文书材料的校对，我在本地用LM Studio加载了Qwen 3.6 Flash对文档进行自动化核验。最近我在提示词中增加了一条规则，要求对文档中提及的IMEI号检查，看是否为十五位数字并通过Luhn算法校验，希望通过此检查发现潜在的IMEI号记录错误。

这种方法极大地提高了校对效率，类似少录或多录入了一位数、数字录入错误等问题可以很方便地检查出来，比人工核对快很多。但这两天遇到一个IMEI号，Qwen检查说校验失败IMEI非法，但我仔细核对了检材手机，待检查的IMEI号与手机中记录的IMEI号完全一致。于是我又用Qwen写了一个Luhn校验脚本进行计算，结果依然是校验不通过！这部手机是国内很常见的品牌，型号就不说了，去年年中才发布。

按照规范，IMEI号的最后一位应通过Luhn算法计算得出，但实践中似乎并非所有IMEI号都能通过Luhn校验。至于原因，目前尚无明确结论，留待后续探究。

附：Luhn算法规则

Luhn算法也被称为模10算法，主要用来校验各种数字的正确性。Luhn算法规则很简单，对数字从右往左逐一遍历，奇数位不变，将偶数位的数字乘以2，如果乘积大于9则减9，将各位求和后加上校验位数字一定能被10整除，不能整除则说明校验失败。

例如针对IMEI号865498078589991，从右往左第1位到第15位分别是1、9、9、9、8、5、8、7、0、8、9、4、5、8、6，偶数位处理后15个数字分别是1、9、9、9、8、1、8、5、0、7、9、8、5、3、8，(1+9+9+9+8+1+8+5+0+7+9+8+5+3+8)%10= 0，即校验位通过。

大约是2017年，又一件重案的分析任务落到我头上。检材是一块台式电脑硬盘和一块移动硬盘，需要提取或检验其中的特定内容。制作完镜像后，使用取证软件加载，发现台式电脑硬盘第二分区有Bitlocker加密，移动硬盘也有Bitlocker加密。于是打电话和办案单位沟通，可是对方表示嫌疑人不愿意交代密码等任何相关信息。

Bitlocker是Windows平台下常用分区加密方案，高效而安全。我自己十年前就开始使用Bitlocker加密移动硬盘了，那时候大部分同学还在使用Windows XP系统，需要使用Bitlocker To Go才能打开我Bitlocker加密后的移动硬盘。

打开Bitlocker分区主要有两种方式，一种是通过密码，一种是通过恢复密钥。恢复密钥是创建Bitlocker加密分区时提醒备份或打印的一串8组共48位的字符串。保存的恢复密钥文件默认是txt格式，其中的文字有一定规律，可以被取证软件用来检索恢复密钥。

使用取证软件的恢复密钥搜索功能对硬盘镜像进行全盘搜索后，果然在未分配空间找到了一个恢复密钥。使用该恢复密钥尝试解密Bitlocker分区，移动硬盘镜像中的加密分区成功被解密。经检验，里面果然有委托方需要的数据。

硬盘镜像中的Bitlocker分区就没有这么幸运了，只能另外想其他的办法。

山穷水尽疑无路，柳暗花明又一村。当我使用委托方提供的关键词，尝试对硬盘镜像中未加密的系统分区进行搜索，意外发现在一个名为“Everything.db”的文件中有大量命中记录。里面不仅有文件名，还有文件的完整路径！没错，这就是大名鼎鼎的文件搜索工具Everything的索引数据库。经过其他方式综合关联分析，确定了其中一些记录就是未解密的Bitlocker分区中的文件。委托方最终对结果非常满意！

Everything是一款高效的文件搜索工具，我自己也已使用多年，100万的文件在一两秒就可以创建完索引然后快速搜索。我计算机上千万级别的文件，基本也只有Everything能够进行管理和搜索了。我经常在想，如果Everything的快速搜索技术如果能应用到取证软件中就太好了。

Everything的索引数据库保存路径为“C:\Users\<用户名>\AppData\Local\Everything\Everything.db”，如果电脑上有多个用户，就会有多个Everything.db文件。看文件头，该文件像是ESE数据库，但是根据Everything官方描述，该文件可能会使用BZIP算法进行压缩，所以直接搜索并不是永远都会起作用。在写这篇文章的时候，意外的发现Everything官方提供了Everything.db的转换工具，可以直接将Everything.db转换成EFU格式，该格式是Everything创建的文件列表文件，实际就是CSV格式，可以用记事本等任意文本编辑器打开查看。

另外，在写本篇文章的时候，我还发现了Everything的另外一个痕迹——文件打开记录。忘记了从哪个版本开始，Everything支持记住每个搜索结果的打开次数以优化结果排序。Everything文件打开记录位于“C：\Users\<用户名>\AppData\Roaming\Everything\”下，文件名有“Run History.csv”、“Run History.csv.tmp”，其中的“Last Run Date”字段时间戳格式为Google Chrome Value格式，可以用DCode工具进行解码。

2020年6月27日发布于本博客及微信公众号“取证杂谈”、“神探学院”。

2018年年中的一天，一个律师打来电话，咨询我电子数据鉴定的事情，说要鉴定一个AI文件。刚听到时我懵了一下，人工智能鉴定？但马上反应过来应该是AI格式文件（Adobe Illustrator默认的文件格式）的鉴定。我问对方，是设计图纸吗？对方连连点头，是的是的，是一个商标的设计图。

原来，对方想鉴定一个AI格式文件的创建时间。对方当事人在一个官司中涉及一个商标的纠纷，该当事人声称十年前自己就设计了该商标图，现在想鉴定以证明该事实。经了解，该文件这些年经过多次修改、复制，已经找不到原始设计的版本和当时的电脑。我向对方解释道，这种情况已经无法从文件系统相关痕迹判断文件的创建时间了，但可以尝试一下其他方式，当然，不保证成功，对方表示愿意让我尝试。

我所说的尝试其他方法，是指看元数据中是否有创建时间的相关线索。所谓“元数据”，就是“数据的数据”。例如jpg图片中可能包含拍摄日期、拍摄时的经纬度等信息，Office文档中可能创建者及相关信息，Adobe系列软件创建的文件中一般也包含大量的元数据。

挂完电话，我便下载了Adobe Illustrator试用版，分析了几个AI格式的文件。果然，AI文件中包含文件创建时间、文件修改历史等详细信息。使用Adobe Illustrator打开AI文件后，点击“文件(F)”，然后选择“文件信息(I)...”即可查看这些信息。如下图所示。

经过上述测试，我联系了对方，表示可以尝试从文件中尝试提取文件创建时间，但如果鉴定的话仅能如是描述，无法对文件真实的创建时间下结论。对方表示没问题，只要描述该时间即可，随后发给了我一个AI格式的文件。

使用元数据处理工具ExifTool处理该文件，得到的信息如下图所示。

文件内部记录的创建时间为2008-08-21 00:09:54+08:00，修改时间和元数据时间均为2008-08-21 00:17:39+08:00，记录的修改时间只有一次，亦为2008:08:21 00:09:54+08:00。从数据上看，没什么异常。但潜意识里总觉得好像哪里不对劲。

这个设计图还挺复杂的，但按照元数据中记录的，文件只修改了一次？且创建时间和修改时间仅相差8分钟？当然了，这些都是最基础的的疑问，没有具体证据支撑的只能停留在猜想怀疑阶段。我盯着ExifTool展示的结果，陷入了沉思。

突然，有了新思路。我飞快地打开了浏览器，进入百度，键入了一串字符……之后，我再次拔通了那个律师的电话。你们确定文件是十年前创建的吗？对方非常肯定，说，是的，2008年创建的！于是我告诉对方，这个文件中显示的创建时间确实是2008年，但这个时间是假的。对方听到前半句话的时候很满意，听到后半句话后，非常诧异，沉默了片刻后再三追问我原因。

我说，虽然你们这个文件中记录着文件创建时间为2018年，但文件中同时记录着当时的创建工具是Adobe Illustrator CS5。而Adobe Illustrator CS5在2010年才发布。

后来，该律师放弃了鉴定委托。

其实国外也有类似案例。2017年的巴基斯坦“巴拿马文件泄密案”中，一份2006年2月的文档中使用了Calibri字体。Calibri字体首次出现在2004年的Windows Vista测试版中，首次在2006年5月23日发布的Office 2007的Beta 2版本中可用该字体和其他ClearType字体集最终于2007年1月30日向公众发布。调查人员根据这一发现索确定该文件是伪造的，这一点是案件的关键线索。该案件目前在谷歌中还能搜索到。

这个真实案例并未设计多么复杂的取证原理，但还是让我印象非常深刻。其实这里案例中的判断方法非常常见。真实性判定的鉴定中，大部分鉴定，基本方法都是判断是否存在异常，发现异常下结论非真实，没发现异常根据实际情况下结论未发现异常。

电子取证中，为了防止检材污染，工作时中进行写保护是非常必要的。司法部《关于印发<司法鉴定机构仪器设备配置标准>的通知》（司发通[2011]323号）规定电子数据鉴定中只读接口是必备设备，录音资料鉴定中只读接口是选配设备。

不过在紧急情况下，“软只读”可以发挥一定的作用。软只读指的是通过软件的方式禁止向目标设备写入数据。从Windows XP SP2开始，通过修改注册表中的键值达到禁止向USB设备写入数据的目的。具体起作用的为注册表“HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies”的“WriteProtect”的键值，键值为“0”则USB设备为读写状态，键值为“1”则USB设备为只读状态。网上的一些USB写保护小工具（例如USB WriteProtector），基本都是基于这一原理。

下图是使用Process Monitor检测USB写保护工具USB WriteProtector设置写保护这一过程的所有操作，由于篇幅所限，这里只截取了具体的操作详情。

但同时，我发现这工具运行的时候貌似有些“不老实”，过一段时间就多C盘中某个文件进行操作。暂时不知其原因。

其实，我们完全可以自己设置。下面是具体方法。

设置只读：在记事本中粘贴下列内容，保存为“DisableUSBWrite.reg”（注意不要保存成了“DisableUSBWrite.txt”），其实文件名无所谓，但后缀一定要为“reg”。双击保存的文件，即可导入注册表。

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000001

同理，取消只读只需在记事本中粘贴下列内容并保存成“EnableUSBWrite.reg”并双击导入即可。

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies]
"WriteProtect"=dword:00000000

上面两段内容保存后图标如下，如果不是，很可能格式保存错了

双击导入的时候会出现下图所示的提示，直接点“是”就可以了。

设置完后，接上优盘，在优盘中空白处右击，会发现熟悉的“新建”菜单不见了。

当试图从其他位置复制文件到优盘中时，会有写保护提示。

就连对优盘进行重命名都会报错。

演示完了，说几点需要注意的地方。

1.注册表设置后，仅对之后接入的设备有效，例如之前是只读状态，连接着一个优盘，设置读写后，此优盘依然只只读的，重新拔插一次才能恢复对此设备的读写。

2.除了对优盘、移动硬盘等“移动设备”有效，对SATA转USB的硬盘依然有效。

3.一般情况下，设置USB只读或USB读写后，重启后之前的设定依然有效，但是偶尔遇到“不一般的情况”，之前的设定有可能有效可能无效。

下面来解释一下上面的第三条。注册表“HKEY_LOCAL_MACHINE\SYSTEM\”下面一般会有名为“CurrentControlSet”、“ControlSet001”、“ControlSet002”的子目录，这些地方保存着一些系统配置信息。其中“CurrentControlSet”是当前的配置信息，一般与“ControlSet001”内容一致，“ControlSet002”是每次成功启动电脑后从“ControlSet001”中复制的备份，也就是Windows系统启动时按F8进入安全模式看到的“最后一次正确配置”。一般情况下，开机后“CurrentControlSet”都是从“ControlSet001”复制数据，由于某种原因，如果系统启动的时候不是从“CurrentControlSet”数据不是从“ControlSet001”复制的，就有可能造成上次设置失效。

注册表“HKEY_LOCAL_MACHINE\SYSTEM\Select”中记录了当前（Current）、下次（Default）、最后一次正确（LastKnowGood）的配置。

我想不少人看了以上内容一定惊喜不已——以后花几十块钱买个SATA转USB的线材，就可以和只读锁说拜拜了？淘宝上只读锁老贵老贵呢。

这种方法可不可行呢？我们接下来继续看。

我在有个优盘中新建了一个名为“TEST.txt”的文件，内容为“www.cnforensics.com取证中国”。

![图10[10]

将优盘拔出，设置后USB只读后，重新接入优盘，打开重新编辑后按Ctrl+S保存，报错。

使用WinHex打开优盘，编辑“TEST.txt”，将第一个字母“ｗ”改成“Ａ”并保存。

点击“确定”

点击“是”，居然没有报错提示，赶紧从资源管理器中打开优盘看看——内容已修改……

显然，我们修改注册表后的“只读”并没有阻止住WinHex对优盘的写入操作。对于一些使用较低层的方式对磁盘进行的操作，软只读无法无能为力，所以，购买物理只读设备还是很有必要的。当然，特殊情况下，软只读总比直接读写好。

本文最早发布于微信公众号“取证杂谈”及取证中国论坛，发布日期为2016年1月3日，其他网站及平台均为未授权转载。