Applidiumのモバイルアプリ開発者は、Siriが使用する通信プロトコルを把握することができたため、iPhone 4S IDの入手先がわかっていてもAppleが知らない場合、この音声認識エンジンは理論的にはAndroidを含む任意のデバイスで実行できます「ブラックリスト」に追加します。
Siriの重要な要素は、プログラムがサーバーと通信する方法です（Siriはインターネットにアクセスできる場合にのみ機能します）。 トラフィックはTCP、ポート443経由でサーバー17.174.4.4に送信されます。 デスクトップからサーバー
https://17.174.4.4/にアクセスしようとすると、
guzzoni.apple.comという名前の証明書を提示していることがわかります（SRIの
Didier Guzzoniはこの技術の作成者の1人です）。
トラフィックはhttpsで保護されているため、スニファーで聞くことはできません。 Applidiumのスタッフは、最も簡単な方法は偽のhttpsサーバーとdnsサーバーを選択し、Siriからのリクエストを確認することだと判断しました。 もちろん、実際の
guzzoni.apple.com証明書を偽造する
ことはできませんが、偽のhttpsサーバー上の
guzzoni.apple.comで独自の有効な証明書を発行しようとすることはできます。 iPhoneでは任意の認証局からの証明書を電話機に追加できるため、この方法は機能し、Siriが自分のサーバーとコマンドを正常に交換できるようになりました。
その後、ハッカーはSiriプロトコルに冷静に対処することができました。SiriプロトコルはHTTP標準に適合しない珍しい方法を使用します。 タイトルは次のようになります。
ACE /ace HTTP/1.0 Host: guzzoni.apple.com User-Agent: Assistant(iPhone/iPhone4,1; iPhone OS/5.0/9A334) Ace/1.0 Content-Length: 2000000000 X-Ace-Host: 4620a9aa-88f4-4ac1-a49d-e2012910921
ご覧のとおり、通常のGETの代わりにACEメソッドが使用され、URLとして「/ ace」が要求され、
Content-Lengthフィールドはほぼ2 GBで指定されています。
X-Ace-hostフィールドは、何らかの方法でデバイス識別子（GUID）に関連付けられています。
要求本体自体はバイナリ形式で送信されます。 0xAACCEEで始まります。 開発者は、アーカイブされたコンテンツが次に来る、つまり、データが圧縮形式で送信されることを提案しました。 その結果、
zlibアーカイバはアーカイブをバイナリコードで正常に認識しました（AACCEEヘッダーの後の5バイト目から開始）。
解凍されたデータでは、バイナリコードが再び検出されましたが、テキストが含まれています。 個々の言葉の中で、
bplist00は開発者の注目を集めました。 明らかに、これは
plistバイナリを示してい
ます 。 データをさらに詳しく調べた結果、開発者はいくつかの異なるフラグメントを発見しました。
- 0x020000xxxxで始まるフラグメントは「plist」パケットで、xxxxはヘッダーに続くバイナリplistデータのサイズに対応します。
- 0x030000xxxxで始まるスニペットは、接続をサポートするためにiPhoneがSiriサーバーに送信する「ping」パケットです。 ここで、xxはpingのシリアル番号に対応しています。
- 0x040000xxxxで始まるフラグメントは、Siriサーバーがpingに応答してiPhoneに送信する「ポン」パケットです。 ご想像のとおり、xxはパケットのシリアル番号に対応しています。
plistバイナリコンテンツを解読することは大したことで
はなく、
plutil consoleコマンドを使用してMac OS Xで、または
CFPropertyListを使用して他のプラットフォームで自分で行うことができます。
開発者は、Siriが
Speexコーデックで圧縮されたオーディオフラグメントをサーバーに送信し、iPhone 4Sデバイス識別子をあらゆる場所に挿入することを発見しました。 プログラムとサーバーは、わずかな機会に大量の情報を交換します。 たとえば、音声認識が実行されている場合、Appleサーバーは
各単語のタイムスタンプと「信頼レベル」を送信します。
Siriプロトコルでの独立した作業には、Applidiumプログラマーが作成した
ツールキットを使用できます。