TLSトラフィックの復号化
環境：
Nintendo 3DS用のプロトコルをリバースエンジニアリングしたい。ただし、実装ではTLSが使用されるため、リバースエンジニアリングが困難になります。現在、デスクトップのイーサネットとデスクトップのワイヤレスカードを経由して実際のインターネットに接続する「テスト用wifi」に予備のルーターを使用しているため、3DSとの間でパケットを傍受できます。
私が調査したもの：
- MITM
- プロキシ
ロードブロッキング：
- 3DSに疑わしい証明書を受け入れるように強制することはできません。
- 証明書を偽造することはできません。
- 私は実際の秘密鍵を盗もうとはしません（プロトコルを知った後は、あまり興味がありません）。
- ハードウェアが不足しているため、コンソールのRAMからセッションキーを読み取ることができません。
可能な解決策：
- 私は、プロトコルが何らかのHTTPの形式であることをほぼ100％肯定しています（おそらくヘッダーを介したものでしょう）。したがって、暗号化がXOR=に基づいている場合は、少なくとも鍵の一部を取得できる可能性がありますか？暗号についてはよく知りません。
- プロキシ、CAサーバーインスタンスをセットアップして[デスクトップのHostファイルをこのサーバーインスタンスにポイントする]、ニンテンドーの証明書をインストールしてから、公開鍵を自分の秘密鍵で上書きし、次に3DSの証明書を任天堂と通信するためのプロキシ。 TSLがどのように機能するかを完全に把握していないため、これが機能するかどうかはわかりません。
- さらに暗号化されたデータを生成できる場合、ブルートストレングスは実行可能なオプションですか？
tl; dr-サーバーの秘密キーなしでこのデータを復号化する方法、またはRAMをクラックしてセッションキーを見つける方法はありますか？サーバーの証明書と私の3DSのクライアント証明書。
任天堂が物事を失敗させなかったなら、あなたは成功しないでしょう。 TLSプロトコル は、外部からの検査や変更を防ぐために正確に意味します。
TLS（SSLとも呼ばれます）について詳しく知りたい場合は、ウォークスルーとして この答え を読んでください。プロトコルをリバースエンジニアリングするには、主に4つの方法があります。
Nintendo 3DSが偽のサーバー証明書を受け入れるようにしてください。これが@MrSecの答えの本質です。通常、TLSクライアントは、クライアントにインストールされている「信頼できるCA」のセットに関してサーバーの証明書を検証します。そのセットに独自のCAを追加できる場合は、クライアントが受け入れる偽の証明書を作成できます。
任天堂の実装が TLSに対する既知の攻撃 の1つに対して脆弱かどうかを確認します。結局のところ、コンソールファームウェアの更新は、汎用コンピューターの修正よりもまれである傾向があるため、いくつかの脆弱性が潜んでいる可能性があります。明るい面では、そのパスを選択して成功すれば、暗号化について多くのことを学ぶでしょう。
たぶん、いくつかの「異常な」状況では、コンソールはTLSなしで同じプロトコルを実行すると確信することができます。デプロイされたソフトウェアの多くには、開発チームが「本番環境でのビルド」を実行するときにそのデバッグモードを削除するのを忘れたため、非表示のデバッグモードが残っています。
他のことをしてください。たとえば、コンソールは外部サーバーに接続します。 PCからそのサーバーに接続し、serverの回答に基づいて、コンソールをまったく意味することなくプロトコルの詳細を計算することができます。
もちろん、RAM、または少なくともコンソール（プロトコル実装）によって実行されるコードへのアクセスは、はるかに簡単です。コンソールから盗む「秘密鍵」は必ずしも必要ではないことに注意してください。 TLSでは、証明書と秘密鍵は通常サーバー側にあります。
3DSにCA証明書をインストールできますか？その場合、これはうまくいくかもしれません：
- インストール Owasp ZAP
- 3DSにOwasp ZAP CA証明書をインストールする
- プロキシとしてOWASP ZAPを使用するように3DSを構成する
- OWASP ZAPでトラフィックを検査
デバイスが Pinning を実装している場合、これはまだ機能しません。その場合、あなたのプロジェクトはちょっと運命にあるかもしれません。
HTTPでないことが判明した場合は、完全なMiTM攻撃を試すことができます。これには、偽のCAを設定し、 mitmproxy を使用して、3dsからのすべてのトラフィックをルーティングします。