电子取证课外作业
一、知识点总结
1.1 磁盘镜像与取证挂载
电子取证中通常不会直接操作原始磁盘,而是先制作 RAW、E01 等格式的镜像文件,再对副本进行分析。挂载镜像时应尽量采用只读或临时可写方式,防止修改原始检材。
部分镜像还可以转换为 VMDK 等虚拟磁盘格式,在隔离的虚拟机中恢复原系统环境。这样既可以进行静态文件分析,也可以观察原有软件、账户和系统配置。
1.2 Windows 注册表与用户痕迹
Windows 注册表保存了大量系统和用户活动信息,是电子取证中的重要数据来源。例如,SAM 中保存本地账户信息,UserAssist 可以反映部分图形界面程序的运行记录,系统注册表还可能保存软件配置、产品信息和历史使用痕迹。
取证时应结合文件路径、注册表、程序日志和时间线进行分析,而不是只根据某一个字段判断用户行为。
1.3 邮件、文档与文件元数据取证
邮件客户端通常会在本地保存账户目录、邮件索引、邮件正文和附件。即使客户端无法直接加载原账户,也可以通过分析其存储目录和索引文件恢复邮件线索。
文档本身还可能保存作者、创建时间、修改时间等元数据。这些信息可以辅助判断文件来源和使用过程,但索引文件或自动解析结果只能作为线索,最终应尽量回到原始邮件头、原始附件或文件属性中进行验证。
1.4 日志与时间线分析
日志和时间线是还原用户行为的重要依据。软件日志可能记录程序启动、安装、远程连接、登录和异常事件,时间线则可以将文件、注册表和程序活动按照时间顺序关联起来。
分析时需要特别注意时区问题。部分取证工具输出的是 UTC 时间,而题目或实际事件可能采用北京时间,因此必须先确认时间基准,再进行统一换算。对于远程控制等行为,还可以根据日志中的开始时间和结束时间计算实际持续时间,从而进一步还原事件过程。
二、JIAJIA 的 PC
2.1 PC1
1. 佳佳的电脑用户名叫什么(即 C:\Users\{name})?
2. 最后一次运行计算器的时间是什么?
格式为 yyyy-mm-dd_hh:mm:ss,注意冒号为英文冒号。
首先需要确定内存镜像对应的操作系统版本。Volatility 的不同插件通常需要指定正确的系统 Profile,如果 Profile 选择错误,后续解析注册表、文件对象和进程信息时可能无法得到有效结果。
vol.py -f JiaJia_Co.raw imageinfo

图 2-1-1 使用 imageinfo 插件识别内存镜像可能对应的系统版本。
分析结果中给出了多个候选 Profile,其中包括 Win7SP1x64。结合镜像环境,后续取证过程统一使用该 Profile,即把镜像按照 64 位 Windows 7 SP1 系统进行解析。
接下来使用 filescan 扫描内存中的文件对象,并筛选路径中包含 Users 的记录,尝试从用户目录结构中寻找用户名线索。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 filescan | grep "Users"

图 2-1-2 filescan 输出中包含 Users 路径的文件对象记录。
文件路径可以帮助判断系统中出现过哪些用户目录,但为了进一步确认本地账户名称,还可以检查 SAM 注册表中的账户记录。
Windows 会在 SAM 注册表配置单元中保存本地用户账户信息,其中:
SAM\Domains\Account\Users\Names
路径下的子项与本地账户名称相对应。使用 printkey 插件读取该位置:
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 printkey -K "SAM\Domains\Account\Users\Names"

图 2-1-3 printkey 插件读取 SAM 注册表中的本地用户名称记录。
结合用户目录路径与 SAM 中的账户名称,可以确认佳佳的电脑用户名为:
JiaJia
第二个问题要求确定最后一次运行计算器的时间。这里先使用 timeliner 插件整合内存中能够解析出的时间信息,再筛选与 calc.exe 有关的记录。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 timeliner | grep "calc.exe"

图 2-1-4 timeliner 输出中与 calc.exe 相关的时间记录。
timeliner 输出的时间为 UTC 时间,而题目需要提交北京时间。北京时间采用 UTC+8,因此需要在原始时间的基础上增加 8 小时。
换算后,计算器最后一次运行时间为:
2021-12-10_20:15:47
为了避免只依赖单一插件得出结论,还可以使用 userassist 进行交叉验证。UserAssist 注册表记录通常用于保存通过资源管理器、开始菜单或快捷方式启动程序的相关信息,因此能够辅助判断用户运行过哪些图形界面程序。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 userassist

图 2-1-5 userassist 插件输出的用户程序运行记录。
两种方式得到的线索能够相互印证。按照题目要求,将用户名、下划线和北京时间拼接,得到待计算 MD5 的字符串:
JiaJia_2021-12-10_20:15:47
使用以下命令计算 MD5:
echo -n "JiaJia_2021-12-10_20:15:47" | md5sum
这里必须添加 -n 参数,否则 echo 会在字符串末尾附加换行符,最终计算出的 MD5 将与预期结果不同。

图 2-1-6 使用 md5sum 计算拼接字符串的 MD5 值。
最终提交结果为:
ctfshow{079249e3fc743bc2d0789f224e451ffd}
PC1 中需要特别注意时间时区。取证插件显示的 UTC 时间不能直接作为北京时间提交,否则即使程序名称和用户名判断正确,最终哈希仍然会出错。
2.2 PC2
1. 佳佳在公司使用了一款聊天软件,请问此软件的版本号为?
2. 佳佳在网页上登录了自己的邮箱,请问佳佳的邮箱是?
首先继续使用 filescan 扫描文件对象,并筛选桌面目录中的相关文件。桌面上的程序、快捷方式和用户文件通常能够反映用户近期使用的软件。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 filescan | grep "Desktop"

图 2-2-1 filescan 输出中包含 Desktop 路径的文件对象记录。
扫描结果中发现了与 TG.exe 有关的文件对象。记录前方的十六进制数值是该文件对象在内存中的偏移地址,可以将其交给 dumpfiles 插件进行提取。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000013fde26a0 -D ./

图 2-2-2 dumpfiles 插件根据文件对象偏移地址导出 TG 相关文件。
Volatility 导出的文件可能使用 .img、.dat 或其他通用扩展名。这并不代表文件原本就是磁盘镜像,而是因为取证工具通常会优先保留原始二进制数据,不一定能够恢复原文件名和扩展名。
检查文件头后,可以确认该文件具备 Windows PE 可执行文件的结构。为了让 Windows 正确识别文件类型,可以将副本的扩展名修改为 .exe,随后通过文件属性读取版本元数据。

图 2-2-3 Windows 文件属性窗口中显示的程序版本信息。
从文件详细信息中可以读取到 TG 的版本号为:
3.3.0.0
第二个问题要求查找佳佳在网页中登录的邮箱。由于邮箱地址很可能直接显示在浏览器窗口中,因此可以使用 screenshot 插件恢复内存中保存的桌面窗口画面。
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 screenshot --dump-dir ./screenshot

图 2-2-4 screenshot 插件执行后生成的桌面窗口截图文件。
screenshot 通常会生成多张窗口图像,其中部分图像可能只包含窗口边框、空白区域或被其他窗口遮挡的内容。因此需要逐张检查,重点关注浏览器窗口、邮箱登录页面和包含账户信息的区域。

图 2-2-5 恢复出的部分窗口画面及其界面内容。
继续检查其余截图后,可以定位到包含浏览器和邮箱账户信息的窗口。

图 2-2-6 恢复出的浏览器窗口中显示了邮箱账户相关信息。
由于截图中的文字较小,可以先放大图片,再使用 QQ 的文字提取功能辅助识别。OCR 结果仍有出现字符误判的可能,因此需要对照原图检查数字、字母和邮箱后缀。

图 2-2-7 文字提取工具识别出的邮箱地址内容。
经过识别和人工核对,佳佳登录的邮箱为:
a2492853776@163.com
按照题目要求,将软件版本号和邮箱地址使用下划线连接:
3.3.0.0_a2492853776@163.com
随后计算 MD5:
echo -n "3.3.0.0_a2492853776@163.com" | md5sum

图 2-2-8 使用 md5sum 计算软件版本号与邮箱拼接字符串的 MD5 值。
PC2 的分析分别利用了文件对象和桌面窗口两类证据。程序版本来自可执行文件的静态元数据,邮箱地址则来自浏览器窗口截图,两者对应的取证方法并不相同。
2.3 PC3
1. 佳佳最后一次运行固定在任务栏的 Google Chrome 的时间是什么?
格式为 yyyy-mm-dd_hh:mm:ss,注意冒号为英文冒号。
2. 佳佳解压了一个从 Chrome 下载的压缩文件,该文件的相关内容信息已经写入环境变量中,请问文件的内容是什么?
首先通过 timeliner 查找与 Chrome 有关的时间记录:
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 timeliner | grep -i "chrome"

图 2-3-1 timeliner 输出中与 Google Chrome 有关的时间记录。
根据时间线结果,可以定位到固定在任务栏中的 Chrome 快捷方式及其相关时间。该时间同样需要从 UTC 转换为北京时间,在原时间基础上增加 8 小时后,得到:
2021-12-10_20:28:43
第二个问题明确说明,压缩文件的内容信息已经被写入环境变量。Windows 进程的环境变量可能包含程序运行参数、临时路径或用户主动设置的字符串,因此可以使用 envars 插件枚举内存中各进程的环境变量。
为了缩小输出范围,这里筛选与常见压缩格式有关的关键字:
vol.py -f JiaJia_Co.raw --profile=Win7SP1x64 envars | grep -iE "zip|rar|7z"

图 2-3-2 envars 输出中与压缩文件相关的环境变量记录。
从环境变量记录中可以提取出压缩文件对应的内容:
Th1s_i5_Ur_P5wd
该字符串使用数字 1 和 5 分别替代了部分字母,计算哈希前需要严格按照原始大小写和字符形式输入,不能自行改写为普通英文单词。
将 Chrome 的北京时间与文件内容使用下划线拼接:
2021-12-10_20:28:43_Th1s_i5_Ur_P5wd
使用以下命令计算 MD5,并通过 awk 仅保留哈希值:
echo -n "2021-12-10_20:28:43_Th1s_i5_Ur_P5wd" | md5sum | awk '{print $1}'

图 2-3-3 计算 Chrome 运行时间与环境变量内容拼接字符串的 MD5 值。
PC3 的难点不只是找到 Chrome 和环境变量,还需要保持字符串完全一致。时间格式、大小写、数字替代字符以及下划线中的任意一处差异,都会导致最终 MD5 完全不同。
三、Jiajia 的 CP
3.0 挂载与登陆
在开始后续取证前,需要先解决检材镜像的挂载和系统登录问题。最初尝试通过ftk直接挂载镜像时一直出现异常,无法稳定访问其中的文件系统。

图 1-1 使用镜像挂载工具加载 E01 检材并分配磁盘分区。
直接挂载没有达到预期效果,因此换一种思路,将原始检材转换为 VMware 可以识别的 VMDK 虚拟磁盘。转换完成后,目录中生成了对应的 VMDK 文件。

图 1-2 检材目录中生成的 RAW、E01 和 VMDK 等文件。
将 VMDK 文件接入虚拟机后,Windows 系统可以正常启动,但进入系统时需要输入用户密码。此时虽然已经恢复了系统运行环境,仍然无法直接登录桌面。

图 1-3 使用转换后的虚拟磁盘启动系统后出现密码登录界面。
为了提取系统中的注册表文件,我又使用 Arsenal Image Mounter 挂载检材。挂载方式选择 Disk device, write temporary,也就是临时可写模式。
这种模式会把写入操作保存到额外的差分文件中,而不是直接修改原始镜像。既能满足部分文件系统的写入需求,也可以尽量避免破坏原始检材。

图 1-4 在 Arsenal Image Mounter 中选择临时可写的磁盘挂载方式。
完成挂载后,可以在资源管理器中看到镜像包含的多个分区。其中,Windows 系统所在分区被分配为 F: 盘,可以正常查看系统目录和用户文件。

图 1-5 挂载完成后在资源管理器中访问检材的 Windows 系统分区。
Windows 本地账户的密码散列存储在 SAM 注册表配置单元中,对应文件路径为:
F:\Windows\System32\config\SAM
实际分析时,还应保留同一目录中的 SYSTEM 配置单元,因为 SAM 中的密码数据需要结合系统启动密钥进行解析。将相关注册表文件复制到分析环境后,再导入 Passware Kit Forensic 进行密码恢复。

图 1-6 Passware Kit Forensic 正在对提取出的 SAM 文件执行密码恢复。
密码恢复的耗时与密码长度、字符集和硬件性能有关。截图中工具启用了 GPU 加速,并通过暴力破解找到了一个长度为 7 的密码。

图 1-7 Passware Kit Forensic 显示当前攻击方式及恢复出的账户密码。
最终恢复出的系统登录密码为:
ljj1226

图 1-7 Passware Kit Forensic 显示当前攻击方式及恢复出的账户密码。
使用该密码即可进入虚拟机中的 Windows 系统,继续完成后续取证。
3.1 CP1
1. 产品密钥是什么?
2. Windows 系统版本号是什么?
进入系统后,首先查找 Windows 产品密钥。按下 Win + R 打开“运行”窗口,输入以下命令启动注册表编辑器:
regedit
在注册表中定位到:
计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform
该路径下的 BackupProductKeyDefault 值保存了系统的备用产品密钥。

图 2-1 在 SoftwareProtectionPlatform 注册表项中查看 BackupProductKeyDefault 的值。
从注册表中读取到的产品密钥为:
YC7N8-G7WR6-9WR4H-6Y2W4-KBT6X
接下来查看 Windows 系统版本。打开 Windows“设置”,进入“系统”页面。

图 2-2 Windows 设置主页面中的系统设置入口。
在“系统”页面左侧选择“关于”,可以查看 Windows 规格、系统类型和操作系统内部版本等信息。

图 2-3 Windows“关于”页面显示的版本、安装日期和系统内部版本信息。
页面中显示该系统为 Windows 10 专业版,题目要求的版本号为:
21H2
按照题目要求,将产品密钥与版本号使用下划线拼接:
YC7N8-G7WR6-9WR4H-6Y2W4-KBT6X_21H2
随后对拼接结果计算 MD5,得到:
769a5b735409a2697086e68df511495f

图 2-4 对产品密钥和 Windows 版本号的拼接字符串计算 MD5。
3.2 CP2
1. 佳佳的 QQ 号是多少?
2. `金额统计.rar` 是由哪个 QQ 号通过邮箱发送来的?
3. 金额统计文档的作者是谁?
在系统盘根目录中发现了 Foxmail 7.2 文件夹,说明佳佳曾经在这台电脑上使用 Foxmail 管理邮件。

图 3-1 系统盘根目录中存在 Foxmail 7.2 程序文件夹。
进入该目录后,可以看到 Foxmail 主程序以及用于保存邮件账户数据的 Storage 文件夹。

图 3-2 Foxmail 目录中的主程序和 Storage 邮件数据目录。
直接启动程序后,Foxmail 显示的是新建账户页面,并没有自动加载原有邮件。这里说明程序本身可以运行,但原账户数据没有被当前配置正确识别。

图 3-3 直接启动 Foxmail 后显示的邮箱账户添加界面。
随后检查 Storage 文件夹,发现其中存在一个以邮箱地址命名的账户目录:
C:\Foxmail 7.2\Storage\2492853776@qq.com

图 3-4 Foxmail 的 Storage 目录中保存了 2492853776@qq.com 账户数据。
QQ 邮箱地址的用户名部分通常就是对应的 QQ 号,因此这里可以确定佳佳的 QQ 号为:
2492853776
继续进入该账户的 Mails 目录,可以看到多个编号文件夹以及 Index、Index.key 等文件。Index 是 Foxmail 使用的邮件索引文件,其中保存了邮件主题、联系人和地址等信息。

图 3-5 Foxmail 账户的 Mails 目录及其中的 Index 邮件索引文件。
直接使用记事本打开 Index 后,大部分内容无法正常显示。这是因为该文件并不是普通文本,而是包含二进制结构的邮件索引数据。不过,从其中仍然能够看到一些未被编码的邮箱地址和邮件主题。

图 3-6 记事本中显示的 Index 二进制数据和部分可读邮箱字符串。
索引中出现了多个邮箱地址,单纯看到地址还不能判断它们分别属于发件人还是收件人。可以借助解析工具或大模型整理可读字符串,但解析结果只能作为辅助线索,仍然需要回到原始邮件中验证。

图 3-7 根据 Index 文件中的可读字段整理出的邮件时间、地址和主题信息。
参考 Foxmail 邮件数据恢复的方法,需要让程序加载现有的账户存储目录。检查 FMStorage 文件后,发现里面是空的,按照搜索到的原理,我往里面了 Foxmail 的邮件数据路径:
C:\Foxmail 7.2\Storage\2492853776@qq.com

图 3-8 FMStorage 文件中记录的 Foxmail 账户数据存储路径。
确认存储路径后,应运行目录中的 Foxmail 主程序。这里需要注意,打开的是邮件客户端 Foxmail,不是浏览器 Firefox,两者名称比较接近,操作时容易看错。

图 3-9 Foxmail 7.2 目录中的邮件客户端主程序。
账户数据加载成功后,在邮件列表中找到主题为“金额统计”和“金额统计-新附件”的邮件。查看发件人信息,可以看到发件人的邮箱地址为:
77602440@qq.com

图 3-10 Foxmail 中“金额统计-新附件”邮件显示的发件人地址。
因此,发送 金额统计.rar 的 QQ 号为:
77602440
最后需要确定金额统计文档的作者。由于虚拟机中缺少能够正常查看表格属性的软件,可以先将附件复制到物理机,再使用 WPS 或其他表格软件打开文件属性。
在文档的“摘要”属性中,可以看到作者字段为:
mumuzi

图 3-11 金额统计表格的文件属性中显示作者为 mumuzi。
CP2 的三个答案为:
佳佳的 QQ 号:2492853776
附件发送者的 QQ 号:77602440
文档作者:mumuzi
邮件索引中的可读字符串只能用于快速定位线索。最终判断发送者时,我还是以 Foxmail 中实际恢复出的邮件头信息为准,这样比只依赖记事本或自动解析结果更可靠。
3.3 CP3
1. 佳佳使用了公司指定的聊天软件,并使用了该软件的远控功能,请问整个远控持续了多少秒?
2. 此软件是什么时候开始安装的?请将时间中的空格替换为下划线。
3. 除开机密码外,佳佳喜欢使用一个通用密码,请找出此密码。
从前面的邮件内容可以看到 TeamViewer 的账户验证邮件,因此这里优先检查 TeamViewer 的程序目录和日志文件。
在以下目录中发现了 TeamViewer:
C:\Program Files\TeamViewer

图 4-1 Program Files 目录中存在 TeamViewer 软件文件夹。
进入 TeamViewer 目录后,发现 Connections_incoming 文件。该文件用于记录传入的远程连接,其中包含远程设备、连接开始时间、结束时间和连接类型等字段。

图 4-2 Connections_incoming 文件中记录的一次 TeamViewer RemoteControl 连接。
该条远程控制记录中的开始时间和结束时间分别为:
开始时间:14:20:52
结束时间:14:23:35
计算持续时间:
14:23:35 - 14:20:52
= 2 分 43 秒
= 163 秒
因此,整个远程控制过程持续了:
163
接下来检查 TeamViewer 的日志文件。在安装目录中找到 TeamViewer15_Logfile,其中第一条日志记录的时间为:
2021/12/14 22:14:14.804

图 4-3 TeamViewer15_Logfile 中记录的首条日志时间和程序启动信息。
日志第一条记录为 Logger started,说明 TeamViewer 的日志组件在该时间开始工作。结合题目要求,可以将这条记录作为软件开始安装或初始化阶段的时间线索。
将日期和时间之间的空格替换为下划线后,答案为:
2021/12/14_22:14:14.804
最后查找佳佳经常使用的通用密码。打开浏览器菜单,进入保存密码的管理页面。

图 4-4 从浏览器菜单进入已保存密码的管理功能。
浏览器中保存了百度和 CTFshow 两组登录信息。查看百度账户的保存密码,可以看到密码为:
Miaojia123

图 4-5 浏览器密码管理器中保存的百度账户登录信息。
继续查看 CTFshow 账户,发现其密码同样为 Miaojia123。

图 4-6 浏览器密码管理器中保存的 CTFshow 账户登录信息。
两个不同网站使用了相同密码,可以判断这就是佳佳经常使用的通用密码:
Miaojia123
CP3 的三个答案为:
远程控制持续时间:163 秒
软件开始时间:2021/12/14_22:14:14.804
通用密码:Miaojia123
浏览器保存的密码能够直接反映用户的密码复用习惯。多个网站使用相同密码,一旦其中一个网站发生数据泄露,攻击者就可能利用相同凭据尝试登录其他平台,因此实际使用中不应在不同系统之间重复使用同一密码。
四、遇到的问题
4.1 库调用问题
在使用 Python 2 环境安装相关依赖库时,出现了 egg_info 执行失败的问题,导致所需库无法正常安装。

图 4-1-1 使用 pip2 安装依赖库时出现 egg_info 相关错误。
从报错信息来看,问题与当前 Python 2 环境中的 setuptools 版本有关。由于部分旧版本 setuptools 与待安装软件包的构建流程不兼容,因此先对其进行升级。
pip2 install --upgrade setuptools -i https://pypi.tuna.tsinghua.edu.cn/simple
这里使用清华 PyPI 镜像源提高下载速度。完成 setuptools 升级后,再重新执行原来的依赖安装命令。

图 4-1-2 升级 setuptools 后重新完成相关 Python 依赖的安装。
遇到
egg_info、setup.py或构建阶段报错时,不一定是目标库本身存在问题,也可能是pip、setuptools等基础构建工具版本不兼容。先检查并更新构建环境,通常比反复重新安装目标库更有效。
4.2 找不到磁盘
在创建虚拟机并尝试使用挂载后的物理磁盘时,VMware 出现无法访问磁盘的问题。开始时怀疑是 VMware 本身没有足够权限,因此首先尝试以管理员身份运行 VMware。

图 4-2-1 VMware 创建虚拟机时出现无法访问目标磁盘的问题。
如果管理员权限仍然无法解决问题,还需要检查目标磁盘或分区是否正在被其他进程占用。按下 Win + R 打开“运行”窗口,输入:
resmon
进入“资源监视器”后,选择 CPU 页面,在“关联的句柄”搜索框中输入被占用的磁盘盘符,例如:
F:
通过这种方式可以查询当前有哪些进程持有该磁盘或分区的相关句柄。

图 4-2-2 在资源监视器的关联句柄中查询目标磁盘的占用情况。
如果发现有其他程序正在占用目标磁盘,需要先确认对应进程的用途,再关闭相关程序或解除占用,然后重新尝试让 VMware 访问磁盘。
不过,在本次实验中,即使尝试了管理员权限和磁盘占用排查,问题仍然没有彻底解决。结合后续现象来看,这里的根本问题更可能出现在前面的 FTK 镜像挂载环节。
4.3 Passware 无法提取 SAM
在使用 FTK 挂载检材后,尝试通过 Passware Kit Forensic 读取系统中的 SAM 文件时同样出现异常,无法按照预期完成账户密码信息的提取。

图 4-3-1 使用 Passware Kit Forensic 处理挂载镜像中的 SAM 文件时出现异常。
开始时主要围绕 Passware 本身进行排查,但结合前面 VMware 找不到磁盘的问题,可以发现两个异常都发生在 FTK 挂载检材之后。因此这里可以初步判断,问题并不一定出在 VMware 或 Passware 本身,而更可能是 FTK 对该检材的挂载结果存在异常。
由于始终没有找到稳定解决 FTK 挂载问题的方法,最后没有继续在原有挂载方式上反复尝试,而是更换处理思路:使用 QEMU 将 .E01 检材转换为 VMware 可以识别的 .vmdk 虚拟磁盘文件。
转换完成后,再使用 VMDK 文件恢复虚拟机环境,并通过其他镜像挂载工具访问其中的 Windows 分区,后续的系统启动、SAM 提取和密码恢复才能继续进行。
4.2 和 4.3 中出现的问题表面上分别表现为“VMware 找不到磁盘”和“Passware 无法正常处理 SAM”,但继续排查后发现,两者都与前面的 FTK 挂载过程有关。

浙公网安备 33010602011771号