iOS Airplay Screen Mirroring 投屏技术详解

投屏技术已经被大量用在身边的产品, 比如电视投屏, 投影仪, 视频会议产品中. 在iOS平台外的其他平台中都已经有非常成熟的标准和实现. 但在封闭的苹果iOS和Mac系统中, 苹果使用私有的Airplay协议进行多屏互动, 只开放给自己生态中的产品. 对此相关技术限制比较严格，甚至在iOS9中加上了更严格的加密算法, 直接导致很多投屏的产品不可用.

iOS中的投屏方案:

1, ReplayKit

iOS9中引入了ReplayKit, 让开发者有了一定的获取屏幕数据的能力. 并在iOS10和iOS11中继续扩展了ReplayKit的能力. 但还是有很大的限制, 比如在使用ReplayKit的api时只能录制当前应用的应用, 无法在应用进入后台之后继续录屏. 如果使用系统级别的屏幕录制,又无法获得每一帧的数据,只能获得最后录取的单个视频. 这样对第三方的开发有了非常大的限制.

2, Airplay

Airplay是苹果提供的一种多屏互动技术, 可以将音频照片,视频, 屏幕从iOS设备或者Mac电脑上投射到支持airplay接受的设备上，如Apple TV。这样可以将小屏映射到大屏，可以无线音乐，可以图片分享等等. 但是Airplay属于苹果私有协议方案，设备间的协商与传输过程都进行了加密处理，并不能用于其他平台中。我们已经完整的逆向了Airplay的全部协议栈，并破解了其加密方案，可以提供跨平台Airplay接收方案。这样可以方便实现跨平台的多屏共享。

同时，通过研究，我们也可以通过Airplay Mirroring技术，做到在iPhone上把自己的屏幕的内容投送给当前iPhone，在某些情况下这种airplay的破解却非常有用处,比如手游直播。这中投屏方案使用了iOS原生的投屏能力，并且是完全的软件方案，非常方便进行集成和使用。

下面将介绍Airplay Mirroring接收端的实现原理，并揭示相关协议交互过程。

Airplay Mirroring客户端的同屏交互过程，分为三个主要步骤：

1, 设备广播与发现

2, 信息交互与能力协商

3, 音视频数据接收与解扰

设备广播与发现:

Airplay设备间的广播与发现通过Bonjour协议进行。Bonjour也被称为ZeroConf, mDNS等，可以用来在局域网内进行数据记录广播与发现。该协议比较成熟，网上可以找到诸多介绍。对于实现的Airplay（包括Mirroring）接收端而言，首先需要注册两类服务，即airtunes和airplay。 Airtunes服务主要用来处理广播视音频接收能力协商，是最为重要的服务内容，对应Bonjour记录名称为'_raop._tcp'，注册服务端口不限，一般为了避免冲突，建议采用较高的端口数；Airplay服务主要用来兼容传统的streaming等服务，对应记录名称为'_airplay._tcp'，注册端口一般为7000。

具体的服务广播内容，可以进行局域网抓包，找到对应记录内容。

当接收端通过Bonjour广播器服务能力后，发送端（如iPhone等各类iOS设备）就可以发现该接收端。

信息交互与能力协商:

当发送端发现接收端后，可以开始信息交互与能力协商过程。该部分协议协议格式类似rtsp协议格式。主要分为两个阶段，设备匹配与和能力协商。

当发送端链接服务端后，设备匹配过程即开始。通信双方会进行fairplay加密协议进行信息交换，当完成信息交换后，客户端后续必须使用这部分信息来处理加密过的密钥，才能获得进一步视音频解密密钥。在iOS9之后，在fairplay过程之前，增加一个设备匹配过程，即pair-setup、pair-verify过程，其主要算法是较为标准的非对称公钥交换算法。

当两端成功匹配后，开始进行能力协商与信息交换，这些信息包括，设备名称、代号，音视频接收相关端口配置，视频接收能力以及加密密钥等，相关信息使用binary plist格式进行封装。

可以参考https://github.com/espes/Slave-in-the-Magic-Mirror找到相关协议交互的一些细节。

音视频数据接收与解密:

双方协商成功后，发送端开始向接收端发送视音频数据，mirroring数据是通过TCP进行发送，为h.264 ES流格式。音频是通过RTP协议进行发送，根据内容的不同音频编码为ALAC或者AAC-ELD。

音视频流都是通过AES进行了加密处理，密钥需要通过上面一步的进过信息交互后的fairplay模组对setup过程中接收到的加密密钥进行解密，获得的AES解密需要的IV和KEY，然后经过AES解扰，即可以获得最终的视音频清流。

其他需要注意的地方:

Airplay没过Session传送过来的视频h264码流，只有开头一个关键帧. 因此这种情况并不适合直播这种需要固定GOP的场景. 还需要做进一步的转码的工作，或者直接在压缩域进行处理，获得合理的GOP结构。

作者：notedit

想要了解更多请加qq：2645837520