Microsoft -Windows -Partition/ Diagnostic是Windows10新引入的事件日志之一，具体位置一般为“C：\Windows\ System32\ winevt\ Logs\ Microsoft - Windows - Partition\ %4 Diagnostic.evtx”。Matt Graeber在2017年10月指出了此事件日志中包含的一些数据［注1］，Harlan随后进一步做了跟进［注2］，但是并没有太多新的信息，特别是如何在USB设备取证调查中使用这一事件日志。

背景

Windows10引入的Partition/ Diagnostic事件日志，会在USB设备连接或断开连接的时候创建一个ID为1006的事件记录。当使用Windows事件查看器查看时，默认的“常规”视图并没有实际的帮助，但是“详细信息”视图包含很多与连接设备相关的信息。遗憾的是，这个事件日志文件会在Windows重要更新中被清除掉，所以如果最近有大版本更新，则可能该日志文件中没有记录。然而，现存的记录可以提供关于特定设备的大量信息，包括设备标识符、连接时间、断开连接时间、设备卷引导记录（VBR）、设备主引导记录（MBR）等。

图 1 ID为1006的事件中包含的设备信息

设备卷引导记录

Partition/ Diagnostic事件日志中ID为1006的记录中有一区域记录有连接系统的设备的卷引导记录（VBR），此设备包括该设备的整个VBR的十六进制内容。这在USB取证中很重要，因为VBR包含很多信息，例如卷序列号。另外，如果设备文件系统为FAT，则VBR中还包含卷标信息。

正如大家所知道的，LNK文件和跳转列表（Jump List）中都包含有卷序列号（VSN），而VSN可以反映一个特定的设备，所以非常关键。注册表Hive SOFTWARE的EMDMgmt子键可能包含连接设备的VSN，但这个子健在有些情况下并未生成，例如当Windows检测到接入的是一个固态硬盘。由于SSD的普及，EMDMgmt子健的用处正在下降。好消息是，尽管EMDMgmt子键越来越少见，但我们依然可以从Partition/Diagnostic 事件日志中获取到卷序列号。

图 2 ID为1006的事件中的卷序列号

通过将VBR0字段(见图2所示)的值保存到一个新文件中，我们可以使用任何能够解析原始VBR的十六进制编辑器或工具来从VBR中获取VSN、卷标及其他有用信息。另一个选择是直接使用USB设备取证工具来处理所有这些信息的提取及解析。

在Partition/ Diagnostic事件日志中发现的信息本身是有用的，但是当与其他与USB相关的数据(如其他事件日志、注册表组和setupapi日志)相关联时，它会变得更加强大。除了设备卷引导记录之外，还有其他一些有用的信息可以从Partition/ Diagnostic 事件日志中获取。

注1: https://twitter.com/mattifestation/status/916338889840721920
注2: http://windowsir.blogspot.com/2017/10/stuff.html

说明

本文翻译自Digital Forensics Stream博客，作者JASON HALE，原题为“USB Device Tracking using the Partition/ Diagnostic Event Log”，略有删改，原文地址https://df-stream.com/2018/05/partition-diagnostic-event-log-and-usb-device-tracking-p1/

截至2018年5月，市面上绝大多数取证设备仍不支持解析本文提到的USB痕迹。另一方面，USB使用痕迹遍布注册表、系统日志、事件日志，从XP到Vista到7，到8，再到10，每次Windows的大版本升级，都引入了新的位置保存，更多的USB取证知识，还需要取证调查人员不断学习，使用不同的工具对比。

本文2018年5月30日发布在微信公众号“取证杂谈”。

目前针对手机微信数据恢复，已经有较为成熟的方法，商业的手机取证工具一般都能不同程度地支持。本文将以Android微信为例探讨判断微信聊天记录是否被删除过的方法，这一方法也可以用于检验取证工具恢复的聊天记录是否完整。

Android微信默认路径为data分区下的“data\com.tencent.mm\MicroMsg”目录，用户及应用产生的大部分数据都在此目录下，但用户产生的多媒体数据则保存在SDCard分区的“tencent\MicroMsg”目录下。在以上路径下，每个登录的帐号会产生一个以某MD5值（该值也和微信账号有关系，详情网上可以搜到）命名的文件夹，聊天记录、朋友圈信息、收藏记录全部位于各账号MD5值目录下。

Android微信聊天记录保存在数据库文件“EnMicroMsg.db”中，收藏信息保存在数据库文件“enFavorite.db”，朋友圈信息保存在数据库文件“SnsMicroMsg.db”中。“EnMicroMsg.db”和“enFavorite.db”都是加密的，密钥为（手机IMEI+微信uin）取MD5值后截取前7位，详细资料可以从网上搜到。

有了以上基础，可能大家会想到，既然是加密后的SQLite数据库，又知道加密规则，解密后直接进行SQLite数据库恢复不就可以了吗？实际情况还真没有这么简单，如何找到解密参数是第一个问题（本文暂不讨论），从Android微信5.3.1版本开始，删除操作使用了特殊的指令，通俗地说就是删除后在原记录处使用“0”进行填充。像短信、通讯录一样使用SQLite数据库原理对Android微信聊天记录进行恢复是行不通的。

下面进入正题。

将“EnMicroMsg.db”文件解密后，可以发现聊天记录保存在表“message”中。主要字段有“msgId”、 “status”、 “isSend”、 “createTime”、 “talker”、 “content”等。如图1所示。

图 1

“status”记录了消息阅读状态，“isSend”记录了消息是发送还是接收的，“createTime”记录了消息时间，“talker”记录了消息的创建者（如果是群消息，则是群聊ID，具体消息创建者标示在“content”字段内），“content”记录了消息的详细内容。

本文的主角是“msgId”字段。该字段记录的是消息在本地的序号，该序号是自增长的，正常情况下，所有对话中，时间上相邻的两条记录“msgId”字段值必定是相邻的。所有记录按“msgId”字段排序后，如果发现有相邻的记录“msgId”字段值不连续，则说明此处有记录被删除了，具体删除的条数也可以判断出来。

图 2

我们再观察一下上面的截图。按“msgId”字段排序后，第11786条记录的“msgId”字段值为11822，而第11787条记录的“msgId”字段值为11824，由此可以推断，这两条记录之间本还有一条记录。第11786条记录的“createTime”字段值“1495527020001”转换成可视化时间为2017-05-23 16:10:20 （UTC+08:00），第11787条记录的“createTime”字段值1495527161000转换成可视化时间为2017-05-23 16:12:41 （UTC+08:00）。即在本例中，2017年5月23日16:10:20之间有一条聊天记录被删除。

总结及说明：

1. 可以通过“EnMicroMsg.db”表“message”的“msgId”字段值来判断是否有聊天记录被删除。
2. 本文介绍的方法无法判断被删除记录的创建者和接收对象，也无法判断被删除的具体内容。
3. 本文讨论的“删除”操作不包括“撤销”，撤销的消息记录还在，只是“content”字段值被改成了“‘xxx’撤回了一条消息”。

本文最早发布于本人微信公众号“取证杂谈”，发布日期为2017年7月9日。

微信在即时通讯工具中所占的份额越来越大，取证实践中已经逐渐取代QQ成为最重要的取证项。对于手机端，目前国内外手机取证工具都能很好地解析，但对于PC端的微信，则只有取证大师等少量的产品支持。

Windows PC安装后，默认会在“我的文档”目录下创建“WeChat Files”文件夹，后续每登陆一个微信账号，便在该文件夹下创建一个以微信号命名的子文件夹，放置配置信息、聊天记录及附件数据。

取证大师解析Windows PC端微信数据需要同账号的微信在手机上进行授权操作，流程比手机微信取证要麻烦得多。知道登陆过的微信号后，如何通过相关信息找到对应的手机呢？其实我们可以通过人工分析上述微信号文件夹中的数据得到。

下面我以自己的微信进行说明。我在我的一台WIndows10系统中安装了最新版的微信，扫描二维码登陆了我的微信号“cnhbhz”。之后通过FTK Imager加载本地磁盘查看，“C:Users cnhbhz Documents WeChat Files cnhbhz config accinfo.dat”文件即保存了我的微信账号信息。该文件主要内容明文可见，如图1所示。

图 1 微信号信息

接下来可以看到我的区域信息，本例中“Hubei Xiaogan”即“湖北省孝感市”。如图2所示。

图 2 地区信息

接下来是签名信息，本例中是“Less is more！”。如图3所示。

图 3 签名信息

接下来是头像信息，本例中有两个，前一个是大图，后一个是小图。如图4、图5所示。复制URL到浏览器中打开即可查看头像信息。

图 4 头像（大图）

图 5 头像（小图）

接下来是邮箱信息，本例是“cnhbhz@xxxxxxx.com”。如图6所示。

图 6 邮箱信息

接下来是绑定的手机号信息，本例中是“1592xxxxxxx”。如图7所示。

图 7 绑定的手机号

以上我使用自己的账号登陆Windows微信后查看的accinfo.dat文件情况，实际上并非每个微信账号都有这些数据，要看该账号具体绑定了哪些信息。另一方便，我并未解析该文件的详细结构，这些事情留给取证公司吧，相信PC微信实际上远不止保存了这些信息。

本文最早发布于本人微信公众号“取证杂谈”，发布日期为2017年6月26日，微信公众号“电子物证”2017年7月21日授权转载。

手机取证中，手机号是确定手机机主的重要途径，同时也可以在众多检材或线索中起串联作用，其重要性不言而喻。确定手机号的一个重要途径是通过SIM卡，SIM卡中可能记录有手机号，通过SIM卡的ICCID也可以从运营商查询得到对应的手机号。

实践中机主可能更换过手机号，所以仅对手机附带的SIM卡进行取证可能还不够。本文将介绍Android及iOS设备中检验历史SIM卡信息的方法。

iOS设备

使用iTunes或其他工具创建手机备份，使用iBackupBot等工具浏览备份数据。SIM卡历史记录记录保存在”WirelessDomain /Library /Database /CellularUsage.db"文件中。

CellularUsage.db是SQLite数据库文件，可以使用免费的DB Browser for SQLite或iBackupBot自带的查看器查看，SIM卡历史记录保存在表“subscriber_info”中。如图1所示。

图 1 CellularUsage.db文件中记录的SIM卡历史信息

subscriber_info字段即SIM卡的ICCID，subscriber_mdn字段即手机号，last_update_time字段即最后更新时间，为MAC Absolute Time时间格式。MAC Absolute Time时间记录的是2001年1月1日 00:00:00 UTC+0:00至今流逝的秒数，可以用免费的工具DCode进行转换。如图2所示。

图 2 使用DCode解析MAC Absolute Time格式的时间

需要注意的是，last_update_time字段记录的最后更新时间与手机系统时间相关，如果手机时间不准，会影响此处的最后更新时间。图1所示的第二条记录中，“-978306735.184363”经过转换为1970年1月1日，显然是错误的时间。如图3所示。

图 3 CellularUsage.db文件中记录的错误的时间

Android设备

Android手机的SIM卡使用记录一般保存在data分区的“data \com .android .providers .telephony \databases \telephony.db”文件中,该文件也是SQLite数据库。表“sim_info”会记录使用过的SIM卡的ICCID、手机号等信息。如图4所示。

图 4 telephony.db文件中记录的SIM卡历史信息

对于小米手机，SIM卡信息还在“data \com .android .providers .telephony \databases \siminfo.db”文件中。如图5所示。

图 5 siminfo.db文件中记录的SIM卡历史信息

注意事项

上面分别介绍了iOS和Android设备提取SIM卡历史记录的方法，其中iOS设备不需要越狱，只要能创建iTunes备份即可；对于Android设备，由于相关信息保存在data分区，普通权限无法访问相关数据，一般需要root或制作镜像后才能进行分析。

SQLite数据库数据恢复技术是手机取证的基石之一，无论iOS还是Android，SIM历史记录都保存在SQLite数据库中，我们可以使用取证软件对上述文件进行处理，以获取删除的记录。本人在实践中也曾成功恢复出SIM卡历史记录。

本文最早发布于本人微信公众号“取证杂谈”，发布日期为2017年6月14日。
写这篇文章的时候，国内外很多手机取证产品对手机号取证还不支持或支持的不完善，一年后的今天，国内手机取证产品已经都支持的比较好了。