iOS14取证解析：数据库变化、地图新格式与BLOB数据挖掘

作者：Heather Mahalik

本文是对本周正式发布的iOS14的初步检视。延续我之前的风格，我将重点关注影响几乎所有调查的基础数据，然后深入剖析。将此博文视为一次“浅尝辄止”的探索。本次测试使用了我个人可用的工具。如果您觉得遗漏了什么，请分享。如果您是供应商并认为有遗漏，请与我分享，我将亲自尝试。目前，加密的iTunes备份似乎是最稳定的选项。我知道供应商很快就会发布支持iOS14的更新，请耐心等待。如果您不加密备份，您将无法提取通话记录、Apple Maps（部分数据库被提取但为空）、Safari浏览记录、健康数据，可能还有更多内容！

苹果对于主要数据并未偏离太多。我注意到一些奇怪的现象，并将在此分享。自iOS13以来，最佳实践是加密您的备份！如果不这样做，您将无法获得基本检查所需的所有数据库。

本次测试中，我采用了多种获取方式进行比较。加粗的为最佳获取方式。

Mac获取测试：

• 使用Finder在Mac上备份 – 加密
• 使用Finder在Mac上备份 – 未设置加密
• 使用Finder在Mac上备份 – 设置了加密但未将密码保存到钥匙串

当备份到Mac并将加密密码保存到钥匙串时，我发现的问题是：Manifest.plist不显示加密标志，并且工具在解析时不会要求输入密码。

Manifest.plist 对比

因此，您几乎什么也得不到！我将所有这些提取内容加载到Cellebrite Physical Analyzer和Magnet AXIOM中进行验证，钥匙串保存密码的做法确实限制了我们检查员的能力。因此，在使用Mac创建备份时请注意，不要让那个复选框保持勾选状态，否则您的检查机会将受到限制。

Windows获取测试： 我首先尝试使用旧版本的iTunes，但它甚至无法识别我运行iOS14的设备。更新后一切正常。

• 使用iTunes备份 – 加密
• 使用iTunes备份 – 未设置加密

这里没有太多异常，只是当我将备份从MobileSync目录移走后，iTunes声称从未向此PC备份过。

iTunes 备份视图

以及几分钟后的备份视图。

备份从MobileSync目录移出后的iTunes视图

请记住，我对这个设备进行了大约10次备份，因为我不断添加数据然后提取数据。细想之下这是合理的，但我知道设备会存储这些信息，所以我很惊讶地看到iTunes仅仅依赖备份目录来获取此信息。底线是：不要相信iTunes摘要屏幕上关于备份的陈述，因为真相存在于iOS设备内部。

在本次测试中，我创建了新的联系人、拨打了电话（包括FaceTime和普通电话）、发送了短信（使用了新的“回复消息”功能）、拍摄了照片、搜索了路线（甚至不得不额外驾驶以充分测试地图）、创建了备忘录，并使用Safari浏览网页。这些是大多数情况下每个人都应检查的关键项目，因此我倾向于从这里开始。我和我的同事将深入研究更复杂的数据（KnowledgeC、位置、健康数据等），并将就此单独撰写博客。

常见数据：

• 联系人： var/mobile/Library/AddressBook/AddressBook.sqlitedb – 商业工具可解析
• 通话记录： var/mobile/Library/CallHistoryDB/CallHistory.storedata – 商业工具可解析

PA 解析的通话记录 PA 通话记录与源文件

• 短信： var/mobile/Library/SMS/sms.db – 主要由商业工具解析。详见下文。
• Safari： var/mobile/Library/Safari/History.db – 主要由商业工具解析。注意：确保您的工具能解析历史记录、Google搜索和标签页历史。

AXIOM 标签页会话 PA Safari 历史记录 PA Safari 历史记录 – 源

• 照片： var/mobile/Media/DCIM/100APPLE/ – 商业工具可解析 – 但是，有一个新表。请看下方。

PA 照片

我们长期依赖的ZGENERICASSET表现在变成了ZASSET。感谢Jared Barnhart首先发现这一点。并感谢Scott Koenig提供的解析查询。https://drive.google.com/drive/folders/1v6T6OqD8eyL1xwHXDMePaXxEZ3IZssp2

• 备忘录： var/mobile/Containers/Shared/AppGroup/group.com.apple.notes/NoteStore.sqlite – 商业工具可解析

新增文件与路径

• 地图： var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1 var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1_deviceLocalCache.db

Apple Maps是最大的变化，老实说，我以为我又找不到它们了。如果您不确定我指的是什么，请阅读我先前关于Apple Maps的博客。我花了无数个小时试图定位数据，您知道可悲的是什么吗？我甚至不喜欢Apple Maps。我更喜欢Waze。然而，作为一名研究员，我必须测试所有东西。让我们回顾一下Apple Maps的历史。

• 历史： mapsdata – 是直到iOS 8为止地图的主要存储文件
• GeoHistory.mapsdata – 从iOS 8到iOS 11（大约）是地图的主要存储文件。在iOS12期间转向云存储，然后在iOS13又回来存储在这里 – 再次请参考我之前的博客 – 《格林奇如何偷走了Apple Maps数据……还是他只是把它们藏起来了？》以及《先是格林奇，现在是复活节兔子！Apple Maps躲在哪里？》
• MapsSync_0.0.1 – 新出现的文件 – 这是存储iOS 14地图数据的主要文件。

根据我的测试，MapsSync_0.0.1似乎只保留最后15条历史记录。这大约是3-5次路线/查询/搜索。我多次转储我的设备以确认这一点。让我们看看。

这是我最初提取数据时的样子。

Apple Maps 数据 – DB Browser for SQLite

仅仅两次Apple Maps搜索之后，它变成了这样。

Apple Maps 数据 – DB Browser for SQLite

坏消息是，我测试的所有工具都无法解析此文件。好消息呢？这里有一个查询供您使用。用您选择的工具来解析它。请注意，下面的“创建时间”将反映设备升级到iOS14的时间。因此，这不是搜索发生的时间。要获取该信息，您需要检查GeoHistory.Mapsdata – 存储此历史信息的protobuf。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
ZHISTORYITEM.ZROUTEREQUESTSTORAGE AS "Journey BLOB",
ZMIXINMAPITEM.ZMAPITEMSTORAGE as "Map Item Storage BLOB"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM

在检查输出时，我对结果稀少感到困惑，这时我意识到无论我搜索什么，数字15都保持不变。它似乎是事务性的。另外，我检查了所有坐标，意识到类型“coordinates of search”除非被选中，否则不会显示为“navigation journey”。例如，我搜索了UMMC（在我最终转储中，此数据库不再包含该记录），但“coordinates of search”仍然存在。一组坐标是马里兰大学医学中心（我导航去的地方），另一组是密西西比大学医学中心，我从未选择过它。

好消息是 – GeoHistory.mapsdata包含了在iOS13中进行的历史搜索！如果您在MapsSync_0.0.1数据库中看不到这些，请返回检查protobuf以查找感兴趣的位置。下面我们可以看到对UMMC的搜索，这些搜索已不存在于MapsSync_0.0.1，但在这里存在。

PA 中的 Protobuf 视图

您问zrouterequeststorage中存储的那些BLOB呢？嗯，它们存储了您的起始位置和最终目的地。相当重要，对吧？这就是确切的旅程。

嵌入在 Apple Maps 中的 BLOB 嵌入在 Apple Maps 中的 BLOB

这些BLOB是protobuf，特别感谢Jon Baumann熬夜为我修复他的脚本。您可以在此处找到他的脚本来解析这些棘手的家伙。https://github.com/threeplanetssoftware/sqlite_miner/tree/protobuf

以下是我的文件的一些示例输出。请注意，它并不完美（他花了几分钟时间完成），并且可能存在误报。

SQlLte-Miner-.pl 输出

可以使用Protoc来查看protobuf。有很多脚本可以提供帮助。Cheeky4n6Monkey推荐的一个是https://github.com/mildsunrise/protobuf-inspector。

另一个考虑是回到您的工具中进行搜索。Cellebrite Physical Analyzer有一个内置按钮可以在二进制BLOB中搜索。我在这里进行了两次搜索。一次搜索我家的街道（此处不分享），另一次搜索我导航到/搜索的位置（chantilly）。

在 PA 中搜索二进制 BLOB

另一种选择是将上面提供的查询中的BLOB转换为十六进制，以便您看到输出并得到提醒。同样，这是一种偏好。感谢Jared Barnhardt的建议！

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
hex(ZHISTORYITEM.ZROUTEREQUESTSTORAGE) AS "Journey BLOB(hex)",
hex(ZMIXINMAPITEM.ZMAPITEMSTORAGE) as "Map Item Storage BLOB(hex)"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM

BLOB 输出为 HEX – DB Browser for SQLite

我计划继续深入研究Apple Maps，并在发现更多信息时撰写更多博客。目前，如果您转储运行iOS14的设备，请使用此查询。也不要害怕根据您的需求修改它！您会看到许多我无法填充有价值信息的列。

关于iMessage，您现在可以回复对话中的单个部分。下面的屏幕截图显示了这在设备上的显示方式。

回复消息

数据库中新增了两个名为thread_originator_guid和thread_originator_part的列，这似乎是当前工具尚未解析的部分，它提醒您回复的是哪条消息。我尚未确定thread_originator_part的含义。

SMS 回复至 – DB Browser for SQLite SMS 回复至 – DB Browser for SQLite

请参考手机上的屏幕截图以整合所有信息。在工具跟进之前，这里有一个查询可以让您部分解决问题。它并不完美，我计划尝试合并它们。也许我的某个朋友会帮忙写一个脚本（呼唤Brigs、Ian和Cheeky4n6Monkey！）。下面的查询已针对iOS14更新。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

SELECT message.rowid,
chat_message_join.chat_id,
message.handle_id,
message.text,
message.thread_originator_guid,
message.thread_originator_part,
message.service,
message.account,
chat.account_login,
chat.chat_identifier,
case when LENGTH(chat_message_join.message_date)=18 then
datetime(chat_message_join.message_date/1000000000 + 978307200,'unixepoch','localtime')
when LENGTH(chat_message_join.message_date)=9 then
datetime(chat_message_join.message_date + 978307200,'unixepoch','localtime')
else 'NA'
END as "Message Date",
case when LENGTH(message.date_read)=18 then
datetime(message.date_read/1000000000 + 978307200,'unixepoch','localtime')
when LENGTH(message.date_read)=9 then
datetime(message.date_read+978307200,'unixepoch','localtime')
else 'NA'
END as "Date Read",
case when message.is_read=1
then 'Incoming'
when message.is_read=0
then 'Outgoing'
end as "Message Direction",
case when LENGTH(chat.last_read_message_timestamp)=18 then
datetime(chat.last_read_message_timestamp/1000000000+978307200,'unixepoch','localtime')
when LENGTH(chat.last_read_message_timestamp)=9 then
datetime(chat.last_read_message_timestamp + 978307200,'unixepoch','localtime')
else 'NA'
END as "Last Read",
attachment.filename,
datetime(attachment.created_date+978307200,'unixepoch','localtime') AS "Attachment Date",
attachment.mime_type,
attachment.total_bytes
FROM message
left join chat_message_join on chat_message_join.message_id=message.ROWID
left join chat on chat.ROWID=chat_message_join.chat_id
left join attachment on attachment.ROWID=chat_message_join.chat_id
order by message.date_read desc;

底线 – 苹果并未腐烂。我花费在研究写博上的日子都是为了我的家人，直到我按下提交按钮！请进行研究并分享！验证是关键。我们都需要这样做！创建测试数据并亲自尝试。如果您发现错误，请报告给供应商。如果您发现空白，请报告，并找到可以构建工具来解析它的人。在DFIR领域，教育和分享是我们的工作。祝您在iOS 14上狩猎愉快！您可能很快就会公开看到这张图片！