闘魚アプリサインチェック迂回
転載先:http://www.secbuff.com/ios/215.html?d=3
0×00説明
闘魚は自分の大好きな生放送プラットフォームで、よく闘魚でlol試合を見て、武漢のインターネット企業なので、逆に闘魚を見て、署名検査ができるかどうかを見ました.
まず、私たちは正常にアプリにログインして、正常にアプリの各種ページをロードすることができて、ログインする時にQQ番号でログインしてみて、正常に授権ページに来ます.次の図を示します.
0×01署名検証分析
一般的なAPPの署名検証には、ローカル検証、ネットワーク検証、ローカル検証+ネットワーク検証の3種類があり、ローカル検証もJava層とNative層に分かれています.では、APPの署名チェックがあるかどうかを分析する一般的な方法は、まずAPPを逆コンパイルし、直接コンパイルしてから署名し、APPを実行してフラッシュ脚があるかどうかを確認したり、toastを弾いて署名エラーを提示したりすることです.闘魚の署名検証に問題がある場合はネットワークに接続できません.QQで補助検証を試みてみると、署名検証があることが明らかになります.以下の図です.
0×02署名分析
まず、闘魚を起動するときにバッグをつかんで、不審な点を発見しました.
ヘッダヘッダヘッダにdy-signのフィールドがあり、署名検証中のネットワーク検証かどうかを推測できますか?取得したapp検証値をサービス側に渡して判断し、正しく正規版appであれば、そうでなければ偽造appです.では、appを直接逆コンパイルして、何の修正もせずに、自分の署名したappを起動してdy-signを前に取得してみましょう.
戻り200が表示されますが、後で入るとネットワークのロードに失敗しすぎて、ローカル検証がある可能性があります.
前述したように,偽造署名を用いたappを発見した場合.中に入るとサーバーに接続できない、ロードに失敗したというメッセージが表示されるので、まずこのエラーメッセージに基づいて探してみましょう.
上の画像は、プロンプト情報に基づいて、このプロンプトメッセージに対するstring nameを見つけ、string nameに基づいてこのプロンプト情報のID番号を見つけ、グローバルにID番号を検索し、どこに呼び出しがあるかを確認し、一歩一歩分析します.
呼び出したjavaコードをjd-guiで調べたところ、0 x 7 f 080304がある場所は見つかりませんでした.0 x 7 f 080304を10進数にして検索できますが、卵用はありません.
0×03 androidシステム取得署名方法の分析
署名検証を行うには、appがシステムのapiメソッドを呼び出す必要があることを知っています.
packagemanagerクラスの実装を見てみましょう.
次は署名全体を実現するプロセスです.
前の分析ではsignatureやgetpackageinfogetpackagemanagerなどのキーワードを手動で検索して署名を見つける場所をsmaliコードで対応するコードを修正すれば迂回できますが、この方法は面倒で、グローバル検索で大量のキーワード情報が得られ、一つ一つ見るのに時間がかかります.このとき、私たちは直接hookシステムのjava.security.Signatureというインタフェースを通じて、直接システムが取得した署名を永遠にtrueに戻すことができます.そうすれば、appの署名検査を迂回し、xposedを直接使うのは簡単です.
この方法でappの署名検証を完全に迂回することができる.
0×04まとめ
Androidのオープンソース特性のため、攻撃者と保護者はまったく緯度的に存在しないと言えるが、移動端の安全にとって、多くのもの(反転試験戦略、補強)はソースコードを研究することで迂回し、攻撃者の緯度を達成することができる.署名検証はappの最も基本的な最も重要な保護方法と言える.appの署名が逆方向に迂回されると、悪意のある攻撃者は任意の悪意のあるコードを書き込み、様々なプラットフォームに公開してユーザーにダウンロードさせ、悪意のある行為(メールブロック、カメラの盗み、録音、支払い監視、デバイスマネージャのアンロード防止など)を実現することができる.
署名保護には、ローカル検証+ネットワーク検証が好ましい.ローカル検証にはnativeレイヤで検証が必要であり、対応するsoを補強処理する必要がある.ネットワーク検証には、アップロードされたsignパラメータを処理し、ユーザーがパケットを直接ブロックして検証を迂回することを避ける必要がある.
0×00説明
闘魚は自分の大好きな生放送プラットフォームで、よく闘魚でlol試合を見て、武漢のインターネット企業なので、逆に闘魚を見て、署名検査ができるかどうかを見ました.
まず、私たちは正常にアプリにログインして、正常にアプリの各種ページをロードすることができて、ログインする時にQQ番号でログインしてみて、正常に授権ページに来ます.次の図を示します.
0×01署名検証分析
一般的なAPPの署名検証には、ローカル検証、ネットワーク検証、ローカル検証+ネットワーク検証の3種類があり、ローカル検証もJava層とNative層に分かれています.では、APPの署名チェックがあるかどうかを分析する一般的な方法は、まずAPPを逆コンパイルし、直接コンパイルしてから署名し、APPを実行してフラッシュ脚があるかどうかを確認したり、toastを弾いて署名エラーを提示したりすることです.闘魚の署名検証に問題がある場合はネットワークに接続できません.QQで補助検証を試みてみると、署名検証があることが明らかになります.以下の図です.
0×02署名分析
まず、闘魚を起動するときにバッグをつかんで、不審な点を発見しました.
ヘッダヘッダヘッダにdy-signのフィールドがあり、署名検証中のネットワーク検証かどうかを推測できますか?取得したapp検証値をサービス側に渡して判断し、正しく正規版appであれば、そうでなければ偽造appです.では、appを直接逆コンパイルして、何の修正もせずに、自分の署名したappを起動してdy-signを前に取得してみましょう.
戻り200が表示されますが、後で入るとネットワークのロードに失敗しすぎて、ローカル検証がある可能性があります.
前述したように,偽造署名を用いたappを発見した場合.中に入るとサーバーに接続できない、ロードに失敗したというメッセージが表示されるので、まずこのエラーメッセージに基づいて探してみましょう.
上の画像は、プロンプト情報に基づいて、このプロンプトメッセージに対するstring nameを見つけ、string nameに基づいてこのプロンプト情報のID番号を見つけ、グローバルにID番号を検索し、どこに呼び出しがあるかを確認し、一歩一歩分析します.
呼び出したjavaコードをjd-guiで調べたところ、0 x 7 f 080304がある場所は見つかりませんでした.0 x 7 f 080304を10進数にして検索できますが、卵用はありません.
0×03 androidシステム取得署名方法の分析
署名検証を行うには、appがシステムのapiメソッドを呼び出す必要があることを知っています.
packageInfo = context.getPackageManager().getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES ); packagemanagerクラスの実装を見てみましょう.
次は署名全体を実現するプロセスです.
前の分析ではsignatureやgetpackageinfogetpackagemanagerなどのキーワードを手動で検索して署名を見つける場所をsmaliコードで対応するコードを修正すれば迂回できますが、この方法は面倒で、グローバル検索で大量のキーワード情報が得られ、一つ一つ見るのに時間がかかります.このとき、私たちは直接hookシステムのjava.security.Signatureというインタフェースを通じて、直接システムが取得した署名を永遠にtrueに戻すことができます.そうすれば、appの署名検査を迂回し、xposedを直接使うのは簡単です.
public void initZygote(StartupParam startupParam) throws Throwable { XposedHelpers.findAndHookMethod( "java.security.Signature" ,null, "verify" , byte[].class,new XC_MethodHook(){ protected void afterHookedMethod(MethodHookParam param) throws Throwable { XposedBridge.log( "disabled verifysignature......" ); param.setResult(Boolean.TRUE); } }); この方法でappの署名検証を完全に迂回することができる.
0×04まとめ
Androidのオープンソース特性のため、攻撃者と保護者はまったく緯度的に存在しないと言えるが、移動端の安全にとって、多くのもの(反転試験戦略、補強)はソースコードを研究することで迂回し、攻撃者の緯度を達成することができる.署名検証はappの最も基本的な最も重要な保護方法と言える.appの署名が逆方向に迂回されると、悪意のある攻撃者は任意の悪意のあるコードを書き込み、様々なプラットフォームに公開してユーザーにダウンロードさせ、悪意のある行為(メールブロック、カメラの盗み、録音、支払い監視、デバイスマネージャのアンロード防止など)を実現することができる.
署名保護には、ローカル検証+ネットワーク検証が好ましい.ローカル検証にはnativeレイヤで検証が必要であり、対応するsoを補強処理する必要がある.ネットワーク検証には、アップロードされたsignパラメータを処理し、ユーザーがパケットを直接ブロックして検証を迂回することを避ける必要がある.
：SecBuff » APP