Install Burp Certificate
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
仮想マシン上で
まず最初に、BurpからDer形式の証明書をダウンロードする必要があります。これは、Proxy --> Options --> _Import / Export CA certificate_で行うことができます。
Der形式で証明書をエクスポートし、Androidが理解できる形式に変換します。**AVDのAndroidマシンでBurp証明書を設定するには、このマシンを-writable-system
オプションで実行する必要があります。
例えば、次のように実行できます:
次に、burpの証明書を設定するには:
マシンが再起動を完了すると、Burp証明書が使用されます!
Magiscを使用する
もしあなたがMagiscでデバイスをルート化した(おそらくエミュレーター)、そして前の手順に従ってBurp証明書をインストールできない場合、ファイルシステムが読み取り専用であり、書き込み可能に再マウントできない場合、別の方法があります。
このビデオで説明されているように、次のことを行う必要があります:
CA証明書をインストールする:DER Burp証明書をドラッグ&ドロップして、モバイルで拡張子を
.crt
に変更し、ダウンロードフォルダーに保存し、証明書をインストール
->CA証明書
に進みます。
信頼できる資格情報
->ユーザー
に進んで、証明書が正しく保存されていることを確認します。
システム信頼にする:MagiscモジュールMagiskTrustUserCerts(.zipファイル)をダウンロードし、ドラッグ&ドロップして電話に移動し、電話のMagicsアプリの**
モジュール
セクションに行き、ストレージからインストール
をクリックし、.zip
モジュールを選択し、インストール後に再起動**します:
再起動後、
信頼できる資格情報
->システム
に進み、Postswigger証明書がそこにあることを確認します。
Android 14以降
最新のAndroid 14リリースでは、システム信頼の証明書機関(CA)証明書の取り扱いに大きな変化が見られました。以前は、これらの証明書は**/system/etc/security/cacerts/
に格納されており、ルート権限を持つユーザーによってアクセスおよび変更可能で、システム全体に即座に適用されていました。しかし、Android 14では、ストレージの場所が/apex/com.android.conscrypt/cacerts
に移動され、これは/apex
**パス内のディレクトリであり、本質的に不変です。
APEX cacertsパスを読み書き可能として再マウントしようとすると失敗します。システムはそのような操作を許可しません。一時ファイルシステム(tmpfs)でディレクトリをアンマウントまたはオーバーレイしようとする試みも不変性を回避することはできず、アプリケーションはファイルシステムレベルでの変更に関係なく、元の証明書データにアクセスし続けます。この耐性は、**/apex
マウントがPRIVATE伝播で構成されているためであり、/apex
**ディレクトリ内の変更が他のプロセスに影響を与えないことを保証します。
Androidの初期化にはinit
プロセスが関与しており、オペレーティングシステムを起動すると同時にZygoteプロセスも開始されます。このプロセスは、新しいマウントネームスペースを持つアプリケーションプロセスを起動する責任があり、プライベートな**/apex
**マウントを含むため、このディレクトリへの変更を他のプロセスから隔離します。
それでも、**/apex
ディレクトリ内のシステム信頼のCA証明書を変更する必要がある場合の回避策があります。これは、PRIVATE伝播を削除するために/apex
を手動で再マウントし、書き込み可能にすることを含みます。このプロセスには、/apex/com.android.conscrypt
の内容を別の場所にコピーし、読み取り専用制約を排除するために/apex/com.android.conscrypt
ディレクトリをアンマウントし、その後、内容を/apex
**内の元の場所に復元することが含まれます。このアプローチは、システムクラッシュを避けるために迅速な行動を必要とします。これらの変更をシステム全体に適用するためには、system_server
を再起動することが推奨されており、これによりすべてのアプリケーションが再起動され、システムが一貫した状態に戻ります。
Bind-mounting through NSEnter
書き込み可能なディレクトリの設定: 最初に、既存の非APEXシステム証明書ディレクトリの上に
tmpfs
をマウントすることで、書き込み可能なディレクトリが確立されます。これは次のコマンドで実現されます:
CA証明書の準備: 書き込み可能なディレクトリのセットアップに続いて、使用するCA証明書をこのディレクトリにコピーする必要があります。これには、
/apex/com.android.conscrypt/cacerts/
からデフォルトの証明書をコピーすることが含まれる場合があります。これらの証明書の権限とSELinuxラベルを適切に調整することが重要です。Zygoteのバインドマウント:
nsenter
を使用して、Zygoteのマウントネームスペースに入ります。ZygoteはAndroidアプリケーションを起動する責任を持つプロセスであり、以降に起動されるすべてのアプリケーションが新しく構成されたCA証明書を利用するためにこのステップが必要です。使用されるコマンドは:
これにより、開始されるすべての新しいアプリが更新されたCA証明書の設定に従うことが保証されます。
実行中のアプリへの変更の適用: 既に実行中のアプリケーションに変更を適用するには、
nsenter
を再度使用して各アプリの名前空間に個別に入り、同様のバインドマウントを実行します。必要なコマンドは:
代替アプローチ - ソフトリブート: 代替手法は、
init
プロセス(PID 1)でバインドマウントを実行し、その後にstop && start
コマンドでオペレーティングシステムをソフトリブートすることを含みます。このアプローチは、すべてのネームスペースに変更を伝播させ、各実行中のアプリを個別に対処する必要を回避します。しかし、この方法はリブートの不便さから一般的にはあまり好まれません。
参考文献
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated