web-dev-qa-db-ja.com

JSONデータの復号化

コンテキスト

私は、さまざまなiOSネイティブアプリが内部でどのように機能するかを調査することにより、Webセキュリティについてさらに学習しようとしています。 Burp SuiteをMITMツールとして使用して、アプリとの間で送受信されるネットワークトラフィックをスニッフィングしており、iPhoneにはSSL Kill Switch 2をインストールして、証明書のピン留めをバイパスしています。私のような初心者にとって、すべてが内部でどのように機能するかを見るのは非常に興味深く、驚くべきことです。

ほとんどのアプリで何の問題もありませんでした。これには、いくつかのモバイルバンキングアプリなど、高度なセキュリティが必要な一部のアプリが含まれます。SSLが解除されるとすぐに、すべてがプレーンテキストで表示されます。興味深いことに、一部のモバイルゲームは私に苦労しています。

チャレンジ

傍受されたトラフィックは、暗号化されたJSONファイルのようです。例えば、

{
"F4q6i9xe":{"aV6cLn3v":"542668","Hhgi79M1":"ynB7X5P9"},
"a3vSYuq2: {"Kn51uR4Y":
"f3SQ5sySeaoDupGhGmCD9MKt0V4naBjXXR+jDEjqU1gmL32FgS8v1/6vy61RFO/rwmXwFYZHfTRgV2XujI6U7fESlcSZjMjdeiULExVg0uFmnSgiYA5040hBtuxfFqn+lP1ZCsvnua2IQHoYZDBagkr8I9VZVxQbzivc7rv5d17qscgnD2Jd4BBImn+ohuTpxPEC2H2sLBpAldLe/5EAbXUIkF8griS73lvjyWhmHubZguNUa9EzOCH8o0UPwo5BLB8Fz7xok1GE85/wwSzrlyapQw76/U/RJBF+/0YQ75BACuE4/SfIknim9XZk2EspKrCOu/Gi2K+7pHS+jytfXHR6zTjmeMyV2o967MUVXag="}
}

私がやったこと

私が正しく理解すれば、私は今、解読の領域にいます。私がグーグルから見つけたいくつかの分析的アプローチを使用して、ここに私の発見のいくつかがあります（いくつかは経験者にとって非常に明白で些細なように見えるかもしれません）：

  1. アプリから送信されるすべてのリクエストは、この正確な形式/構造です。暗号化されたキー名は常に同じで、値のみが異なります。

  2. キーaV6cLn3vの値は、増え続けるため、ある種のタイムスタンプに対応しているようです。

  3. キーHhgi79M1に対応する値はタイムスタンプに基づいたチェックビットであると以前に思っていましたが、そうではありません。タイムスタンプが異なっていても、ゲームで同じアクションを実行すると、同じ値になります。ただし、アクションが異なれば、値も異なります。

  4. キーKn51uR4Yの値は、実際のペイロードがある場所です。暗号化の下にあるJSONだと思いますが、よくわかりません。

  5. ペイロードの/記号は、データのセグメントの区切り文字のようです。 2番目のセグメント/6vy61RFO/は、タイムスタンプに基づくチェックビットのようです。ゲームで2つの同じアクションを実行すると、タイムスタンプとペイロードのこの特定のセクションを除いて、ほぼ同じ2つのJSONが生成されるためです。

  6. ペイロードの暗号化は、署名の末尾が=（ 's）であるため、Base64またはAESと何らかの関係があり、異なるペイロードの長さは常に4の倍数です。後者が何かを意味するかどうかはわかりません。

  7. 使用されている暗号化キーは一定のようです。別のセッションや別のデバイスで変更されることはありません。

質問

これまでの分析では正しいですか？ここからどこへ行けばいいですか？これらの分野の知識はほとんどないので、次のステップは何なのかわかりません。アプリを逆コンパイルし、バイナリを調べて、解読キー/関数が見つかるかどうかを確認する必要があると思います。しかし、私にはわかりません。

今後もたくさんのことを学んでいくことは承知していますが、とても楽しんでいるので気にしないでください。トピックやURLの一覧にすぎない場合でも、いくつかの助けをいただければ幸いです。に。

2015年11月23日更新

アプリの復号化されたバイナリをダンプし、stringsコマンドを実行してから、Pythonスクリプトを作成しました暗号化キーの抽出に成功しました。

aesdecryption
5
saulgoodman

私はあなたが今のところ正しいと言いますが、これは今のところ推測しているだけです（おそらく正しいですが:)）。

はい、アプリケーションバイナリのリバースエンジニアリングは次のステップだと思います。暗号化関数とキーを特定したら、Pythonなどの暗号化関数を再実装して、必要に応じて値を復号化/暗号化できます。

そう、

  1. アプリケーションバイナリを入手してください。（電話からそれを抽出する（脱獄する必要がある場合があります）、またはiTunesからIPAをダウンロードします。詳細 こちら ）

  2. アプリケーションで「文字列」を実行する。それは多くの興味深い文字列をもたらす可能性があります暗号化キーをリストするかもしれませんまたはどのアルゴリズムが使用されているかについての手がかり。

  3. スタティックデバッガーを使用する、IDA Proや Hopper （ARMをサポートする必要があるなど）などのバイナリを確認します。 運が良ければ関数名があり、探しているものを見つけるのに大いに役立ちます。そうでない場合は、既知の暗号定数を検索バイナリ。それについての私の答えをチェックしてください ここ 。 this と this も確認してください。暗号関数で使用されている定数を見つけた場合は、その定数がアクセス/使用されている場所の相互参照を使用できます。最終的に、キーは、暗号関数で使用されているパラメーターまたは静的変数として検出されます。

  4. 他のすべてが失敗した場合は、動的デバッガを使用（GDBなど）を実行し、電話で実行されているプロセスにアタッチして、そこから作業する必要があります。最終的に暗号化されることが確実にわかっているデータを見つけて、暗号化されるまでそのデータにアクセスする関数呼び出しを追跡する。

Reverse Engineering と Crypto のstackexchangeサイトを忘れないでください。もちろん、Googleはたくさんのグーグル！ ;）

3
Dominik Antal

私はあなたが正しい軌道に乗っていると思います。アプリバイナリの解凍と分析は、次のステップです。アプリ開発者として、私はいくつかの理論を投げ出し、おそらくそれらがあなたを助けるでしょう。

これは完全に暗号化された要求を含むメタデータjsonのように見えるという事実のため、aV6cLn3v値はおそらくいずれかのトランザクションIDです（前のトランザクションを参照しています。有効なタイムスタンプには小さすぎるように見えます。また、タイムスタンプがHTTPヘッダーに含まれている可能性があるため、JSONリクエストのメタデータに追加する必要があります）。もう1つのフィールドは、アプリが既に持っている特定のデータの状態に対して現在生成されている、デルタのリクエスト（モバイルデータの使用量を節約する）に役立つハッシュ、または何らかのメソッド識別子の可能性があります。

ワイルドゲスを取る必要がある場合、少なくともこのJSONのキーの暗号化を解除すると次のようになります。

{
    "metadata" : {"transactionId" : "542668", "delta" : "ynB7X5P9"},
    "request" : {"body": "encrypted data goes here"}
}

アプリを確認してもまったく害はありませんが、サーバーに手動でリクエストしないでください（地域の法律によって異なります）。

1
Justin Beale