タイトル：フロントエンドリクエストと応答パケットのデコードプロセスのデコード1回

つまり、最後の復号化の後、開発チームはあきらめませんでした。数ヶ月後、返品パッケージも暗号化されました。圧縮および難読化されたフロントエンドJS

観察によると、最初はサーバーが同じRSA+AES暗号化を実行し、RSA暗号化された後にキーとIVを送信し、AESによってAESによって暗号化されたデータフィールドを送信することも当初考えられています。しかし、私たちにとって、これは実際にシステムへのs辱を増し、システムのセキュリティを減らします。これにより、フロントエンドがRSA+AESを復号化できるため、RSA秘密キーは間違いなくフロントエンドに存在します！

操作を開始1。古いルールでencryptivフィールドを検索し、疑わしい復号化された部分を見つけ、ブレークポイントを押してログインリクエストを送信します

バープはパケットをつかみ、パケットを返し、データフィールドを抽出します

ブレークポイントでRSAによって復号化されたAEのキーとIVの値を抽出します

nとaをフロントエンドのブレークポイントからキーとして、ivをGuigui JSデバッグツールに入れて、復号化を試みます。復号化は成功しているため、このアイデアに問題はありません。つまり、ここでのコードは、サーバーからencryptivとencryptkeyを元のキーとAEのオフセットに復号化します。

2。復号化コードによると、RSA秘密キー（p.D）を見つけ、ディスプレイは不完全です。 Ctrl+Fをコピーして、完全なRSA秘密キーを検索します。

jsencrypt.jsスクリプトを使用して、エラーを解読して見つけます。その理由は、元のJSがブラウザのウィンドウとナビゲーターメソッドを呼び出すからです。これら2つは、ブラウザウィンドウ情報とマウスの位置情報を取得して乱数を生成するために使用されます

検索を通じて、誰かが最初に元のJSENCRYPTを変更し、ウィンドウとナビゲーターの方法を削除して使用したことがわかりました。投稿アドレス：https://bbs.125.la/forum.php?mod=viewthreadtid=14113049

Guigui JSを使用したデバッグ

3.最後のステップは、自動暗号化と復号化スクリプトの書き込みを改善することです。古いルールは、依然としてmitmweb+burpの組み合わせです。ブラウザは最初にげっぷをし、次にPythonスクリプトを実行するためにMITMWEBに二次プロキシを燃やし、次にサーバーに送信します。一般的なアイデアは次のとおりです。

実際、私は90％が完成し、残りの10％が自動化されたスクリプトを書くために書かれていると思いました。その結果、JSの復号化への呼び出しが成功しなかった理由のために、この10％が数日かかりました。その後、それは解決され、一般的に言えば、AESアルゴリズムJS、およびPythonと関係があります。この大きなピットについて詳細に説明することができます。今日この部分をスキップしてください。

最後に、最後のスクリプトで、フロントエンドの復号化をキャンセルするコードとMITMWEBへのコードをキャンセルして、応答を復号化するのに役立ちました。

デバッグは成功し、げっぷは快適で、プロセス全体が明確でした。

ちなみに、ハァッ？検証コードハハハでフロントエンドに戻るリスクの高い脆弱性を見つけました。しかし、私は親切です。この暗号化と復号化はしばらく解決されないので、今は金曜日ですので、それを開発と呼び、来週の月曜日に脆弱性を修正しましょう。次回まで特定の新しいコードパーツを離れましょう。この大きなピットを復号化するときは、AESと一緒に話しましょう。