利用photos.sqlite展示照片和创建它们的应用程序之间的关系

在测试的过程中，我在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 高级逻辑提取 (嫌疑人手机)

1.Cellebrite UFED 4PC (7.34.0.116)

2.Cellebrite Physical Analyzer (PA) (7.35.00.33 – 7.36.0.35)

3.Magnet AXIOM (4.3.1.20814)

4.Artifact Examiner (1.3.6.1) https://www.doubleblak.com/

5.Mushy Plist Viewer (1.2.7.0)

6.iLEAPP (1.2) https://github.com/abrignoni/iLEAPP

7.APOLLO (1.1) https://github.com/mac4n6/APOLLO

8.Zimmerman Hasher (1.9.2.0)

9.Navicat for SQLite (15.0.1)

10.DB Browser (3.12.0)

当检查和分析嫌疑人的设备时，我对于看到的内容和这些数据的产生方式有一些疑问。于是，我制定了一些可能有助于演示和解释所发生事情的场景：

场景#1：利用手机短信应用程序(com.apple.MobileSMS)调用摄像头程序(com.apple.camera.CameraMessagesApp)拍摄一张照片，把照片作为短信的附件发送出去。

场景#2：按照场景1操作之后，在短信对话窗口中将照片附件删除(/private/var/mobile/Library/SMS/Attachments/)。

场景#3：按照场景1操作之后，从照片图库 (/private/var/mobile/Media/DCIM/) 中删除照片。

场景#1：在手机短信应用程序中调用相机拍摄一张照片作为附件发送，会发生什么？

在实验过程中，我按照以下步骤拍摄照片或实况照片：

1.启动本机iOS messenger应用程序（图1.1），然后进入短信对话窗口（图1.2）

图 1.1

图 1.2

2.在短信对话窗口中点击相机图标（图1.3），拍摄照片（图1.4），点击 “done”完成（图1.5）。注意：图1.5是一个即将发送出去的预览照片。那么，这张照片是不是我们后期会从手机中找到的短信附件照片呢？其实，此时这张照片虽然还没有被发送出去，但它已经被保存在手机的/private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/目录下了。如果用户选择撤销这张照片，使用“Retake”重新拍一张，之前的那张预览照片依然存在。

图 1.3

图 1.4

图 1.5

3.随后短信对话窗中会出现照片预览图（图1.6），点击向上箭头发送照片。图1.7可见，此时照片已经发送出去，没有文字内容。

图 1.6

图 1.7

现在让我们看一下当上述步骤操作完成，设备内部会发生什么事情。

KnowledgeC数据库中记录了应用程序使用情况和重点应用程序。大家可以去找找关于KnowledgeC数据库的介绍文章，有很多已发表的研究成果介绍了这个数据库里面会记录什么。我建议您看完本文之后，花点时间浏览文末的参考资料。

8:21:22 PM至8:22:54 PM  短信应用程序 (com.apple.MobileSMS) 启动并运行中。

在此期间：

8:22:01 PM  —— 后置相机被启用

8:22:03 PM  —— 相机应用程序(com.apple.camera.CameraMessagesApp)被启动，并且创建一些缓存位置记录信息，存储在Cache.sqlite数据库的ZRTCLLOCLATIONMO表中。在实验期间，这些记录的测试位置信息是准确的。如果你有其他关于位置信息的问题，可以翻阅参考资料中lan Whiffin的博客文章。

8:22:03 PM —— 与\private\var\db\uuidtext\相关的许多其他路径位置被打开、修改和创建了。虽然我还没有对这些内容进行深入研究，但我还是先在这里提一下，供大家参考。

图1.8，图1.9，图1.10，图1.11，图1.12是利用不同取证工具对已启动的程序的解析结果。

图 1.8 PA

图 1.9 AXIOM

图 1.10 ArtEX

图 1.11 KnowledgeC.db PA

8:22:03 PM — 一个plist属性列表文件被创建，位置如下：

private\var\mobile\Library\SMS\PluginMetaDataCache\BB6846A9-F53A-4DDA-9FA9-75B5E4FDF94E\com.apple.messages.MSMessageExtensionBalloonPlugin:0000000000:com.apple.camera.CameraMessagesApp.plist

在图1.12中可见，可以用AXIOM和PA来查看这个plist文件。我使用了Ian Whiffin编写的Mushy Plist Viewer来打开、保存并导出这个plist文件。如图1.13可见，这个plist中记录了实验中的照片短信被发送到的手机号码和相关的UUID。

图 1.12

图 1.13 Mushy Plist Viewer

这个plist文件也可以在嫌疑人的手机中找到，其中包含了很多手机号码和相关的UUID。对于所发送的不同类型的短信，似乎会产生不同的plist文件。

1.com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.Animoji.StickersApp.MessagesExtension.plist

2.com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.camera.CameraMessagesApp.plist

3.com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.mobileslideshow.PhotosMessagesApp.plist

4.com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.PassbookUIService.PeerPaymentMessagesExtension.plist

5.com.apple.messages.MSMessageExtensionBalloonPlugin_0000000000_com.apple.siri.parsec.HashtagImagesApp.HashtagImagesExtension.plist

6.com.apple.messages.MSMessageExtensionBalloonPlugin_EWFNLB79LQ_com.gamerdelights.gamepigeon.ext.plist

8:22:20 PM — 在我为好朋友Dexter拍摄实况照片时，手机内又生成了以下这些文件：

当我用不同的工具分析这些测试数据时，每个都会把这些文件以不同的时间线顺序放置，但是它们都有相同的拍摄和创建时间，即8:22:20 PM，见图1.14。

图 1.14 PA

参图1.15，在AXIOM的时间轴中可以发现，有一个事件条目被创建到 Photos.sqlite 数据库中。可以参考图1.16和图1.17查看具体细节信息。

图 1.15 AXIOM

图 1.16 AXIOM

图 1.17 Photos.sqlite – PA

在图1.17中，我使用PA SQLite Viewer查看Photos.sqlite 数据库中的ZGENERICASSET 表。可以看到表中字段Z_PK的所有值都是按顺序排列的，没有缺失值，说明这个表是完整的。我刚说过，当我为Dexter 拍照的时候，手机中生成了很多文件，包括IMG_0012.JPG这个文件。那么包含这些文件的信息都被保存在哪里呢？本文后续会慢慢讨论这些内容。

通过图1.17我们可以发现，Photos.sqlite数据库的 ZADDITIONALASSETATTRIBUTES 表中被创建了一个条目。AXIOM的分析结果表明，Z_PK和ZADDITIONALASSETATTRIBUTES 的值是相同的。稍后将在文中详细介绍。我必须向Ian Whiffin高声鸣谢，因为当我使用他的工具Artifact Examiner (ArtEx)查看整个文件系统镜像时，我才发现了数据库中的这几个值。我后续又问了他几个问题，他都立刻回答了我，对我检验嫌疑人的设备有很大的帮助。具体结果见图1.18。

图 1.18

图1.19中可以看到 ZADDITIONALASSETATTRIBUTES 表和一些关于 IMG_0012.JPG的重要信息。

图 1.19 PA SQLite Viewer

现在，我想花点时间说说我在分析 ZADDITIONALASSETATTRIBUTES 表时的一些发现。

首先需要注意，Z_PK字段的1-6条记录在ZEXIFTIMESTAMPSTRING列中没有日期和时间。这些照片不是用测试手机拍摄的，而是从一台安卓手机中以彩信（MMS）形式发送到测试手机中的。然后这些照片是使用手机短信应用程序保存到照片图库中的。注意看图，ZCREATORBUNDLEID字段记录了com.apple.MobileSMS这个信息。见图1.20。

图 1.20 表ZADDITIONALASSETATTRIBUTES

Z_PK 字段的7-11条和17-22条是由测试设备的相机应用程序拍摄的照片，由springboard启动。注意表中ZCREATORBUNDLEID字段没有记录什么内容，但是ZIMPORTEDBY字段中记录了一些值。利用嫌疑人手机的数据和测试手机的数据，我对部分值进行了解码。但这些只是初步结果，还有待后续测试：

0 = 与 .MOV 文件有关

1 = 通过手机的后置摄像头拍摄

2 = 通过手机的前置摄像头拍摄

3 = 通过第三方应用程序 – Snapchat

6 = 通过第三方应用程序 – Facebook

8 = 通过手机后置摄像头拍摄

9 = 从外部源保存，如SMS、Safari

此外，在ZREVERSELOCATIONDATA字段中，我们发现上述的每条记录中都存在一个二进制Plist属性文件。这是由于拍摄这几张照片时启用了位置服务。注意到第21条和22条记录没有二进制Plist属性。这两张照片是在手机被提取前的几分钟被拍摄的。我想可能是此时数据还没有被写入此字段。后续我还会详细讨论这个bplist的内容。参图1.21和图1.24。

图1.21，图1.22和图1.23是测试手机的位置服务设置截图

图 1.21

图 1.22

图 1.23

图 1.24 表ZADDITIONALASSETATTRIBUTES – PA

Z_PK 字段的12-16条记录，是使用短信过程中调用相机程序拍照的结果。见图1.25

图 1.25 ZGENERICASSET 表和 ZADDITIONALASSETATTRIBUTES 表-PA

这里有些事情需要注意：ZORIGINALFILENAME列。

所有用CameraMessagesApp程序拍摄的照片都会有一个UUID作为原始文件名。之前说到Photos.sqlite的ZGENERICASSET表时我说过，这些文件没有列在ZFILENAME列中。

另外，只有被创建的JPG文件才会被列出。还记得当我使用 CameraMessagesApp 拍摄 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

日期，时间和时区：

请注意在ZADDITIONALASSETATTRIBUTES表 ZEXIFTIMESTAMPSSTRING列和 ZGENERICASSET 表的ZDATECREATED列中，日期和时间是以不同的格式保存的。ZDATECREATED列中存储的是unix epoch时间且需要转换。但是ZEXIFTIMESTAMPSSTRING列中记录的值是根据手机拍摄照片时该设备的时间设置决定的。在测试手机中，日期和时间设置为自动，时区设置为Cupertino，即UTC -8或DST -7)。数据库中还有其他列在记录创建文件时的时区设置，如ZADDITIONALASSETATTRIBUTES表的ZTIMEZONEOFFSET列, ZINFERREDTIMEZONEOFFSET 表的ZTIMESONENAME列。

方向：

在ZGENERICASSET表中有一个ZORIENTATION列。利用测试手机中的数据，我认为1=Horizontal（水平），6 = Vertical（垂直）。我从安卓手机发送到测试手机的照片既有水平方向的，也有垂直方向。当它们被发送并保存在测试手机后，所有的照片都以水平方向保存。**您可以在不同的 iOS 版本上测试这个结论是否正确，因为它们似乎也会变化。

位置：

从Physical Analyzer的分析结果（图1.14）可知，使用 CameraMessagesApp 拍摄的照片中没有解析出位置信息。我又进一步仔细分析，发现使用 com.apple.camera.CameraMessagesApp 程序拍摄的照片，无论从EXIF数据或数据库元数据中都找不到任何的位置信息。在测试中，手机定位服务是处于启用状态，而且使用内置相机程序（com.apple.camera）拍摄的照片也都包含有位置信息，但是使用com.apple.camera.CameraMessagesApp程序拍摄的照片就没有位置信息。我不确定这是不是因为使用短信程序发送照片而被设置的安全特性。注：我也使用16进制查看器分析了这张照片，的确没有发现任何位置信息。想得到准确的结论还需要深入的测试和研究。

在图1.26中，我用红框标记出了ZREVERSELOCATIONDATA列。注意ZREVERSELOCATIONDATAISVALID列的值为1或0。根据测试数据分析，我认为：1=如果可用则生成，0=如果可用不生成。这个结果与ZGENERICASSET表的 ZANALYSISSTATEMODIFICATIONDATE有关。在 ZREVERSELOCATIONDATAISVALID列中数值为0的记录，也缺少Analysis State Modification Date（分析状态修改日期）。这一部分也需要后续的进一步分析和测试。

我们再看一下ZREVERSELOCATIONDATA列中的bplist数据。这些二进制plist数据可以使用 Cellebrite PA SQLite Viewer 或 Magnet AXIOM SQLite Viewer查看。我自己则使用了Ian Whiffins 写的 Mushy Plist Viewer这个工具。在这些 bplist 中解析出的位置信息和拍摄照片时设备所处的位置是一致的。见图1.27和图1.28。

图 1.26 利用PA查看ZADDITIONALASSETATTRIBUTES表

图 1.27 利用PA查看ZADDITIONALASSETATTRIBUTES 表ZREVERSELOCATIONDATA 列

图 1.28 利用Mushy Plist Viewer查看ZREVERSELOCATIONDATA中的 Plist

Photos.sqlite数据库存有大量有价值的数据。有研究人员发布了对这个数据库的最新研究成果，比我研究的要深入得多。我强烈推荐大家去查阅文尾的参考材料列表中的相关文章。

我利用Magnet Custom Artifact查看Photos.sqlite数据库。这个自定义痕迹是Costas Katsavounidis提交的。这个SQLite查询适用于iOS 8以及更新的版本，可以在Magnet Forensics Custom Artifact Exchange中找到。在查看查询语句及其列出得参数后，我了解了如何对于保存在数据库中的信息进行额外解码。在查看过程中，我了解到很多由Costas Katsavounidis的查询语句解码的信息也能适用于IOS 13。这个信息和Jared Barnhart研究的结果已包含在我使用并分享的查询语句中。请在您的案件中对上述方法进行测试和验证。我还提交了需要添加到Magnet Custom Artifact Exchange的查询语句。这是一个链接到谷歌共享盘的查询语句和自定义痕迹：

https://drive.google.com/file/d/1EiZWfahyKShkIo3LPA3T_r4U5LGsFV6Q/view?usp=sharing

原始文件名& /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp/:

在Navicat(付费)和DB Browser(免费)中运行SQLite 脚本之后，我将结果导出到CSV。对于这个部分，我将再次着力于本次演示开始时创建的实时照片(IMG_0012.JPG)。图1.29是输出的一个部分，展示文件之间的联系：

图 1.29 SQLite脚本输出

注意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/ locations 的文件有相同的文件名和哈希值。

在嫌疑人的设备中，我找到了被保存在/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/

当这在测试设备中被发现时，我认为一定会有一个显示临时文件位置和相关应用程序之间关系的文档。图1.30是来自Physical Analyzer的屏幕截图，展示了临时文件和文件系统视图。注意，在文件系统中，“45AAD7D6-8C36-411A-B311-04EAE0B5C470”文件夹根目录下有一个plist。

图 1.30

如图1.31，我导出了这个plist(.com.apple.mobile_container_manager.metadata.plist)，并且使用Mushy Plist Viewer查看时，我发现一条记录“MCMMetadataIdentifier: AsciiString = com.apple.CameraMessagesApp.”。这似乎是有关文件夹路径UUID的应用程序。

图 1.31 Mushy Plist Viewer

根据测试和在嫌疑人的设备中观察到的情况，我得出了一个结论，如果一个文件被保存在这个文件路径中，那么它就是通过CameraMessagesApp拍摄或创建的。

注意：这不是唯一将数据存储在 /private/var/mobile/Containers/Data/PluginKitPlugin 的应用程序，还有一些其他应用程序在这个位置保存数据，包括SnapChat。我没有详细讲述这里包含的其他数据，但任何在此处找到的证据都可能有利于您分析这个文件位置。

既然我们已经讨论了在本机 iOS messenger拍摄照片的过程中创建了哪些文件，让我们看看在删除这些文件中的一个或多个时会留下什么。

场景#2 利用手机短信应用程序(com.apple.MobileSMS)调用摄像头程序(com.apple.camera.CameraMessagesApp)拍摄一张照片，把照片作为短信的附件发送出去，然后在短信对话窗口中将照片附件删除，会发生什么？

这个场景就是使用Camera Messenger应用程序拍摄了一张照片(IMG_0014.JPG)。拍摄照片时，实况照片已关闭。照片被拍摄并附在消息上，被发送到另一个设备。随后从messenger中删除带有附件的已发送的消息。

在2019年7月29日晚上8:23， 在测试设备中，我禁用了实况照片。

8:26:46 PM，短信应用程序(com.apple.MobileSMS)从springboard中启动。见图2.1。

图 2.1

8:27:09 PM，短信的拍照应用程序(com.apple.camera.CameraMessagesApp)启动，见图2.2。

图 2.2

8:27:15 PM，通过com.apple.camera.CameraMessagesApp拍摄一张Dexter的照片。照片中Dexter躺在地上，没有露出眼睛。这张照片被附在消息上，被发送到一台安卓设备，这条消息没有包含文本消息。

注意：提取设备数据之前，消息和附件都已被删除。

其他几张照片是通过com.apple.camera.CameraMessagesApp拍摄的，并通过消息发送到安卓设备。在图2.5中，注意在测试期间所有的照片都有回形针图标，表示它们都是附件。

8:30:05 PM，消息应用程序com.apple.MobileSMS关闭。

8:57:08 PM，消息应用程序启动。

8:58 PM，在消息的对话线程中已删除包含之前讨论过的Dexter照片的消息和附件。

9:00:04 PM，照片应用程序 (com.apple.mobileslideshow) 启动并被使用。

9:01 PM，访问“Recently Deleted”项目，发现这个地方未列出任何照片，使用 Physical Analyzer检查设备，我找到了一个应用程序使用的条目。这表明在9:01:30 – 9:01:34 PM期间，com.apple.mobileslideshow是启动并使用的。它表示“Activity Type: com.apple.mobileslideshow.album”。

注意：我在 KnowledgeC 数据库 ZSTRUCTUREDMETADATA 表中找到了表明此数据可能存在有效日期的数据。有效日期被列在标记的列中：

Z_DKAPPLICATIONACTIVITYMETADATAKEY_EXPIRATIONDATE。虽然还没有测试过，但我想提一下。见图2.3。

图 2.3 Timeline

在图2.4中我们可以看见拍摄照片和发送有附件的消息的时间轴。这个例子展示了如果消息没有删除时是长什么样子的。注意发出MMS 消息的条目。

图 2.4 Timeline

注意：这条消息没有和附件一起被发送的文字。在测试之后，我了解到如果发送只有一个附件的一条消息，那么它不会有KnowledgeC ZSTREAMNAME – /app/intents messages的条目。进一步测试后，我发现这也适用于一条同时包含文字和附件的消息。此外，在sms.db – message表中，只有一个条目用于文本正文和附件。

在图2.5中，我们可以看到当我拍摄实况照片时，创建了一些文件。注意，如前所述，保存在/SMS/Attachments和/Containers/Data/PluginKitPlugin 位置的文件有相同的文件名。

图 2.5 Artifacts Media Merged

让我们回到被删除的文件。在图2.6中，我们可以看见Artifact view – Media – Thumbnail view，注意到这个过程中缺少的文件是保存在/private/var/mobile/Library/SMS/Attachments/的照片。

图 2.6 Artifacts Media Merged

图 2.7 是Artifacts – Media – Table视图的相同文件的另一种外观。请注意，条形列表明只有两个文件与主记录合并，并且它们都不是附件文件。

图 2.7 Artifacts Media – Table View Similar Items Merged

如前所述，无论消息和附件是否被删除，创建并保存到/Containers/Data/PluginKitPlugin/<UUID>/tmp/ 的文件都存在。

注意：我不确定这些文件将在设备中存在多久。第一次提取（2020年7月31日）中出现的文件也在第二次提取中出现（2020年9月5日）。

让我们尝试找到所有存储在PluginKitPlugin位置的特定应用程序 (com.apple.camera.CameraMessagesApp)的项目。在缩略图视图中，我根据 UUID"45AAD7D6-8C36-411A-B311-04EAE0B5C470"筛选了合并后的类似项目。见图 2.8。

图 2.8

在图2.8中，所有重复项和类似项目都相互合并，因此每张照片左下角都有分层方形图标。在Physical Analyzer中检查图标时，我注意到突出显示的照片中缺少了两个图标。一个是表示消息被发送的发出消息图标，另一个是用于表示附件的回形图标。这些图标丢失是因为消息和附件从对话线程中被删除了。当消息和附件被删除时，保存在 /private/var/mobile/Library/SMS/Attachments/的关联文件被删除。我无法找到该文件，并且该文件似乎在消息被删除后立即从设备中删除了。

在图2.8 中，显示的其他文件是通过与突出显示的文件使用相同的方法创建的。

注意： 当我检查嫌疑人设备时， 这并不容易！！有成千上万的照片，我不知道我在找什么，也不知道我一旦发现这些照片，我该看什么。

图2.9，查看sms.db–message表，请注意，删除的消息缺少一个条目(ROWID 18) 。

图 2.9 sms.db – Messages Table

图 2.10 Timeline

在图2.10 中，我们可以看到与已删除的消息和附件相关的照片的时间轴。请注意，从时间线中缺少发出的MMS 条目。该文件使用UUID文件名保存在PluginKitPlugin文件位置。此外，还有一个文件保存在DCIM文件位置。我们还可以看到照片拍摄前后的应用程序和正在使用的应用程序。这些向我表明，可能已经由一封带有附件的邮件被发送，然后被删除了。

场景#3 利用手机短信应用程序(com.apple.MobileSMS)调用摄像头程序(com.apple.camera.CameraMessagesApp)拍摄一张照片，把照片作为短信的附件发送出去，之后，从照片图库 (/private/var/mobile/Media/DCIM/) 中删除照片，会发生什么？

在图3.1 中，我们可以在PA中看到一个文件，IMG_0013.JPG，这是使用Camera Messenger应用程序拍摄的。当拍摄照片时，实况照片已关闭。照片拍摄后被附在消息上，发送到另一个设备。稍后，保存在/private/var/mobile/Media/DCIM/100APPLE中的照片被删除。在照片被永久删除并从"Recently Deleted（最近删除）"中删除之前，我提取了设备数据。在这种情况下，测试设备上保留的文件存储在：

/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 – “Recently Deleted”

图 3.1 PA

让我们通过为Photos.SQLite数据库编写的SQLite查询语句看一下情况。见图3.2。注意，有一个File Trash State状态列，还有一个File Trash Date列。突出显示的文件IMG_0013.JPG表示该文件处于回收站中，它提供了回收站日期或标记为“recently deleted”的日期。此外，请注意，在Z_PK的1-22条中没有任何缺少的条目。

图 3.2 SQlite查询

有关已删除文件的其他信息：

我已将最近从回收站中删除/移除的IMG_0013.JPG恢复。Photos.sqlite中唯一显著的变化是文件不再具有Trash State和File Trash Date。然后我删除了IMG_0014.JPG，该文件随后在回收站中被标记为 recently deleted / in the trash。我做这个更改是因为我想测试如果删除了所有其他相关文件，存储在/Containers/Data/PluginKitPlugin/<UUID>/tmp/的文件是否会保留。

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

图 3.3 PA 

图 3.4 PA

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

图 3.5

总结：

这篇文章我们讨论了这样一个问题，当您需要对iOS 进行完整的文件提取 (FFS)提取时，那么应该对这些位置进行额外的检查和分析。

首先，您应该检查Photos.sqlite数据库并查看原始文件名。这可能表面存在其他需要分析的文件，以及FFS提取是否有助于您的调查。

此外，您应该检查Photos.sqlite creator bundle ID，该ID可以指出哪些应用程序用于捕捉或创建照片。根据这些信息，您可以找到正确的 /private/var/mobile/Containers/Data/PluginKitPlugin/<UUID>/tmp文件位置并检查更多的文件。

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

参考文献和资源：

Heather Mahalik Blog: https://smarterforensics.com Twitter @HeatherMahalik

Sarah Edwards Blog: https://www.mac4n6.com Twitter @iamevltwin GitHub: https://github.com/mac4n6

Alexis Brignoni Blog: https://abrignoni.blogspot.com Twitter @AlexisBrignoni GitHub: https://github.com/abrignoni

Ian Whiffin Blog: https://www.doubleblak.com  Twitter @BlakDouble

Ed Michael Twitter @EdXlg123 GitHub: https://github.com/edmichael 

Jared Barnhart Blogs hosted at: https://www.mac4n6.com Twitter @bizzybarney

Mike Williamson Blog: https://www.forensicmike1.com/2019/05/02/ios-photos-sqlite-forensics Twitter @forensicmike1

“Finding Waldo: Leveraging the Apple Unified Log for Incident Response” https://www.crowdstrike.com/blog/how-to-leverage-apple-unified-log-for-incident-response/

2020年8月25日由前线的Jai Musunuri和Erik Martin发布到CrowdStrike

Costas Katsavounidis [email protected] sqlite query and Magnet Forensics Custom Artifact based on iOS 8+. https://artifacts.magnetforensics.com/CommunitiesArtifactExchangeDownload?Id=a6K0b000000CrdoEAC

https://github.com/geiszla/iOSLib/wiki/ZGENERICASSET-contents

https://github.com/geiszla/iOSLib/wiki/ZADDITIONALASSETATTRIBUTES-contents

https://linuxsleuthing.blogspot.com/2013/05/ios6-photo-streams-recover-deleted.html

https://appletoolbox.com/live-photos-on-iphone-complete-guide/

还有很多其他的!

原文链接：

https://smarterforensics.com/2020/08/does-photos-sqlite-have-relations-with-cameramessagesapp-by-scott-koenig/

 本文由小茆同学编译、 陈裕铭校对，转载请注明。