# Installer le certificat Burp {{#include ../../banners/hacktricks-training.md}} ## Proxy système via ADB Configurez un proxy HTTP global afin que toutes les applications acheminent le trafic via votre intercepteur (Burp/mitmproxy) : ```bash # 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 ``` Astuce : Dans Burp, liez votre listener à 0.0.0.0 afin que les appareils sur le LAN puissent se connecter (Proxy -> Options -> Proxy Listeners). ## Sur une machine virtuelle Tout d'abord, vous devez télécharger le certificat Der depuis Burp. Vous pouvez le faire dans _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ ![](<../../images/image (367).png>) **Exportez le certificat au format Der** et transformons-le pour obtenir une forme que **Android** pourra **comprendre.** Notez que **pour configurer le certificat Burp sur la machine Android dans AVD** vous devez **exécuter** cette machine **avec** l'option **`-writable-system`**.\ Par exemple vous pouvez l'exécuter comme : ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` Ensuite, pour **configurer le certificat de burps**, faites : ```bash 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 ``` Une fois que la machine a terminé le redémarrage, le certificat Burp sera utilisé par celle-ci ! ## Using Magisc Si vous avez **rooté votre appareil avec Magisc** (peut‑être un émulateur), et que vous **ne pouvez pas suivre** les **étapes** précédentes pour installer le certificat Burp parce que le **système de fichiers est en lecture seule** et que vous ne pouvez pas le remonter en écriture, il existe une autre méthode. Expliqué dans [**cette vidéo**](https://www.youtube.com/watch?v=qQicUW0svB8) vous devez : 1. **Installer un certificat CA** : Il suffit de **drag&drop** le certificat Burp au format DER en **changeant l’extension** en `.crt` sur le mobile pour qu’il soit stocké dans le dossier Downloads et aller à `Install a certificate` -> `CA certificate`
- Vérifiez que le certificat a été correctement stocké en allant dans `Trusted credentials` -> `USER`
2. **Le rendre approuvé par le système** : Téléchargez le module Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (un fichier .zip), **drag&drop** le sur le téléphone, allez dans l’app Magics du téléphone à la section **`Modules`**, cliquez sur **`Install from storage`**, sélectionnez le module `.zip` et une fois installé **redémarrez** le téléphone :
- Après le redémarrage, allez dans `Trusted credentials` -> `SYSTEM` et vérifiez que le certificat Postswigger est présent
### Learn how to create a Magisc module Consultez [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437) ## Post Android 14 Dans la dernière release d’Android 14, un changement important a été observé dans la gestion des certificats d’autorité (CA) approuvés par le système. Auparavant, ces certificats étaient stockés dans **`/system/etc/security/cacerts/`**, accessibles et modifiables par les utilisateurs avec les privilèges root, ce qui permettait une application immédiate sur l’ensemble du système. Cependant, avec Android 14, l’emplacement de stockage a été déplacé vers **`/apex/com.android.conscrypt/cacerts`**, un répertoire situé dans le chemin **`/apex`**, qui est immuable par nature. Les tentatives de remonter le **APEX cacerts path** en écriture échouent, car le système n’autorise pas ce type d’opération. Même les tentatives de démontage ou de superposition du répertoire avec un système de fichiers temporaire (tmpfs) ne contournent pas l’immuabilité ; les applications continuent d’accéder aux données de certificats d’origine quelles que soient les modifications au niveau du système de fichiers. Cette résilience est due au fait que le montage de **`/apex`** est configuré avec une PRIVATE propagation, ce qui garantit que toute modification au sein du répertoire **`/apex`** n’affecte pas les autres processus. L’initialisation d’Android implique le processus `init` qui, au démarrage du système d’exploitation, lance également le processus Zygote. Ce dernier est responsable du lancement des processus d’application avec un nouveau mount namespace qui inclut un montage privé **`/apex`**, isolant ainsi les modifications de ce répertoire des autres processus. Néanmoins, il existe un contournement pour ceux qui doivent modifier les certificats CA approuvés par le système dans le répertoire **`/apex`**. Il consiste à remonter manuellement **`/apex`** pour retirer la PRIVATE propagation, rendant ainsi le répertoire modifiable. Le processus inclut la copie du contenu de **`/apex/com.android.conscrypt`** vers un autre emplacement, le démontage du répertoire **`/apex/com.android.conscrypt`** pour éliminer la contrainte en lecture seule, puis la restauration du contenu à son emplacement d’origine dans **`/apex`**. Cette approche nécessite une exécution rapide pour éviter des plantages système. Pour garantir l’application des changements à l’échelle du système, il est recommandé de redémarrer le `system_server`, ce qui redémarre effectivement toutes les applications et ramène le système à un état cohérent. ```bash # 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**: Initialement, un répertoire inscriptible est créé en montant un `tmpfs` sur le répertoire système de certificats non-APEX existant. Ceci est réalisé avec la commande suivante : ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` 2. **Préparation des certificats CA** : Après la création du répertoire en écriture, les certificats CA que l'on souhaite utiliser doivent être copiés dans ce répertoire. Cela peut impliquer de copier les certificats par défaut depuis `/apex/com.android.conscrypt/cacerts/`. Il est essentiel d'ajuster les permissions et les labels SELinux de ces certificats en conséquence. 3. **Montage bind pour Zygote** : En utilisant `nsenter`, on entre dans le namespace de montage de Zygote. Zygote, étant le processus responsable du lancement des applications Android, nécessite cette étape afin de s'assurer que toutes les applications lancées à partir de ce moment utilisent les certificats CA nouvellement configurés. La commande utilisée est : ```bash nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` Cela garantit que chaque nouvelle application démarrée respectera la configuration mise à jour des certificats CA. 4. **Appliquer les modifications aux applications en cours d'exécution** : Pour appliquer les modifications aux applications déjà en cours d'exécution, `nsenter` est à nouveau utilisé pour entrer dans l'espace de noms de chaque application individuellement et effectuer un bind mount similaire. La commande nécessaire est : ```bash nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` 5. **Approche alternative — redémarrage logiciel**: Une méthode alternative consiste à effectuer le bind mount sur le processus `init` (PID 1), suivie d'un redémarrage logiciel du système d'exploitation avec les commandes `stop && start`. Cette approche propagerait les changements à travers tous les namespaces, évitant la nécessité de traiter individuellement chaque application en cours d'exécution. Cependant, cette méthode est généralement moins privilégiée en raison de la gêne occasionnée par le redémarrage. ## Références - [Android 14: Install a system CA certificate on a rooted device](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/) - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) {{#include ../../banners/hacktricks-training.md}}