iOS14数字取证技术深度解析
本文是对本周正式发布的iOS14系统的初步技术分析。按照以往惯例，我重点关注影响大多数调查的基础数据痕迹，并深入分析苹果系统的技术细节。本文将这部分视为初步探索。
测试环境与方法
在本研究中，我测试了个人可用的工具。如果您发现遗漏了什么，请分享。如果您是供应商并认为缺少某些内容，请与我分享，我将亲自尝试。目前，加密的iTunes备份似乎是最稳定的选择。我知道供应商很快会发布支持iOS14的更新，请耐心等待。
重要提示：如果不加密备份，将无法提取通话记录、苹果地图（某些数据库被提取但为空）、Safari、健康数据以及更多内容！
数据获取技术
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之外，这里没有其他异常情况。
关键技术发现
常见数据痕迹分析：
联系人：var/mobile/Library/AddressBook/AddressBook.sqlitedb - 由商业工具解析
通话记录：var/mobile/Library/CallHistoryDB/CallHistory.storedata - 由商业工具解析
短信：var/mobile/Library/SMS/sms.db - 主要由商业工具解析
Safari：var/mobile/Library/Safari/History.db - 主要由商业工具解析。注意：确保您的工具解析历史记录、Google搜索和标签页历史。
照片：var/mobile/Media/DCIM/100APPLE/ - 由商业工具解析。但是，有一个新表。请看下面。
我们长期依赖的ZGENERICASSET表现在是ZASSET。
笔记：var/mobile/Containers/Shared/AppGroup/group.com.apple.notes/NoteStore.sqlite - 由商业工具解析
新文件和路径
地图：
var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1_deviceLocalCache.db
苹果地图是最大的变化，老实说，我以为我又丢失了它们。MapsSync_0.0.1似乎是事务性的，似乎只保留最后15个历史记录项。
坏消息是，我测试的工具都没有解析此文件。好消息是，这里有一个查询供您使用。使用您选择的工具来解析它。
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
|
存储在"zrouterequeststorage"中的BLOB包含您的起始位置和最终目的地。这些BLOB是protobuf，可以使用专门脚本进行解析。
iMessage技术更新
对于iMessage，您现在可以回复对话的单个部分。数据库中有两个新列：“thread_originator_guid"和"thread_originator_part”，这似乎是工具尚未解析的内容，也是提醒您回复的是哪条消息的原因。
以下是针对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中，教育和分享是我们的工作。
祝您在iOS14上狩猎愉快！