iOS统一日志分析——Airdrop相关知识
本文由石冀编译，Roe校对，转载请注明。
在本文中，我想测试一下，当某些文件从一个未知的来源通过AirDrop被发送时，它们会是什么样子。许多学校已经从AirDrop收到了炸弹威胁，我想看看是否有办法发现追查这些威胁来自哪里。
在本次测试中，你会看到来自两个iOS设备的日志记录：
• 发送者：Elwood’s iPhone
• 接收者：miPhone11
注意：这篇文章主要针对iOS。对于macOS，你可能需要在这些查询中添加--info来获取类似的信息。
从AirDrop的基础知识开始 - 首先我们需要确定每个用户的AirDrop ID。AirDrop ID在设备的生命周期内是不一致的，会一直发生变化。最后（当前）的AirDrop ID可以在iOS设备上的/private/var/mobile/Library/Preferences/com.apple.sharingd.plist中找到。我甚至看到由于一些设备的AirDrop功能不常用，导致这个plist中没有AirDrop ID。下面的查询可以提供统一日志中仍保存的AirDrop ID。
log show system_logs.logarchive --predicate 'eventMessage contains "AirDrop ID"'对于当时使用的是什么可发现模式，快速的查询方法是寻找 "SharingDaemon"，它包含一些共享元数据信息。
log show system_logs.logarchive --predicate 'eventMessage contains "SharingDaemon State"'查询结果中包含许多有用的信息：
• 设备品牌/型号
• iOS版本
• 电池状态
• 可发现性模式（所有人/仅联系人/关闭）
• 屏幕状态
• 解锁状态
• 无线网络连接状态
在我们设计的场景中，我们假设接收方在有关时间内将其可发现模式设置为 "所有人"。当前的模式也可以在com.apple.sharingd.plist这一文件中看到。还有一种查看可发现模式的方法是使用这个查询（原作者示范时使用了两个--info参数，查询时只需一个即可）：
log show --info system_logs.logarchive --predicate 'eventMessage contains "Scanning mode"'在发送端设备（Elwood’s iPhone）的记录
分享手段
使用AirDrop的第一个迹象是它是如何被启动的。这个过程被称为 "ShareSheet"。这是呈现给用户的窗口，让他们选择如何分享一个项目。在这个截图中，我想从照片应用中分享一张照片。我们可以选择AirDrop、信息、邮件、笔记等。下面是一组可以对所选照片进行的其他活动。
这个查询可以向我们显示一个文件是从什么应用中被分享的。每个共享项目可能有不同的共享选项。查询结果将显示在Airdrop、笔记、地图或Safari链接中可能进行的操作。
首先寻找“Activating com.apple.sharing.sharesheet”的信息，这个信息能够清晰地表明有文件要被分享了。将与要分享的特定应用程序建立连接，在这个例子中是com.apple.mobileslideshow(Photo)（黄色高亮）。
红色高亮显示的项目正在寻找可以分享的人。本次使用的设备是一个测试设备，没有联系人；因此没有人被推荐。
紫色和蓝色高亮显示的项目是用户在ShareSheet视图中应该看到的分享以及其他操作。
绿色高亮的信息显示，用户选择了AirDrop。
在粉色的信息中，以“Item:”开头并带有GUID的消息显示照片需要更多的准备（文件格式转换、缩略图创建等）。这在共享便签、地图和Safari链接中没有看到。这种特定的活动可以通过使用GUID进行过滤，如下图所示。深绿色突出显示的项目提供了用于准备的临时文件路径，但最重要的是文件名应与Photos.sqlite数据库中的项目文件名一致（IMG_6782.JPG）。
log show system_logs.logarchive --predicate 'eventMessage contains "74745469-9184-442C-B49D-5BE37CDD8CAA"'更多关于AirDropped、便签、地图和Safari链接的分享方法的例子显示在下面。注意每个应用程序的活动的不同。
便签
地图
Safari 链接
Airdrop 发送文件
有时我们看到有文件试图被分享，并不一定意味着它真的被发送和接收。这个过程的第一部分是找到一个人去使用AirDrop发送文件。我将使用下面的查询来浏览其中的一些条目。
log show system_logs.logarchive --predicate 'category = "AirDrop"'在上面的截图中，我把默认的样式改为更加紧凑的样式（通过在查询中加上 参数 --style compact [1]），以便在截图中更合适。这显示了iPhone试图通过Bonjour和AWDL[2]发现已知和未知联系人。突出显示的是找到我的MacBook Air（Airdrop ID：eb4f5a53391b）的条目。注意黄色高亮显示的AWDL IPv6地址。这些似乎在接收端被缓存了（寻找包含 "com.apple.p2p: Caching peer: "的消息）。看来AWDL IPv6/MAC地址的轮换相当频繁。这些是将两台设备配对在一起的另一种方式（与AirDrop ID一起），但这些不会被永久保存，你需要两台设备来做这个分析。
现在，我们有了AirDrop联系人，那么就可以通过照片从Elwood's iPhone发送一张照片到miPhone11（IMG_6782.JPG）。
以“startSending”开始的信息（黄色）就是被AirDrop的文件。它显示了它正在发送的项目或文件以及接收者ID和会话ID。Receiver ID是这个项目被发送到的设备的AirDrop ID，而Session ID则跟踪这个AirDrop会话。
绿色显示，AirDrop连接已经开始，但深绿色显示无法建立连接。在测试中，miPhone11的AirDrop ID陷入了一个奇怪的缓存状态，ID是错误的（3603f73a17de）。我第一次尝试AirDrop这张照片时，失败了。它最终发现了正确的ID（ecc57b722d8）。发送端设备显示了一个 "Waiting… "的信息，文件传输无法完成。
第二次图片发送成功。注意miPhone11的AirDrop ID改变了，现在是04f30cbdcb55。这些ID一直在变化。它还识别出设备可以处理HEIC文件格式的实时照片，所以它发送了HEIC文件而不是JPG文件。
现场照片的ShareSheet信息如下。通过匹配GUIDs可以找到这些信息。用查询语句过滤6C85AC86-BEF2-42BC-9862-4982211791DF（来自上面的截图）即可找到与该文件传输相关的其余操作。
log show system_logs.logarchive --predicate 'eventMessage contains "A79A3C4F-AF63-486E-A7FC-4173753B12E2"'下面是传输其他文件的例子：
便签
这些记录显示有一个标题为“This is a threatening note!”的笔记被分享，但没有笔记本身的内容。
地图（分享定位）
分享地图定位时只显示标题但不显示确切的地址。
Safari 链接
发送一个Safari链接显示了域名，但没有关于URL的具体细节。
同样地，当Safari链接指向一个PDF文件时：
发送同样的链接，但作为一个PDF文件发送时，就根本不显示域名。
当只看统一日志时，这些项目失去了背景。此时必须将这些操作与其他应用程序的数据库或记录（照片、笔记、地图、Safari历史等）相关联，以提供相关的信息。
在接收端设备（miPhone11）的记录
我们可以通过一个简单的AirDrop查询来找到所有相关的条目。
log show system_logs.logarchive --info --predicate 'category = "AirDrop"'收到文件的用户可以选择接受或拒绝。这些选择都记录在统一日志中。
对于一个传入的连接，AirDrop连接是用一个标识符（0x101495960）建立的。在这个记录之后，有很多行详细说明了它是什么类型的文件以及它来自哪里。要知道用户是否接受或拒绝了传输，我们需要关注“userResponse”部分。绿色显示的条目是向用户展示的弹出式警报，以进行这一操作。
一旦用户选择了接受，传输就会继续，并在该文件的默认应用程序中打开。这个例子显示照片被导入并在照片（com.apple.mobileslideshow）中打开。一旦完成，AirDrop连接就终止了。这张照片可以通过在Photos.sqlite数据库的ZGENERICASSET表中寻找“16C753E1-309A-46FD-A742-998D7A31047E”的ZUUID并寻找相关的文件名。
如果用户拒绝AirDrop传输，同样的信息会显示拒绝或取消，AirDrop连接也会终止。
下面的查询语句一次性包含了哪些传输是由谁发起的，它们在哪里接受或拒绝，以及公开的信息。
log show system_logs.logarchive --predicate 'category = "AirDrop" and (eventMessage contains "New incoming transfer" or eventMessage contains "Opening URLs:" or eventMessage contains "alertLog: idx:")' --style compact每一个灰色高亮显示的部分都是来自Elwood's iPhone的传入连接。一些传输有一个“Opening URLs”条目，为发送的内容提供了更多的信息，特别是当涉及到地图和Safari链接时。需要注意的是，不能仅仅因为你看到一个像“Elwood's iPhone”这样的主机名，就断定传输者是Elwood，因为设备的主机名非常容易修改。
我花了很多时间试图在“受害者”的设备上找到能够将AirDrop动作归于一个特定的发送设备的确凿的证据。似乎真的没有一个静态标识符能够识别一个特定的地址。AirDrop ID、AWDL IPv6/MAC地址是在设备之间配对这些行动的唯一方法，但你需要两个设备都能进行这种类型的关联。当然，这在大多数调查中可能是很棘手的。即使你能够访问这些设备，数据也会很快被刷新，因此你可能只有几天时间来获取这些日志。
原文链接：
http://www.mac4n6.com/blog/2020/6/5/analysis-of-apple-unified-logs-quarantine-edition-entry-11-airdropping-some-knowledge
参考链接：
[1] https://www.mac4n6.com/blog/2020/5/4/analysis-of-apple-unified-logs-quarantine-edition-entry-7-exploring-usbmsc-devices-with-style
[2] https://owlink.org/wiki/#what-is-apple-wireless-direct-link-awdl