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

　　推薦閱讀

　　國外黑客稱初步實現(xiàn)使用腦波控制Siri完成基本命令

[db:內(nèi)容簡介]>>>詳細閱讀

本文標題：一起來了解 Applidium 如何破解 Siri 的通訊協(xié)議

地址：http://m.sdlzkt.com/a/apple/2013-07-05/275239.html

 1/2    1  2 下一頁