本文由石冀编译，Roe校对，转载请注明。
早前我看到一篇关于 “纽约市计划将使用airdrop空投色情图片定为犯罪[1]”，不禁让我思考，如果警察对发送方或接收方的iphone进行分析，究竟会发现什么？
测试场景
本次使用两部测试手机，一部iPhone 7和一部iPhone 6。iPhone 7属于“David”，iPhone 6属于“Jen”。在这个测试中，两个设备都在iOS 11上进行此测试。Jen将向Jen发送未经请求的松鼠照片。
AirDrop通过蓝牙和Wi-Fi的临时点对点网络工作。当用户试图向某人发送一个文件时，设备将确定谁在范围内以及谁当前正在接收 AirDrop 连接。AirDrop 可以设置为仅限联系人或所有人或接收关闭。David将AirDrop 设置为 “所有人”，他会受到一些“惊喜”。
为了给David发送松鼠照片，Jen使用iPhone原生照片应用程序的共享功能并选择一个设备来隔空投送这张松鼠图片。隔空投送的范围内唯一开启了AirDrop并处于接收模式的设备是David的iPhone。
Jen选择了David的手机并发送了图片。在David的设备上，他会收到一个弹出窗口，他可以选择拒绝或接受。
AirDrop ID
对AirDrop分析来说，重要的是AirDrop ID。AirDrop ID可在/private/var/mobile/Library/Preferences/com.apple.sharingd.plist找到。关键词 “sharingd “非常重要，因为很多Continuity artifacts都可以通过搜索该进程名称找到。这个plist文件应该可以在iTunes备份和任何商业取证工具中找到。
Jen的AirDrop ID是3DAA769F9F23。
David的AirDrop ID是E7D713098E3B，同时可以看到DiscoverableMode被设置为“所有人”。(Jen的iPhone识别的参数没有这个类别，她的这一栏被设置为只有联系人。)
接收者（David ）设备相关记录
假设接收者是可能向警察投诉的人，我们会首先看一下这个iPhone，以确定哪些工件会持续存在，以及它们是否显示归属于某个设备和/或所有者。
很少有设备上的工件会真正显示这种连接发生。让我们来看看，如果我有这个案子，我会探索一些主要的工件。
Unified Logs（统一日志）
译者注：Unified Log 系统提供了一个全面且高性能的 API 来捕获跨系统所有级别的遥测数据。该系统将日志数据集中存储在内存和磁盘上，而不是将该数据写入基于文本的日志文件。Unified Log 系统适用于 iOS 10.0 及更高版本、macOS 10.12 及更高版本、tvOS 10.0 及更高版本以及 watchOS 3.0 及更高版本。该系统取代了 Apple System Logger (ASL) 和 Syslog API。
日志可以显示大量数据并且非常详细。不幸的是，这些统一日志在iOS设备上没有得到备份。从设备上提取它们的唯一方法是获得设备的物理文件转储（越狱/Cellebrite CAS/GrayKey）。(虽然这些统一的日志文件可以使用iOS设备上的sysdiagnose程序收集。但是根据Apple文档，则需要用AirDrop把这个日志文件从设备上复制下来。这不是一个恰当的取证方法，你需要用法律认可的手段获得数据。)
在David的iPhone上的这个例子中，可以看到共享进程开始扫描并试图找到发起连接的设备（连续性连接）。在这个过程中，你也会看到很多wirelessproxd和bluetoothd活动，因为AirDrop是使用蓝牙和Wi-Fi服务。你还会看到对AWDL或苹果无线直接链接的引用。
顺着日志往下看，你会开始遇到一些潜在的识别信息。我们现在开始看到包含Jen的设备名称 “Jen 的iPhone “的记录。密切注意第一条记录，你会看到一个看起来像MAC地址的东西，但它既不是蓝牙地址也不是Wi-Fi地址。这个地址在每次连接时都会生成不同的地址，因此不是一个理想的归因数据点。
回到设备的名称上。这可能会引导你走向正确的方向，然而任何人都可以给他们的设备起任何名字。例如，我可以把我的iPhone X称为 “三星S9″，没有识别信息，坦率地说，这个设备甚至不支持AirDrop功能。
接下来的几个高亮部分（红色），显示了AirDrop连接的开始。我们可以看到一个传入的请求，并开始看到包括Jen的iPhone的AirDrop ID，3DAA769F9F23的记录。这是我认为可能归因的地方。根据我的经验，这个ID在不同的连接和不同的设备上似乎是一致的。也许有可能将其与一个苹果ID或特定设备联系起来。然而，我还没有找到这种联系。据我所知，它不是序列、UDID或各种MAC地址的一部分，还需要更深入研究。
接下来，紫色显示的是关于文件传输的更多元数据，包括传输状态、媒体类型、源设备名称、源应用程序和相关传输GUID。
在这些元数据记录之间，显示正在将文件传输到/var/mobile/Downloads/com.apple.AirDrop/BA40D8CF-54E6-4B09-8F2F-717FB638174E/Files。无论用户选择接受还是拒绝，照片仍然被传输到设备上。
最后，用户会收到一个关于AirDrop照片的提醒。在这一记录之后是有关如何通过警报音和振动以声音和物理方式向用户提醒连接的更多详细信息。
Jen发来的照片被David “拒绝 “之后，则可以在下面的记录中看到，”selectedAction “现在显示为 “Decline”，并且已经开始清理过程。突出显示的蓝绿色是AirDrop连接被关闭。
如果用户接受了AirDrop的照片，日志会看起来像下面这样。该文件将在元数据记录中被 “接受”。最后，由于它是一张照片，默认应用程序Photos试图把它导入它的文件和数据库，AirDrop连接也在此时关闭。
照片数据库
由于照片被转移到用户的照片数据库中，因此可被查找。这个文件会被iTunes和商业取证工具所备份。照片数据库位于物理设备上的/private/var/mobile/Media/PhotoData/Photos.sqlite。
Jen设备上的文件名是IMG_0007.JPG，然后在David的手机上被重命名为IMG_0110.JPG。原始文件名可以在ZADDITIONALASSETATTRIBUTES表中的ZORIGINALFILENAME列中找到。
值得注意的是，导入的照片将携带与Jen设备上的原始照片相同的EXIF数据，事实上它是完全相同的照片（哈希值应该匹配）。文件大小和一些时间戳会被带入照片数据库。其他元数据项目也可用于确定来自另一设备的照片，如高度/宽度等。假设它来自不同的设备系列，像素则可能不同。
在ZGENERICASSET表中，存有图片的高度/宽度，但是更新了一些时间戳以匹配通过 AirDrop 导入的时间。ZDATECREATED时间戳与照片的原始创建时间一致。ZCLOUDASSETGUID与上述日志中最后几个条目中看到的GUID相符。这个数据库中似乎没有任何归因数据。
发送者（Jen）设备相关记录
在极少数情况下，发送者的设备信息被获取，相关的日志记录如下：
Unified Logs（统一日志）
大部分的日志看起来与接收方相似。下面的样本显示了连接到David的AirDrop ID，E7D713098E3B的分享过程，并显示了他的iPhone设备名称。同样，MAC地址似乎并不一致，每次连接时都会改变。
再往下几行，我们可以看到照片的一些文件转换，IMG_0007.JPG（这显然是不需要的）。接下来是一个带有David的iPhone的AirDrop ID的AirDrop传输记录。
结论
目前，由于缺乏归因工件（有待进一步研究），这将导致很难对AirDrop的滥用进行归因。在最好的情况下，如果警察得到了所有设备，然后进行连接配对进行取证。然而，这将需要访问文件系统转储服务，如Cellebrite CAS[3]，GrayKey from GrayShift[4]或进行越狱以获得最准确的分析。
参考链接：
[1] https://www.cultofmac.com/593752/airdop-dick-picks/
[2]https://github.com/mac4n6/Presentations/blob/master/The Cider Press – Extracting Forensic Artifacts from Apple Continuity/The Cider Press – Extracting Forensic Artifacts from Apple Continuity.pdf
[3] https://www.cellebrite.com/en/services/advanced-extraction-services/
[4] https://graykey.grayshift.com/
[5]http://www.mac4n6.com/blog/2018/12/3/airdrop-analysis-of-the-udp-unsolicited-dick-pic
原文始发于微信公众号（数据安全与取证）：性骚扰事件中的AirDrop（隔空投送）日志分析
