Install Burp Certificate - HackTricks

# Install Burp Certificate

> [!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
> Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

> Support HackTricks
> - Check the subscription plans!
> - Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
> - Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

## On a Virtual Machine

First of all you need to download the Der certificate from Burp. You can do this in Proxy --> Options --> Import / Export CA certificate

Export the certificate in Der format and lets transform it to a form that Android is going to be able to understand. Note that in order to configure the burp certificate on the Android machine in AVD you need to run this machine with the `-writable-system` option.
For example you can run it like:

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

Then, to configure burps certificate do:

    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 machine finish rebooting the burp certificate will be in use by it!

## Using Magisc

If you rooted your device with Magisc (maybe an emulator), and you can't follow the previous steps to install the Burp cert because the filesystem is read-only and you cannot remount it writable, there is another way.

Explained in this video you need to:

1. Install a CA certificate: Just drag&drop the DER Burp certificate changing the extension to `.crt` in the mobile so it's stored in the Downloads folder and go to `Install a certificate` -> `CA certificate`

- Check that the certificate was correctly stored going to `Trusted credentials` -> `USER`

2. Make it System trusted: Download the Magisc module MagiskTrustUserCerts (a .zip file), drag&drop it in the phone, go to the Magics app in the phone to the `Modules` section, click on `Install from storage`, select the `.zip` module and once installed reboot the phone:

- After rebooting, go to `Trusted credentials` -> `SYSTEM` and check the Postswigger cert is there

## Post Android 14

In the latest Android 14 release, a significant shift has been observed in the handling of system-trusted Certificate Authority (CA) certificates. Previously, these certificates were housed in `/system/etc/security/cacerts/`, accessible and modifiable by users with root privileges, which allowed immediate application across the system. However, with Android 14, the storage location has been moved to `/apex/com.android.conscrypt/cacerts`, a directory within the `/apex` path, which is immutable by nature.

Attempts to remount the APEX cacerts path as writable are met with failure, as the system does not allow such operations. Even attempts to unmount or overlay the directory with a temporary file system (tmpfs) do not circumvent the immutability; applications continue to access the original certificate data regardless of changes at the file system level. This resilience is due to the `/apex` mount being configured with PRIVATE propagation, ensuring that any modifications within the `/apex` directory do not affect other processes.

The initialization of Android involves the `init` process, which, upon starting the operating system, also initiates the Zygote process. This process is responsible for launching application processes with a new mount namespace that includes a private `/apex` mount, thus isolating changes to this directory from other processes.

Nevertheless, a workaround exists for those needing to modify the system-trusted CA certificates within the `/apex` directory. This involves manually remounting `/apex` to remove the PRIVATE propagation, thereby making it writable. The process includes copying the contents of `/apex/com.android.conscrypt` to another location, unmounting the `/apex/com.android.conscrypt` directory to eliminate the read-only constraint, and then restoring the contents to their original location within `/apex`. This approach requires swift action to avoid system crashes. To ensure system-wide application of these changes, it is recommended to restart the `system_server`, which effectively restarts all applications and brings the system to a consistent state.

    # 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. Setting Up a Writable Directory: Initially, a writable directory is established by mounting a `tmpfs` over the existing non-APEX system certificate directory. This is achieved with the following command:

        mount -t tmpfs tmpfs /system/etc/security/cacerts

2. Preparing CA Certificates: Following the setup of the writable directory, the CA certificates that one intends to use should be copied into this directory. This might involve copying the default certificates from `/apex/com.android.conscrypt/cacerts/`. It's essential to adjust the permissions and SELinux labels of these certificates accordingly.
3. Bind Mounting for Zygote: Utilizing `nsenter`, one enters the Zygote's mount namespace. Zygote, being the process responsible for launching Android applications, requires this step to ensure that all applications initiated henceforth utilize the newly configured CA certificates. The command used is:

    nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

This ensures that every new app started will adhere to the updated CA certificates setup.

4. Applying Changes to Running Apps: To apply the changes to already running applications, `nsenter` is again used to enter each app's namespace individually and perform a similar bind mount. The necessary command is:

    nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts

5. Alternative Approach - Soft Reboot: An alternative method involves performing the bind mount on the `init` process (PID 1) followed by a soft reboot of the operating system with `stop && start` commands. This approach would propagate the changes across all namespaces, avoiding the need to individually address each running app. However, this method is generally less preferred due to the inconvenience of rebooting.

## References

- https://httptoolkit.com/blog/android-14-install-system-ca-certificate/

> [!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
> Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

> Support HackTricks
> - Check the subscription plans!
> - Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
> - Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.