Sapito

作者：Sebastian Garcia ([email protected], @eldracote), Veronica Valeros ([email protected], @verovaleros)

关于 Sapito

Sapito 是一个用 Python 编写的组播 DNS（mDNS）嗅探器和解释器。Sapito 从 pcap 文件或网络接口中嗅探数据包，并解释其发现的内容。这意味着 Sapito 能够理解 mDNS 查询和应答，从而解析这些消息的含义。它还可以识别某些设备，例如识别 MacOS 电脑以及多种 iPad。颜色编码的输出有助于突出显示重要信息。

如果你发现了一个 bug，请连同该工具的输出一起报告至 [email protected]。如果你有包含问题数据包的 pcap 文件，那么在提交 bug 报告时一并发送将会非常有帮助。

Docker 镜像

Sapito 在 DockerHub 上提供了一个包含最新版本的公共 Docker 镜像，该镜像在 Linux 系统上运行良好（尚不支持 MacOS）。

运行 Sapito：

docker run --rm --network host --name sapito -it stratosphereips/sapito:latest  python3 sapito.py -i <interface>

关于某些服务的背景信息

关于 Bonjour 服务

._airplay._tcp.local

这是用于启用视频内容 AirPlay 的网络服务的 Bonjour 通告。也就是说，这允许 iOS 设备将 Apple TV 发现为“远程显示器”，并可在其上播放视频。

._mediaremotetv._tcp.local

这是使 Apple TV 遥控器能够工作的网络服务之一——即用于从 iPhone 和 iPad 远程控制 Apple TV 设备的 App 或控制中心内置功能。该服务通过网络上的 Bonjour 进行通告，以确保 iOS 设备能够发现 AppleTV。

._companion-link._tcp.local

该服务似乎并未被 Apple 记录在案，但似乎与让 AirPlay 2 系统正常工作有关。

._raop._tcp.local

该网络服务称为远程音频输出协议（Remote Audio Output Protocol）。它本质上是在说明 AppleTV 充当 AirPlay 音频接收器。这一 Bonjour 通告允许 iOS 设备将 Apple TV 发现为可以发送音频的“扬声器”。

._sleep-proxy._udp.local

这是一个 Bonjour 休眠代理（Sleep Proxy）。其思路是，AppleTV 可以为当前处于低功耗模式的其他设备响应各种网络查询，以降低能耗。例如，它可能是一台 Mac，提供共享的 iTunes 资料库或共享打印机。当 Mac 处于睡眠模式时，AppleTV 可以为这些服务器应答网络请求——例如，允许用户列出网络上可用的共享打印机。然而，当用户选择打印某些内容时，AppleTV 会唤醒 Mac 并将请求转交给它。

_homekit._tcp.local

这是一个与 HomeKit 相关的网络服务，HomeKit 是 Apple 用于与家中设备通信并加以控制的系统。可以想象为可控灯泡、窗帘、门铃等等。在这种设置中，AppleTV 充当代理，使用户即使不在家也能远程控制设备，即使这些设备可能仅支持蓝牙且超出范围。请注意，网络上的普通 HomeKit 设备会以 _hap._tcp 的形式通告，而非此服务。

._touch-able._tcp.local

这是使 Apple TV 遥控器能够正常工作的另一个网络服务。该服务涉及设备认证。也就是说，例如，如果你想在 Apple TV 上播放 YouTube 视频，Apple TV 可以要求在允许播放之前对该设备进行认证。在实践中，认证过程是 Apple TV 在电视上显示一个 PIN 码，用户在 iOS 设备上输入这个 PIN 码。该 PIN 码通过以“touch-able”通告的服务进行传输，以对设备进行认证。

为什么有些数据包在同一包中既有问题又有答案？

因为已知答案抑制（Known-Answer Suppression）¹：

已知答案抑制

   当组播 DNS 查询方发送一个它已经知道部分答案的查询时，它会用
   这些已知答案填充 DNS 查询消息的答案区。

   通常，这仅适用于共享记录（Shared records），而不适用于唯一记录（Unique
   records），因为如果组播 DNS 查询方的缓存中已经至少有一条唯一记录，
   那么它就不应期望再收到针对此问题的其他不同答案，因为它已有的唯一
   记录已经构成了完整答案，因此它没有理由再发送该查询。相比之下，
   缓存中拥有一些共享记录并不一定意味着组播 DNS 查询方不会收到
   针对此查询的更多答案，正是在这种情况下，使用已知答案列表来抑制
   重复发送查询方已经知道的冗余答案是有益的。