深入解析iOS照片数据库：揭示照片与创建应用的技术关联

本文详细探讨了如何通过分析iOS设备中的Photos.sqlite数据库，追踪照片的来源应用（如原生相机、信息应用内的相机或第三方应用），并揭示了当照片作为附件发送或删除后，相关文件在设备文件系统中的残留情况与技术细节。

使用Photos.sqlite展示照片与其创建应用程序之间的关系？

作者：斯科特·科尼格 | 更智能的取证

首先，我要感谢希瑟·马哈利克在此过程中的帮助，并允许我在她的博客上发布内容。这是我的荣幸！此外，还要感谢贾里德·巴恩哈特在研究与测试方面给予的协助。

如果各位已经花时间阅读过这篇博客，我必须先表示歉意。这是我第一篇研究博客，发布之后，我感觉它缺少了一些内容。我纠结于是重写它，还是仅仅用一篇额外的博客来补充。最终得出结论，编辑原文并重新发布整篇博客，是让大家获取完整信息的最佳方法。

概要：在一次检测与分析过程中，我了解到一些有趣的事情，并希望与大家分享。在检查一部苹果iPhone 7之后，我发现一些照片是在原生iPhone信息应用（com.apple.MobileSMS）内部，使用相机应用（com.apple.camera.CameraMessagesApp）拍摄的。作为拍摄照片的结果，创建了几个我在过去的检查中未曾观察到的文件，这引发了我的一些疑问。

这是因为我在检查一个完整的文件系统提取镜像吗？ 或者 是因为我在检查过程中没有足够仔细地留意？

无论如何，我着手进行测试以验证我的发现。

嫌疑设备： 测试设备： 苹果 iPhone 7 (A1778) 苹果 iPhone XS (A1920) iOS 13.4.1 (17E262) 13.5.1 (17F80)

在测试过程中，我没有发现13.4.1和13.5.1之间有导致测试无效的重大变化。不过，当我查看iOS 12.*.*的FFS提取镜像时，确实注意到了一些差异。

重要提示：在这篇博客最初写完后处理案件时，我注意到iOS 12和iOS 13之间存在一些差异。主要是，iOS 13设备在/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/位置比iOS 12设备包含更多数据。我提及这一点只是为了让您知道，可能还存在尚未讨论的其他差异。

获取方式： 首次解锁后（AFU）完整文件系统（FFS）（嫌疑设备和测试设备）。 Cellebrite UFED 4PC高级逻辑提取和逻辑提取（仅嫌疑设备）。

使用的工具： Cellebrite UFED 4PC (7.34.0.116) Cellebrite Physical Analyzer (PA) (7.35.00.33 – 7.36.0.35) Magnet AXIOM (4.3.1.20814) Artifact Examiner (1.3.6.1) https://www.doubleblak.com/ Mushy Plist Viewer (1.2.7.0) iLEAPP (1.2) https://github.com/abrignoni/iLEAPP APOLLO (1.1) https://github.com/mac4n6/APOLLO Zimmerman Hasher (1.9.2.0) Navicat for SQLite (15.0.1) DB Browser (3.12.0)

取证问题： 在检查嫌疑设备并分析数据时，我对显示的数据及其创建方式有一些疑问。我构思了几个可能有助于演示和解释所发生情况的场景：

场景 #1 – 当照片在原生iOS信息应用（com.apple.MobileSMS）内部使用相机应用（com.apple.camera.CameraMessagesApp）拍摄并作为附件发送时，会发生什么？ 场景 #2 – 当照片在原生iOS信息应用内部拍摄，作为附件消息发送，并且后来从对话线程中删除了包含该附件的消息时（/private/var/mobile/Library/SMS/Attachments/），会发生什么？ 场景 #3 – 当照片在原生iOS信息应用内部拍摄，作为附件消息发送，并且后来从照片应用（/private/var/mobile/Media/DCIM/）中删除了作为附件发送的照片时，会发生什么？

场景 #1 – 在原生iOS信息应用内部使用相机应用拍摄照片/实况照片并作为附件发送时会发生什么：

在测试中，我按照以下步骤拍摄了照片和实况照片：

  1. 启动原生iOS信息应用（图1.1）并进入对话线程（图1.2）。
  2. 从对话线程中点击相机图标（图1.3），拍摄一张照片（图1.4），然后点击完成（图1.5）。注意：图1.5是照片的预览，可以发送。但这不就是刚刚拍摄的照片吗？多亏了贾里德·巴恩哈特的帮助，我了解到这张照片实际上已保存到设备上，即使用户选择“重拍”。这张照片将存储在/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/文件夹中。
  3. 随后出现预览（图1.6），点击向上箭头将照片发送给收件人，未附加任何文本（图1.7）。

现在，让我们看看当这些操作发生时设备内部发生了什么。

应用程序使用情况和处于前台的应用程序被记录在KnowledgeC数据库中。关于KnowledgeC数据库及其内容已有一些资源和已发表的研究。我鼓励你花时间查看本文末尾的参考文献和其他来源列表。

  • 晚上8:21:22 – 晚上8:22:54，应用程序（com.apple.MobileSMS）被启动并使用。

  • 在此期间：

    • 晚上8:22:01 – 后置摄像头被打开
    • 晚上8:22:03 – 应用程序（com.apple.camera.CameraMessagesApp）被启动，并且在Cache.sqlite – ZRTCLLOCLATIONMO表中创建并存储了几个缓存位置。这些位置准确反映了测试期间设备所在的位置。
    • 晚上8:22:03 – 与\private\var\db\uuidtext\相关的各种文件路径位置被打开、修改和创建。我尚未研究或解码这些内容，但想提一下。

  • 晚上8:22:03 – 创建了一个属性列表（plist）： private\var\mobile\Library\SMS\PluginMetaDataCache\BB6846A9-F53A-4DDA-9FA9-75B5E4FDF94E\com.apple.messages.MSMessageExtensionBalloonPlugin:0000000000:com.apple.camera.CameraMessagesApp.plist

    这个plist可以在AXIOM中查看（图4），也可以在PA中查看。我将其保存、导出并使用伊恩·惠芬的Mushy plist查看器打开（图4.1）。该plist包含接收附件消息的设备的电话号码和关联的UUID。

    这个plist也存在于嫌疑设备中，包含一个电话号码及其关联UUID的列表。似乎存在不同类型的消息发送对应的不同属性列表：

    • com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.Animoji.StickersApp.MessagesExtension.plist
    • com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.camera.CameraMessagesApp.plist
    • com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.mobileslideshow.PhotosMessagesApp.plist
    • com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.PassbookUIService.PeerPaymentMessagesExtension.plist
    • com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.siri.parsec.HashtagImagesApp.HashtagImagesExtension.plist
    • com.apple.messages.MSMessageExtensionBalloonPlugin_EWFNLB79LQ_com.gamerdelights.gamepigeon.ext.plist

  • 晚上8:22:20，拍摄了一张我朋友Dexter的实况照片，导致在设备上创建了多个文件，包括以下内容：

    • /private/var/mobile/Media/DCIM/100APPLE/IMG_0012.MOV
    • /private/var/mobile/Media/DCIM/100APPLE/IMG_0012.JPG
    • /private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470/tmp/61777214012__81412243-7181-4BFA-BAE0-7101DC818736.MOV
    • /private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470/tmp/61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.JPG
    • /private/var/mobile/Library/SMS/Attachments/eb/11/A4BDFF37-B875-44DE-A094-1AC66A6DC059/61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.JPG
    • /private/var/tmp/com.apple.messages/com.apple.MobileSMS/LinkedFiles/CB11EDB0-B428-49A4-9913-2C959289C3BC/61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.MOV

用于检查测试数据的每个工具都在时间线中以不同的顺序排列这些文件，但它们都有相同的捕获和创建时间：晚上8:22:20。

在AXIOM的时间线中（图5.1），有一个关于条目被写入Photos.sqlite数据库的事件。更多细节见图5.2和图5.3。

Photos.sqlite信息： 在图5.3中，我们正在PA SQLite查看器中查看Photos.sqlite数据库的ZGENERICASSET表。请注意，所有PK值都是顺序的，没有缺失值，表明列表是完整的。我刚才提到，当我拍摄Dexter的照片时，创建了多个文件，包括IMG_0012.MOV。关于其他文件的信息在哪里？本博客后续会有更多内容。

请注意，在图5.3中，有迹象表明在Photos.sqlite的ZADDITIONALASSETATTRIBUTES表中也创建了一个条目。请注意，AXIOM显示Z_PK值和ZADDITIONALASSETATTRIBUTES值是相同的。更多相关内容将在博客后面介绍。这里必须给伊恩·惠芬一个大大的感谢。我最初是在他的工具Artifact Examiner (ArtEx)中查看完整文件系统转储时注意到这些值的。我联系了他并问了一些问题，他立刻就回答了。这在检查嫌疑设备时提供了巨大帮助……谢谢伊恩！！

在图7中，我们可以看到ZADDITIONALASSETATTRIBUTES表以及关于IMG_0012.JPG的一些关键信息。

我想花点时间讨论一下我在检查ZADDITIONALASSETATTRIBUTES表时发现的一些项目。首先注意，Z_PK条目1-6的ZEXIFTIMESTAMPSTRING列中没有日期。这些图像不是用测试设备拍摄的。它们是从安卓设备通过MMS发送到测试设备的。这些照片随后通过原生iOS信息应用保存到了照片应用。请注意ZCREATORBUNDLEID显示为com.apple.MobileSMS。

Z_PK条目7-11和17-22是使用测试设备原生相机应用（从主屏幕启动）拍摄的。请注意，ZCREATORBUNDLEID没有条目，但ZIMPORTEDBY有值。结合嫌疑数据和测试数据，我相信我已经解码了一些值。这些是初步的，需要额外的测试：

  • 0 = 与.MOV文件相关。
  • 1 = 通过原生后置摄像头拍摄
  • 2 = 通过原生前置摄像头拍摄
  • 3 = 第三方应用 – Snapchat
  • 6 = 第三方应用 – Facebook
  • 8 = 通过原生后置摄像头拍摄
  • 9 = 从外部来源保存（短信、Safari）

请注意，这些条目的ZREVERSELOCATIONDATA列中都有一个二进制属性列表。拍摄照片时，相机应用的位置服务是开启的。注意条目21和22没有二进制属性列表。这些照片是在设备数据被提取前几分钟拍摄的。我认为在设备被获取之前，数据没有时间填充这个字段。我将在本博客后面讨论这个bplist的内容。

Z_PK条目12-16是通过iOS信息内部的相机应用（CameraMessagesApp）拍摄的。

这里需要注意一下……ZORIGINALFILENAME列。所有使用CameraMessagesApp拍摄的照片都有一个UUID作为原始文件名。如果你记得在讨论Photos.sqlite – ZGENERICASSET表时，这些文件并未列在ZFILENAME列中。另一个注意事项，只列出了创建的JPG文件。请记住，当我使用CameraMessagesApp拍摄Dexter的实况照片时，创建了多个文件……现在ZGENERICASSET表中只列出了IMG_0012.JPG。

日期、时间和时区： 注意ZADDITIONALASSETATTRIBUTES表的ZEXIFTIMESTAMPSSTRING列和ZGENERICASSET表的ZDATECREATED列中，日期和时间值以不同格式存储。ZDATECREATED中的值原生以Unix时间戳存储，需要转换，而ZEXIFTIMESTAMPSSTRING列中的值则根据文件捕获时的设备时间设置存储。在测试设备中，日期和时间设置为自动，时区设置为库比蒂诺，即太平洋时间。数据库还有其他列记录了文件创建时的时区设置：ZADDITIONALASSETATTRIBUTES表中的ZTIMEZONEOFFSET、ZINFERREDTIMEZONEOFFSET和ZTIMESONENAME列。

方向： 在ZGENERICASSET表中有一个ZORIENTATION列。使用测试设备数据，我确定1 = 水平，6 = 垂直。我从安卓设备发送到测试设备的照片既有原始水平方向，也有垂直方向。当它们保存到测试设备时，所有照片都以水平方向保存。请确保在每个iOS版本上验证这些是否正确，因为它们似乎会变化。

位置： 在Physical Analyzer的图5中，没有解析出使用CameraMessagesApp拍摄的照片的位置数据。经过仔细分析，我无法在任何通过com.apple.camera.CameraMessagesApp应用创建的项目的EXIF数据或数据库元数据中找到记录的位置数据。在测试期间，位置服务是开启的，并且使用原生相机（com.apple.camera）拍摄的文件记录了位置，但使用com.apple.camera.CameraMessagesApp拍摄的文件则没有。不确定这是否是为了隐藏位置而设的安全功能，因为这些文件是通过信息发送的。注意：我在十六进制级别对文件进行了简要概述，没有找到任何位置数据。可能需要额外的分析和研究才能得出明确结论。

让我们看看ZREVERSELOCATIONDATA bplist。这个plist可以从Cellebrite PA SQLite查看器和Magnet AXIOM SQLite查看器查看，但就像我之前说的，我使用了伊恩·惠芬的工具Mushy Plist查看器。这个bplist中发现的位置准确反映了拍摄照片时设备所在的位置。

Photos.sqlite数据库中存储了大量数据，并且最近有比我先进得多的研究人员对该数据库进行了研究和发表。我强烈建议你查看本文末尾的参考文献列表，以获取更多详细信息和链接。

我找到了一个Magnet自定义项目，用于解析Photos.sqlite。该自定义项目由Costas Katsavounidis提交。SQLite查询基于iOS 8及更高版本的操作系统。该自定义项目可以在Magnet Forensics自定义项目交换中心找到。在查看查询及其列出的参考文献后，我了解了对数据库中存储信息进行额外解码的方法。在审查过程中，我了解到Costas Katsavounidis查询中解码的许多信息也适用于iOS 13。这些信息，连同贾里德·巴恩哈特研究中的信息，都已包含在我使用并分享的查询中。请在用于你的案件之前进行测试和验证。我也已提交查询，希望将其添加到Magnet自定义项目交换中心。这里是查询和自定义项目的Google Drive链接。

原始文件名 & /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/： 在Navicat（付费）和DB Browser（免费）中运行SQLite脚本后，我将输出导出为CSV。在这一部分，我将再次关注本演示开始时创建的实况照片（IMG_0012.JPG）。图9显示了输出的部分内容，展示了文件是如何关联的：

请注意，IMG_0012.JPG的原始文件名是61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.JPG。 文件61777214080__90B95980-BB3C-4A7A-B74E-82C62C923CC2.JPG存储在：/private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470/tmp/

在检查嫌疑设备期间，找到了在此测试过程中创建的一些文件，但本应存在的更明显的文件似乎被删除了。这意味着什么？ 如果这张照片作为附件附加到消息中，发送到了另一台设备，并且尚未被删除，那么在设备中应该有一个文件存储在：/private/var/mobile/Library/SMS/Attachments/。在测试期间，存储在/Containers/Data/PluginKitPlugin/<UUID>/temp和/SMS/Attachments/位置的文件具有相同的文件名和哈希值。

在嫌疑设备中，我找到了存储在/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/文件位置的文件。请注意，我删除了UUID并用<UUID>代替。在嫌疑设备中，此临时文件位置的UUID与我的测试设备中列出的不同。这是两个文件路径：

  • 嫌疑设备：/private/var/mobile/Containers/Data/PluginKitPlugin/6E9D5BDD-2BF6-4203-9608-BAEF8CAAD00A/tmp/
  • 测试设备：/private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470/tmp/

在测试设备中发现这一点时，我认为肯定有文档表明临时文件位置与关联应用程序之间的关系。图10是Physical Analyzer的截图，显示了临时文件和文件系统视图。请注意，在文件系统中，“45AAD7D6-8C36-411A-B311-04EAE0B5C470”文件夹的根目录中有一个plist。

在图11中，我导出了这个plist（.com.apple.mobile_container_manager.metadata.plist），当用Mushy Plist查看器查看时，我发现了一个“MCMMetadataIdentifier: AsciiString = com.apple.CameraMessagesApp。”这似乎是与此文件夹路径UUID关联的应用程序。

根据测试和在嫌疑设备中观察到的情况，我得出结论：如果一个文件存储在此文件路径中，那么它是通过CameraMessagesApp捕获/创建的。

注意：这并不是唯一一个在/private/var/mobile/Containers/Data/PluginKitPlugin存储数据的应用程序。还有其他几个应用程序在此位置存储数据，包括SnapChat。我没有详细介绍此处包含的其他数据，但分析这个文件位置以查看是否可以找到你正在寻找的任何证据将是非常有益的。

现在我们已经讨论了在原生iOS信息应用内部拍摄照片过程中创建了哪些文件，让我们看看删除其中一个或多个文件后留下了什么。

场景 #2 当照片在原生iOS信息应用内部拍摄，作为附件消息发送，并且后来从对话线程中删除了包含该附件的消息时，会发生什么：

此场景的概括是：使用相机信息应用拍摄了一张照片（IMG_0014.JPG）。拍摄此照片时，实况照片功能处于关闭状态。照片被拍摄、附加到消息，然后发送到另一台设备。后来，包含附件的已发送消息从信息应用中删除。

  • 2020年7月29日晚上8:23，通过测试设备，我关闭了实况照片。
  • 晚上8:26:46，从主屏幕启动了信息应用（com.apple.MobileSMS）。
  • 晚上8:27:09，启动了信息相机应用（com.apple.camera.CameraMessagesApp）。
  • 晚上8:27:15，通过com.apple.camera.CameraMessagesApp拍摄了一张Dexter的照片。照片描绘了Dexter躺下的样子，在照片中看不到他的眼睛。照片被附加到消息并发送到一台安卓设备。该消息不包含文本。 注意：此消息和附件在设备数据提取之前已被删除。
  • 晚上8:30:05，信息应用com.apple.MobileSMS被关闭。
  • 晚上8:57:08，信息应用被启动。
  • 晚上8:58，包含前面讨论的Dexter照片的消息和附件从信息对话线程中删除。
  • 晚上9:00:04，照片应用（com.apple.mobileslideshow）被启动并处于前台。
  • 晚上9:01，访问了“最近删除”项目，该区域没有列出任何照片。使用Physical Analyzer检查设备数据时，我找到了一个应用程序使用情况的条目。它显示com.apple.mobileslideshow在晚上9:01:30至9:01:34之间被启动和使用。它显示了一个“Activity Type: com.apple.mobileslideshow.album”。 注意：我在KnowledgeC数据库的ZSTRUCTUREDMETADATA表中找到了数据，表明这些数据可能有一个过期日期。过期日期列在标签为Z_DKAPPLICATIONACTIVITYMETADATAKEY_EXPIRATIONDATE的列中。我还没有测试过这一点，但想提一下。

现在回到已删除的文件。在图17中，我们可以看到工件视图 – 媒体 – 缩略图视图，并注意到此过程中缺失的文件是应该存储在/private/var/mobile/Library/SMS/Attachments/的照片。

图18是查看相同文件的另一个视角，但从工件 – 媒体 – 表格视图。请注意条形栏显示只有两个文件与主记录合并，它们都不是附件文件。

如前所述，无论消息和附件是否被删除，创建并保存到/Containers/Data/PluginKitPlugin/<UUID>/tmp/的文件都将存在。 注意：我不确定这些文件会在设备中保留多久。第一次提取（2020年7月31日）中存在的文件在第二次提取（2020年9月5日）中也存在。

让我们尝试查找存储在该特定应用程序（com.apple.camera.CameraMessagesApp）的PluginKitPlugin位置中的所有项目。在缩略图视图中，我根据UUID“45AAD7D6-8C36-411A-B311-04EAE0B5C470”过滤了合并的相似项目。

在图19中，所有的重复项和相似项目都相互合并，因此每张照片的左下角都有分层方块图标。在检查Physical Analyzer内的图标通知时，我注意到高亮照片缺少两个图标。一个是表示消息已发送的发送消息图标，另一个是用于表示附件的回形针图标。这些图标缺失是因为消息和附件已从消息线程中删除。当消息和附件被删除时，存储在/private/var/mobile/Library/SMS/Attachments/的关联文件也被删除。我无法找到该文件，它似乎在消息被删除后立即从设备中移除。

注意：当我检查嫌疑设备时，可没这么简单！！有成千上万张照片，我根本不知道我在找什么，或者一旦找到这些，我看到的又是什么。

现在，这对我来说是一个迹象，表明可能有一条带有附件的消息被发送然后被删除了。

场景 #3 当照片在原生iOS信息应用内部拍摄，作为附件消息发送，并且后来从照片应用中删除了作为附件发送的照片时，会发生什么：

在图22中，我们可以在PA中看到一个文件，IMG_0013.JPG，它是使用相机信息应用拍摄的。拍摄此照片时，实况照片处于关闭状态。照片被拍摄、附加到消息，然后发送到另一台设备。后来，存储在/private/var/mobile/Media/DCIM/100APPLE的照片被删除。我能够在照片被永久删除并从“最近删除”中移除之前提取设备数据。在这种情况下，测试设备上剩余的文件存储在：

  • /private/var/mobile/Library/SMS/Attachments/43/03/042886A9-EF88-4ADE-9AE7-013078A63B1F/61777224175__CCFF7725-BFDC-4CAA-84BA-DB045C7EAB28.JPG
  • /private/var/mobile/Containers/Data/PluginKitPlugin/45AAD7D6-8C36-411A-B311-04EAE0B5C470/tmp/61777224175__CCFF7725-BFDC-4CAA-84BA-DB045C7EAB28.JPG
  • /private/var/mobile/Media/DCIM/100APPLE/IMG_0013.JPG – “最近删除”

让我们通过为Photos.sqlite数据库编写的SQL查询来看看这是什么样子。请注意，有一个状态列用于“文件回收站状态”，另一列是“文件回收站日期”。高亮显示的文件IMG_0013.JPG显示文件在回收站中，并提供了回收日期或它被标记为“最近删除”的日期。此外，请注意没有缺少条目Z_PK 1-22。

关于已删除文件的额外信息： 我将IMG_0013.JPG从最近删除/回收站中恢复。Photos.sqlite中唯一明显的变化是文件不再具有回收站状态和文件回收站日期。然后我删除了IMG_0014.JPG，它随后被标记为最近删除/在回收站中。我做了这个更改是因为我想测试，如果所有其他关联文件都被删除，存储在/Containers/Data/PluginKitPlugin/<UUID>/tmp/的文件是否会保留。

在文件不再列于最近删除之后，完成了第二次完整文件系统提取。在图24和图25中，我们可以看到，在所有其他关联文件被删除后，存储在/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/的文件仍然保留。

让我们看看通过查询Photos.sqlite发生了什么变化。请注意Z_PK 14，IMG_0014.JPG的整个条目已被删除。

总结：

在本博客中，我们讨论了一些如果你有iOS完整文件系统提取镜像应该分析的额外文件位置。

你应该检查Photos.sqlite数据库并查看原始文件名。这可能表明存在需要分析的额外文件，以及FFS提取是否对你的调查有益。

此外，你应该检查Photos.sqlite的创建者包ID，这可能表明用于拍摄/创建照片的应用程序。利用这些信息，你可以找到合适的/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp文件位置，以检查是否存在额外文件。

/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp文件位置可能包含在其他类型的提取中不存在的重要数据。它还可能包含已被用户删除且可能不存在于设备其他位置的文件。

如果没有其他杰出且知识渊博的专业人士的帮助，我不可能完成这项研究，他们在我甚至拥有第一部手机之前就一直在做这类工作。我想借此机会感谢所有与社区分享经验的人，并列出我在法证检查和准备这篇博客时使用过的一些资源。我希望它能像帮助我一样帮助你。

感谢你与我一起踏上这段旅程，如果你对这篇研究博客有任何疑问，请随时与我联系。一如既往，请测试和验证你的发现，并花时间分享！

参考文献和资源：

comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次