测试场景

本次使用两部测试手机，一部 iPhone 7 和一部 iPhone 6。iPhone 7 属于 “David”，iPhone 6 属于 “Jen”。在这个测试中，两个设备都在 iOS 11 上进行此测试。Jen 将向 David 发送未经请求的松鼠照片。

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

点击数：445