Burp 証明書のインストール

Tip

AWS Hackingを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hackingを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
Az Hackingを学び、実践する: HackTricks Training Azure Red Team Expert (AzRTE) HackTricks Trainingの全カタログ を閲覧して、評価トラック（ARTA/GRTA/AzRTA）と Linux Hacking Expert (LHE) を確認してください。

HackTricksをサポート

ADB経由でのシステム全体プロキシ

すべてのアプリがインターセプタ (Burp/mitmproxy) 経由でトラフィックをルーティングするよう、グローバルなHTTPプロキシを設定します：

# Set proxy (device/emulator must reach your host IP)
adb shell settings put global http_proxy 192.168.1.2:8080

# Clear proxy
adb shell settings put global http_proxy :0

Tip: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners).

仮想マシン上で

まず最初に、Burp から Der 証明書をダウンロードする必要があります。これは Proxy –> Options –> Import / Export CA certificate で行えます。

証明書を Der 形式でエクスポートし、Android が認識できる形式に変換します。注意：AVD の Android マシンに burp 証明書を設定するためには、このマシンを 起動 する際に -writable-system オプションを 付ける 必要があります。
例えば、次のように実行できます:

C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system

次に、burps の証明書を設定するには:

openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
mv burp_cacert.pem $CERTHASHNAME #Correct name
adb root && sleep 2 && adb remount #Allow to write on /syste
adb push $CERTHASHNAME /sdcard/ #Upload certificate
adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correct location
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
adb reboot #Now, reboot the machine

マシンが再起動を完了したら、Burp の証明書が使用されるようになります！

Magisk の使用

もしあなたが Magisk でデバイスを root 化している（エミュレータかもしれません）、そしてファイルシステムが読み取り専用でリマウントできず、前の手順で Burp 証明書をインストールできない場合、別の方法があります。

this video で説明されている通り、次のことを行います:

  1. CA 証明書をインストール: DER の Burp 証明書をモバイルに ドラッグ＆ドロップ し、拡張子を .crt に変更して Downloads フォルダに保存し、Install a certificate -> CA certificate に移動する
  • 証明書が正しく保存されたか Trusted credentials -> USER で確認する
  1. システムで信頼されるようにする: Magisk モジュール MagiskTrustUserCerts（.zip ファイル）をダウンロードし、電話に ドラッグ＆ドロップ して、電話の Magisk app を開き Modules セクションへ移動、Install from storage をクリックして .zip モジュールを選択し、インストールが完了したら電話を 再起動 する:
  • 再起動後、Trusted credentials -> SYSTEM に移動して Postswigger 証明書があるか確認する

代替: AlwaysTrustUserCerts (Android 7-16 Beta)

Android 14+ を使用している場合（または Conscrypt Mainline アップデートを受けて /apex/com.android.conscrypt/cacerts を使用するようになった古いデバイスの場合）、Magisk モジュール AlwaysTrustUserCerts はシステム信頼のために必要な bind-mount を自動化します。ユーザー CA をシステム信頼にミラーリングし、Zygote/app 名前空間にマウントを注入することで、アプリが手動で nsenter を使わなくても証明書を参照できるようにします。

  1. まず Burp CA を ユーザー 証明書としてインストールする。
  2. モジュールをインストールして再起動する。
  3. モジュールが選択肢を提供する場合、/system/etc/security/cacerts を /apex/com.android.conscrypt/cacerts にマウントするときに --rbind を選ぶと、他のモジュールによるネストされたマウントが表示されるようになります。

Magisk モジュールの作り方を学ぶ

参照 https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437

Android 14以降

最新の Android 14 では、システムで信頼される Certificate Authority (CA) 証明書の扱いに大きな変化が見られます。

注: Conscrypt Mainline アップデートを受けた一部の Android 12/13 デバイスはすでに /apex/com.android.conscrypt/cacerts を使用しています。そのディレクトリがデバイスに存在する場合、以下で説明するのと同じ APEX 注入手法を使う必要があります。

かつてこれらの証明書は /system/etc/security/cacerts/ に格納され、root 権限のあるユーザーがアクセス・変更できたためシステム全体に即座に反映されていました。しかし Android 14 では格納場所が /apex/com.android.conscrypt/cacerts に移動し、これは /apex パス内のディレクトリであり、性質上イミュータブルです。

APEX cacerts パスを書き込み可能にリマウントしようとすると失敗します。システムがそのような操作を許可しないためです。ディレクトリをアンマウントしたり tmpfs でオーバーレイしようとしてもイミュータブル性を回避できません。アプリケーションはファイルシステムレベルでの変更に関係なく元の証明書データを参照し続けます。この耐性は、/apex マウントが PRIVATE propagation に設定されているためで、/apex 内の変更が他のプロセスに影響しないようになっています。

Android の初期化では init プロセスが起動し、OS の起動と共に Zygote プロセスも開始します。Zygote は新しいマウント名前空間を持つアプリケーションプロセスを起動する役割を担い、その名前空間にはプライベートな /apex マウントが含まれるため、このディレクトリへの変更が他プロセスから隔離されます。

それでも、/apex ディレクトリ内のシステム信頼 CA 証明書を変更する必要がある場合の回避策は存在します。これは /apex を手動でリマウントして PRIVATE propagation を解除し、書き込み可能にする操作を含みます。手順は /apex/com.android.conscrypt の内容を別の場所にコピーし、読み取り専用の制約を取り除くために /apex/com.android.conscrypt をアンマウントし、元の /apex 内に内容を復元する、という流れです。この方法はシステムクラッシュを避けるために迅速な操作が必要です。変更をシステム全体に確実に反映させるには、system_server を再起動することを推奨します。これにより実質的に全アプリが再起動され、システムは整合状態になります。

# Create a separate temp directory, to hold the current certificates
# Otherwise, when we add the mount we can't read the current certs anymore.
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy

# Copy out the existing certificates
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/

# Create the in-memory mount on top of the system certs folder
mount -t tmpfs tmpfs /system/etc/security/cacerts

# Copy the existing certs back into the tmpfs, so we keep trusting them
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/

# Copy our new cert in, so we trust that too
mv $CERTIFICATE_PATH /system/etc/security/cacerts/

# Update the perms & selinux context labels
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*

# Deal with the APEX overrides, which need injecting into each namespace:

# First we get the Zygote process(es), which launch each app
ZYGOTE_PID=$(pidof zygote || true)
ZYGOTE64_PID=$(pidof zygote64 || true)
# N.b. some devices appear to have both!

# Apps inherit the Zygote's mounts at startup, so we inject here to ensure
# all newly started apps will see these certs straight away:
for Z_PID in "$ZYGOTE_PID" "$ZYGOTE64_PID"; do
if [ -n "$Z_PID" ]; then
nsenter --mount=/proc/$Z_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
fi
done

# Then we inject the mount into all already running apps, so they
# too see these CA certs immediately:

# Get the PID of every process whose parent is one of the Zygotes:
APP_PIDS=$(
echo "$ZYGOTE_PID $ZYGOTE64_PID" | \
xargs -n1 ps -o 'PID' -P | \
grep -v PID
)

# Inject into the mount namespace of each of those apps:
for PID in $APP_PIDS; do
nsenter --mount=/proc/$PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts &
done
wait # Launched in parallel - wait for completion here

echo "System certificate injected"

Bind-mounting through NSEnter

  1. 書き込み可能なディレクトリの作成: 最初に、既存の non-APEX システム証明書ディレクトリの上に tmpfs をマウントして書き込み可能なディレクトリを作成します。これは次のコマンドで実行されます:
mount -t tmpfs tmpfs /system/etc/security/cacerts
  1. CA証明書の準備: 書き込み可能なディレクトリを設定した後、使用するCA証明書をこのディレクトリにコピーします。これはデフォルトの証明書を /apex/com.android.conscrypt/cacerts/ からコピーすることを含む場合があります。これらの証明書のパーミッションとSELinuxラベルを適切に調整することが重要です。
  2. Zygote のバインドマウント: nsenter を使用して Zygote の mount namespace に入ります。Zygote は Android アプリを起動するプロセスであり、この手順は以後起動されるすべてのアプリが新しく設定したCA証明書を利用するようにするために必要です。使用するコマンドは:

Tip: If /system/etc/security/cacerts contains nested mounts (common with Magisk modules), use --rbind instead of --bind so those mounts propagate into app namespaces.

nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
# If /system/etc/security/cacerts includes nested mounts, prefer --rbind
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --rbind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

これにより、起動されるすべての新しいアプリが更新された CA 証明書の設定に従うようになります。

  1. 実行中のアプリへの変更の適用: 既に実行中のアプリケーションに変更を適用するには、nsenter を再度使用して各アプリの名前空間に個別に入り、同様の bind mount を実行します。必要なコマンドは次のとおりです:
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. 代替アプローチ - ソフトリブート: 代替手法として、init プロセス (PID 1) に対して bind mount を実行し、その後 stop && start コマンドでオペレーティングシステムをソフトリブートする方法があります。このアプローチは変更をすべての namespaces に伝播させ、各実行中の app を個別に対処する必要を回避します。ただし、再起動の手間があるため、一般的には好まれません。

参考文献

Tip

AWS Hackingを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hackingを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
Az Hackingを学び、実践する: HackTricks Training Azure Red Team Expert (AzRTE) HackTricks Trainingの全カタログ を閲覧して、評価トラック（ARTA/GRTA/AzRTA）と Linux Hacking Expert (LHE) を確認してください。

HackTricksをサポート