Whatsappの中身は？

世界最大のインスタントメッセンジャーの内部メカニズムに関する当社の研究の出版の方向性に続いて。 今日は、現在の状態のWhatsAppを見ていきます。 実際、過去3年間で内部はあまり変化しておらず、そこの変化は化粧品である可能性が高いです。

この記事では、メッセンジャーのプロトコルを調査し、「WhatsAppは私たちの通信を読むことができますか？」という質問に答え、PHPに必要なすべてのコードを添付する方法を詳しく見ていきます。

一般的な情報

WhatsAppは、メッセージ形式としてXMPPプロトコルの更新バージョンを使用します。 すべてのメッセージは、頻繁に使用される単語を1バイトまたは2バイトのトークンに置き換えることによって圧縮されます（たとえば、「メッセージ」の代わりにバイト0x5fを書き込みます）。

一部のパッケージは、オプションでzlib圧縮されている場合があります。 受信したパケットはAES GCM 256ビットで暗号化され、サーバーに送信されます。

暗号化キーを取得するために、クライアントはノイズプロトコルハンドシェイクを実行します。 ここでそれはよく説明されています。 何らかの理由で、オープン実装のすべての開発者がコードへの実装を拒否し、「サポート終了」ダイを切ったため、修正します。

最初の接続で、完全なハンドシェイクが実行されます。 サーバーへの接続に成功した後、次のセッションで新しいキーが発行されるたびに、キーを交換せずに後で接続が確立されます。

WhatsAppはlibaxolotl（Signal Protocol）を使用したエンドツーエンドの暗号化をサポートし、2つのバージョンがコードに実装されています。最初は暗号化を行い、その後、アライメントを追加してv2と呼びました。 唯一の問題があります-なぜなら 中央集中型のシステムである場合、キー転送はWhatsAppサーバーを経由するため、メッセンジャー開発者が偽の暗号化キーを転送して通信を完全に読み取るための技術的な障害はまったくありません。 ただし、これには遡及効果はありません。後知恵でメッセージを読むことはできません。

ところで、不正な連絡先からメッセージを受信すると、メッセンジャーに「スパムについて苦情を申し立てる」ボタンが表示されます。クリックすると、連絡先をブロックするだけでなく、安全なチャネル（既に開いている！）経由でメッセージテキストを転送します。 アプリケーションコードを完全に調査しないと、この機能が他の場合に使用されないことを保証する方法はありません。

WhatsAppアプリケーションで暗号化キーの信頼性を確認するには、連絡先カードに移動して[暗号化]項目を選択します。その後、アプリケーションは受信者のデバイスでQRコードのスキャンを提供します。 したがって、ところで、WhatsAppプロトコルに基づいてカスタムアプリケーションを作成し、暗号化キーのステータスを常に監視し、「NSA is watching you」または「You are safe」という美しいダイを発行できます。さまざまなインスタントメッセンジャーを考えて、そのうちの1つをアプリケーションはさらに便利になります。

操作アルゴリズムは次のように想定できます。QRコードを表示するデバイスは公開キーをエンコードし、QRコードを読み取るデバイスはキーをデータベース内のキーと比較します。 これは、アプリケーションにブックマークがない場合にのみ、キーを検証する安全な方法です。

送信マルチメディアファイルがWhatsAppサーバーにアップロードされるとき、そこで暗号化されているかどうかについて追加の調査は行いませんでした。 ほとんどの場合、暗号化されていません。 アプリケーション開発者は自分自身を信頼し、ファイルへのリンクはエンドツーエンド暗号化で保護されたチャネルを介して送信されます。

アカウント登録

登録は、v.whatsapp.netドメインに対する3つのhttps要求で行われます（これらは、burpやmitmproxyなどの既知の方法でスパイされる可能性があり、アプリケーションはssl killスイッチの使用をバイパスする証明書のピン留めを使用します）。

v.whatsapp.net/v2/exists?cc=_&in=&id=id_&lg=en&lc=zz
有用なことは何も行わず、この番号が既に登録されているかどうかを確認するために使用されていました（おそらく、誰かがデータベースのソートを開始するまで）

v.whatsapp.net/v2/code?method=sms&cc=_&in=&token=&sim_mcc=mcc&sim_mnc=mnc&id=id_&lg=en&lc=zz&__
実際にアクティベーションSMSコードを要求します。 同様のリクエストを使用して、コールを受信することもできます。 エンドツーエンドの暗号化設定はオプションです-さらに接続するときに設定できます。 トークンは次のようになります。

  md5（ "0a1mLfGUIBVrMKF1RdvLI5lkRBvof6vn0fD2QRSM"。md5（ "21752"）。 "phone"） 

最初の行は、暗号化された文字列のランドスケープです。 アプリケーションの任意のバージョン（21752）に置き換えることができます（最も好奇心が強い人は、まだリリースされていないバージョンに登録しようとすることができます）。アプリケーションコードでは、バージョンからのハッシュは既製ですが、md5ハッシュに似たものがすぐに選択されます。

v.whatsapp.net/v2/register?cc=_&in=&code=__&id=id_&lg=en&lc=zz
このリクエストは、それぞれSMSまたは通話で受信したコードで登録を確認します。

リクエストは、 User-Agent: WhatsApp/2.17.52 iPhone_OS/7.1.2 Device/iPhone_4ます。 トークンを正しく検証するには、おそらく正しいエージェントが必要です。

MITM

これは知られている最初の日ではありません-WA16プロトコル（Chat-API、Yowsup）の実装がいくつかあります。現在のWA20との違いは基本的にノイズプロトコルのみです。 この情報を使用して、復号化されたアプリケーショントラフィックを表示するローカルMITMを開発できます。 なぜなら 最初は、XMPPアプリケーションプロトコル-そこに発生することはすべて、解読されたトラフィックからすぐに理解できるため、逆アセンブラーのジャングルに飛び込む特別な必要はありません。

MITMを起動するには、実際のWhatsAppサーバーとして自分自身を紹介し、完全なハンドシェイクを実行します。その後、アプリケーションはトラフィックをリッスンし、元のwhatsappサーバーにリダイレクトします。 これを行うには、元のアプリケーションを変更する必要があります。

すべての操作は、iPhone 4、iOS 7.1.2、IDA 7、WhatsApp 2.17.52の構成で実行されます。

パッチ適用

1.すべての接続で完全なハンドシェイクを実行します。これにより、生活が大幅に簡素化されます。 メソッド-[NoiseHandshakeManager initWithLoginPayload:clientStaticKeyPair:serverStaticPublicKey:] with serverStaticPublicKeyがResumeHandshake 、 serverStaticPublicKeyがない場合。





serverStaticPublicKeyはレジスタR0に格納され、存在しない場合はFullHandshakeへの移行が実行されます。 そして、この移行を無条件にします。 これを行うには、2バイトを置き換えます



に



結果



デコンパイラでは、条件分岐の1つが到達不能になり、表示されないことがわかります。



2.サーバー署名の検証を無効にします。 元のサーバーの秘密鍵はありません。 この変更がなければ、トラフィックを聞くことはできません。 これを行うには、（bool）メソッドに変更を加えます- [NoiseHandshakeManager validateNoiseCertificate:serverHandshakeStaticPublicKey:] 。



常に1を返す関数が必要です。 これで、レジスターR6からの証明書検証の結果がR0に配置されます。



R0でユニットを書きましょう



結果として、



アプリケーションはすべてのデバッグ情報を使用してコンパイルされるため、さらに名前を変更し、構造を記述し、一般的に逆のプロセスを実行します。パッチを作成する場合、実際には必要ありません。 イメージは、逆コンパイラーの起動直後に表示され、追加の処理は行われません。

iOS 7.1.2は、アプリケーションバイナリファイルの信頼性を検証しないため、すべての変更はアプリケーションファイルで直接行うことができます。 iOSの以降のバージョンでは、実行中のアプリケーションのメモリに同じ変更を加えることができます。

コードを書く...

次に、IDAと長年の骨の折れる努力の助けを借りて、WhatsAppサーバーでNoiseHandshakeを正常に実行するコードを準備します。 次に、偽のサーバーを実装します。すべて同じ暗号化操作を行いますが、逆の順序で行います（簡単に聞こえますが、毎日それを行わないと、まだ頭痛の種です）。 完成したコードはこちらです。

上記のリンクから取得したMITMアプリケーションをコンピューターにダウンロードします。 PHP 5.6をインストールします（別のバージョンも適しています。このバージョンは私の構成で使用されました）。 また、さらに2つのライブラリが必要です。
- 最初
- 二番目

インターセプト接続

現在ではなく、アプリケーションをサーバーに接続するだけです。 アプリケーションはサーバーの1つe％d.whatsapp.net（％dは1〜16の数字、たとえばe5.whatsapp.net）に接続し、それぞれが複数のIPアドレスに解決されます。 300以上のサーバー。 最も簡単な方法は、サーバーのDNS応答を置き換えて、MITMを使用してコンピューターに転送することです。

これを行うには、電話とコンピューターを同じネットワーク上に配置し（文字通りすべてのwifiルーターが行います）、次のホストでbind9をインストールするコンピューターに電話のDNSを配置します。

  $ TTL 86400
 @ IN SOA ns.whatsapp.net。  admin.whatsapp.net。  （
	 2017100500
	 28800
	 7200
	 1209600
	 86400）
 @ IN NS @
 @あなたのIP
 v IN A 184.173.136.86
 v IN A 174.37.243.85
 * IN CNAME @

トラフィックを見る

次に、mitm.phpを編集します。ユーザー名フィールドの電話番号とパスワードフィールドのcck.datファイル（アプリケーションディレクトリにあります）の内容を置き換える必要があります。
php mitm.phpを実行します。 WhatsAppアプリケーションを起動し、次の図を参照してください。



スクリーンショットは、サーバーからの2つのパケットを示しています-成功した認証といくつかの設定に関するメッセージ。 したがって、アプリケーションのすべてのトラフィックはこのように見えます。すべてが読み取り可能であり、さらに、ほとんどの場合、アプリケーションを分解する必要はありません。

FunXMPPを読み取り可能なテキストに変換するアルゴリズムは、すべてのWhatsAppライブラリで利用できます。 最も単純なステートマシンの内部では、ここでは追加でペイントしません。

結論

このアプリケーションは高品質で作成され、最新の暗号化プロトコルを使用していますが、その奥深くには、元々使用されていたejabberdのXMPPが残っています。 アプリケーション開発の現在のベクトルから判断すると、protobufを使用する方が論理的ですが、歴史的な遺産は高すぎます。

このサービスは、大量のメールで長い間苦しんでいました-オープンソースプロジェクトのコードがこれに広く貢献しました。 現時点では、長い間ニュースレターを受信して​​いません-開発者は、許可されていない連絡先に送信されるメッセージの数に制限を課しています。 私の意見では、このアドオン（技術的にはサーバー側に完全に実装されている）が、メーリングリストの愛好家とメール対策部門の従業員（もしあれば）の対立を断固として終わらせたと思います。

純粋に技術的には、このようなアルゴリズムに複雑なものはありません。他のメッセンジャー（hello、Viber、私は少なくとも月に1回はスパムを受け取ります）の開発者にとっては、このテクニックに注意する価値があります。

読んでくれてありがとう、勉強をするのと同じくらい楽しくて面白かったと思っています。