安装 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 配置系统范围代理

配置全局 HTTP 代理，使所有应用的流量通过你的拦截器 (Burp/mitmproxy) 路由：

# 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

提示：在 Burp 中，将监听器绑定到 0.0.0.0，这样 LAN 上的设备就能连接（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

Once the 机器重启完成，Burp certificate 就会被其使用！

使用 Magisk

如果你是用 Magisk root 了你的设备（可能是模拟器），并且你因为 filesystem 是只读的 无法重挂载为可写而无法按照上面的方法安装 Burp 证书，还有另一种办法。

在 this video 中说明，你需要：

  1. 安装 CA certificate：只需将 DER Burp 证书 拖放 到手机中并更改扩展名为 .crt，使其存储在 Downloads 文件夹，然后进入 Install a certificate -> CA certificate
  • 进入 Trusted credentials -> USER 检查证书是否已正确存储
  1. 使其成为 System trusted：下载 Magisk 模块 MagiskTrustUserCerts（一个 .zip 文件），将其 拖放 到手机，打开手机上的 Magisk 应用到 Modules 部分，点击 Install from storage，选择该 .zip 模块并安装，安装完成后 重启 手机：
  • 重启后，进入 Trusted credentials -> SYSTEM 并确认 Postswigger cert 已存在

替代方案：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 作为 user 证书安装。
  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 发布中，系统对 system-trusted 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 进程，它在启动操作系统时也会启动 Zygote 进程。该进程负责以包含私有 /apex 挂载的新挂载命名空间启动应用进程，从而将该目录的更改与其他进程隔离开来。

尽管如此，仍有一种变通方法可用于修改 /apex 目录内的 system-trusted 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 的挂载命名空间。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 certificates 设置。

  1. 将更改应用到正在运行的应用程序: 要将更改应用到已在运行的应用，需再次使用 nsenter 逐个进入每个应用的 namespace 并执行类似的 bind mount。所需命令是：
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
  1. 替代方法 - Soft Reboot：一种替代方法是在 init 进程（PID 1）上执行 bind mount，然后使用 stop && start 命令对操作系统进行 soft reboot。该方法会将更改传播到所有 namespaces，从而避免需要逐一处理每个正在运行的 app。但是，由于重启带来的不便，这种方法通常不太被偏好。

References

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