投屏技術(shù)已經(jīng)被大量用在身邊的產(chǎn)品，比如電視投屏，投影儀，視頻會(huì)議產(chǎn)品中。 在iOS平臺外的其他平臺中都已經(jīng)有非常成熟的標(biāo)準(zhǔn)和實(shí)現(xiàn)。但在封閉的蘋果iOS和Mac系統(tǒng)中，蘋果使用私有的Airplay協(xié)議進(jìn)行多屏互動(dòng)，只開放給自己生態(tài)中的產(chǎn)品。對此相關(guān)技術(shù)限制比較嚴(yán)格，甚至在iOS9中加上了更嚴(yán)格的加密算法，直接導(dǎo)致很多投屏的產(chǎn)品不可用。

iOS中的投屏方案

1.ReplayKit

iOS9中引入了ReplayKit, 讓開發(fā)者有了一定的獲取屏幕數(shù)據(jù)的能力. 并在iOS10和iOS11中繼續(xù)擴(kuò)展了ReplayKit的能力. 但還是有很大的限制, 比如在使用ReplayKit的api時(shí)只能錄制當(dāng)前應(yīng)用的應(yīng)用, 無法在應(yīng)用進(jìn)入后臺之后繼續(xù)錄屏. 如果使用系統(tǒng)級別的屏幕錄制,又無法獲得每一幀的數(shù)據(jù),只能獲得最后錄取的單個(gè)視頻. 這樣對第三方的開發(fā)有了非常大的限制.

2.Airplay

Airplay是蘋果提供的一種多屏互動(dòng)技術(shù), 可以將音頻照片,視頻, 屏幕從iOS設(shè)備或者M(jìn)ac電腦上投射到支持airplay接受的設(shè)備上，如Apple TV。這樣可以將小屏映射到大屏，可以無線音樂，可以圖片分享等等. 但是Airplay屬于蘋果私有協(xié)議方案，設(shè)備間的協(xié)商與傳輸過程都進(jìn)行了加密處理，并不能用于其他平臺中。我們已經(jīng)完整的逆向了Airplay的全部協(xié)議棧，并破解了其加密方案，可以提供跨平臺Airplay接收方案。這樣可以方便實(shí)現(xiàn)跨平臺的多屏共享。

同時(shí)，通過研究，我們也可以通過Airplay Mirroring技術(shù)，做到在iPhone上把自己的屏幕的內(nèi)容投送給當(dāng)前iPhone，在某些情況下這種airplay的破解卻非常有用處,比如手游直播。這中投屏方案使用了iOS原生的投屏能力，并且是完全的軟件方案，非常方便進(jìn)行集成和使用。

Airplay Mirroring實(shí)現(xiàn)原理

下面將介紹Airplay Mirroring接收端的實(shí)現(xiàn)原理，并揭示相關(guān)協(xié)議交互過程。

Airplay Mirroring客戶端的同屏交互過程，分為三個(gè)主要步驟：

設(shè)備廣播與發(fā)現(xiàn)

信息交互與能力協(xié)商

音視頻數(shù)據(jù)接收與解擾

設(shè)備廣播與發(fā)現(xiàn)

Airplay設(shè)備間的廣播與發(fā)現(xiàn)通過Bonjour協(xié)議進(jìn)行。Bonjour也被稱為ZeroConf, mDNS等，可以用來在局域網(wǎng)內(nèi)進(jìn)行數(shù)據(jù)記錄廣播與發(fā)現(xiàn)。該協(xié)議比較成熟，網(wǎng)上可以找到諸多介紹。對于實(shí)現(xiàn)的Airplay（包括Mirroring）接收端而言，首先需要注冊兩類服務(wù)，即airtunes和airplay。 Airtunes服務(wù)主要用來處理廣播視音頻接收能力協(xié)商，是最為重要的服務(wù)內(nèi)容，對應(yīng)Bonjour記錄名稱為'_raop._tcp'，注冊服務(wù)端口不限，一般為了避免沖突，建議采用較高的端口數(shù)；Airplay服務(wù)主要用來兼容傳統(tǒng)的streaming等服務(wù)，對應(yīng)記錄名稱為'_airplay._tcp'，注冊端口一般為7000。

具體的服務(wù)廣播內(nèi)容，可以進(jìn)行局域網(wǎng)抓包，找到對應(yīng)記錄內(nèi)容。

當(dāng)接收端通過Bonjour廣播器服務(wù)能力后，發(fā)送端（如iPhone等各類iOS設(shè)備）就可以發(fā)現(xiàn)該接收端。

信息交互與能力協(xié)商

當(dāng)發(fā)送端發(fā)現(xiàn)接收端后，可以開始信息交互與能力協(xié)商過程。該部分協(xié)議協(xié)議格式類似rtsp協(xié)議格式。主要分為兩個(gè)階段，設(shè)備匹配與和能力協(xié)商。

當(dāng)發(fā)送端鏈接服務(wù)端后，設(shè)備匹配過程即開始。通信雙方會(huì)進(jìn)行fairplay加密協(xié)議進(jìn)行信息交換，當(dāng)完成信息交換后，客戶端后續(xù)必須使用這部分信息來處理加密過的密鑰，才能獲得進(jìn)一步視音頻解密密鑰。在iOS9之后，在fairplay過程之前，增加一個(gè)設(shè)備匹配過程，即pair-setup、pair-verify過程，其主要算法是較為標(biāo)準(zhǔn)的非對稱公鑰交換算法。

當(dāng)兩端成功匹配后，開始進(jìn)行能力協(xié)商與信息交換，這些信息包括，設(shè)備名稱、代號，音視頻接收相關(guān)端口配置，視頻接收能力以及加密密鑰等，相關(guān)信息使用binary plist格式進(jìn)行封裝。

可以參考https://github.com/espes/Slave-in-the-Magic-Mirror找到相關(guān)協(xié)議交互的一些細(xì)節(jié)。

音視頻數(shù)據(jù)接收與解密

雙方協(xié)商成功后，發(fā)送端開始向接收端發(fā)送視音頻數(shù)據(jù)，mirroring數(shù)據(jù)是通過TCP進(jìn)行發(fā)送，為h.264 ES流格式。音頻是通過RTP協(xié)議進(jìn)行發(fā)送，根據(jù)內(nèi)容的不同音頻編碼為ALAC或者AAC-ELD。

音視頻流都是通過AES進(jìn)行了加密處理，密鑰需要通過上面一步的進(jìn)過信息交互后的fairplay模組對setup過程中接收到的加密密鑰進(jìn)行解密，獲得的AES解密需要的IV和KEY，然后經(jīng)過AES解擾，即可以獲得最終的視音頻清流。

其他需要注意的地方

Airplay沒過Session傳送過來的視頻h264碼流，只有開頭一個(gè)關(guān)鍵幀. 因此這種情況并不適合直播這種需要固定GOP的場景. 還需要做進(jìn)一步的轉(zhuǎn)碼的工作，或者直接在壓縮域進(jìn)行處理，獲得合理的GOP結(jié)構(gòu)。

我們對Airplay相關(guān)協(xié)議的逆向工程已經(jīng)封裝成了跨平臺的類庫和框架, 支持windows/Mac/Android/iOS/linux, 在自己內(nèi)部產(chǎn)品中使用已經(jīng)非常穩(wěn)定, 如果有需要可以聯(lián)系我們. 也歡迎各類技術(shù)與應(yīng)用場景討論。我的郵箱leeoxiang#http://gmail.com