來自法國的移動開發商 Applidium 之前成功對 iPhone 4S 與 Siri 服務器的通訊協議進行了反向工程。之后他們發布了一些簡要的通訊協議方面的技術解答，并展示了一些使用 Siri 的語音到文本轉換的范例代碼。 根據他們的研究，Siri 的語音識別工作其實并不是在iPhone 上完成，而是在蘋果的服務器上進行的。也就是說，理論上可以讓 Siri 識別來自任何設備的音頻。用戶使用 iPhone 4S 對 Siri 說話時，手機只是將音頻錄制下來，并通過 Speex 編碼器進行壓縮，然后通過一個特殊的 HTTP 請求把音頻等信息打包傳送給蘋果服務器。隨后服務器會返回一個經過 zlib 壓縮的 plist 二進制文件，其中包含的就是答復數據。 Applidium 開發者們上手的途徑比較簡單，就是在本地網絡中截取 Siri 從 iPhone 發送到服務器的數據，并進行分析。他們建立了一個假冒的 DNS 服務器，以此讓 Siri 把請求發送到自己的服務器上。請求是經過 SSL 加密的，不過他們在 iPhone 中加載了他們自己的 SSL 根證書，這樣便可以使用自己的服務器進行分析了。 在他們的服務器上，運行著一個非常簡單的 HTTP 代.理腳本（用 Ruby 編寫），能夠將發送到蘋果服務器的請求進行延遲，同時將輸入和輸出結果 echo 到 stdout 中，這樣就能知道兩邊都在發送什么數據了。由于需要造出一個自定的 Siri 請求，他們首先要搞清楚信息格式。實際發送的請求比較特殊，并且包含和 HTTP 標準不一致的特征。蘋果使用的是一種被稱作 ACE 的 HTTP 請求方法，這種方法可以使用任意長度的數值內容，包含一個自定的用戶代理字符串，將自己的身份定義為 Assistant。 請求的 header 部分也比較特殊，里面含有設備的唯一身份識別信息。Applidium 的研究者發現，header 中必須含有合法的唯一身份識別信息，否則服務器不會處理此請求，因為目前服務器只接受來自 iPhone 4S 的請求。這對開發第三方 Siri 應用而言是個極大的挑戰。 換句話說，任何 Siri 客戶端在發送請求時都必須含有真實的 iPhone 4S 身份識別信息。而一旦開發者將某個 iPhone 4S 身份識別信息放到他開發的應用中并廣泛傳播，蘋果很可能會屏蔽掉該身份識別信息，以此禁用那款應用。 現在還無法知曉蘋果會如何對待未授權的第三方 Siri 客戶端，我們懷疑會很快將它們拖進黑名單。在蘋果這邊來看，如果突然出現大量計劃之外的設備來使用 Siri 無疑會加重服務器的負擔，而在尚未準備擴展服務器之前，這將影響 iPhone 4S 用戶的使用體驗。 因此我們可以進一步推斷，蘋果目前只允許 iPhone 4S 使用 Siri 的原因并不是硬件限制。所以理論上今后是有可能在老款 iPhone 上看到 Siri 的。 除了設備身份識別方面的數據之外（每臺 iPhone 4S 僅有一個身份），個人開發者們可以自由使用 Applidium 的研究成果，開發自己的應用，前提是蘋果不修改 Siri 的通訊協議。在之后的探索中，有可能發掘出更多 Siri 的功能，不僅限于語音到文本的識別。Applidium 無私奉獻出的代碼讓上手變得簡單了許多，雖說代碼大部分還沒有進行歸檔整理，不過已經很好懂了。 他們公布的范例 Siri 客戶端代碼是用 Ruby 寫的。同時也提供了非常簡單的命令行工具代碼，來使用 Speex 庫生成壓縮音頻數據，以便傳送給蘋果服務器。所有范例代碼已經上傳到了 GitHub
推薦閱讀
國外黑客稱初步實現使用腦波控制Siri完成基本命令
[db:內容簡介]>>>詳細閱讀
本文標題：一起來了解 Applidium 如何破解 Siri 的通訊協議
地址：http://www.sdlzkt.com/a/apple/2013-07-05/275239.html
1/2 1
2 下一頁
網友點評
精彩導讀
科技快報
品牌展示