Install Burp Certificate
Sur une machine virtuelle
Tout d'abord, vous devez télécharger le certificat Der de Burp. Vous pouvez le faire dans Proxy --> Options --> Importer / Exporter le certificat CA
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2088318145-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Frq9WIQinJaxpWMvakjIQ%252Fuploads%252Fgit-blob-ad88950d72ba52916d305d8bb5c938dd1f4cba70%252Fimage%2520%28367%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=30b085f0&sv=1)
Exportez le certificat au format Der et transformons-le en 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 suit :
Ensuite, pour configurer le certificat de Burp, faites :
Une fois que la machine a fini de redémarrer, le certificat Burp sera utilisé par celle-ci !
Utilisation de 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 car le système de fichiers est en lecture seule et que vous ne pouvez pas le remonter en écriture, il y a une autre façon de procéder.
Expliqué dans cette vidéo vous devez :
Installer un certificat CA : Il vous suffit de glisser-déposer le certificat Burp DER en changeant l'extension en
.crt
sur le mobile pour qu'il soit stocké dans le dossier Téléchargements, puis allez dansInstaller un certificat
->Certificat CA
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2088318145-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Frq9WIQinJaxpWMvakjIQ%252Fuploads%252Fgit-blob-0e554c193b3a470f5b1da38e3106da1e6d3ba244%252Fimage%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=475a6b5d&sv=1)
Vérifiez que le certificat a été correctement stocké en allant dans
Certificats de confiance
->UTILISATEUR
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2088318145-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Frq9WIQinJaxpWMvakjIQ%252Fuploads%252Fgit-blob-0e554c193b3a470f5b1da38e3106da1e6d3ba244%252Fimage%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=475a6b5d&sv=1)
Le rendre fiable pour le système : Téléchargez le module Magisc MagiskTrustUserCerts (un fichier .zip), glissez-déposez-le sur le téléphone, allez dans l'application Magics sur le téléphone dans la section
Modules
, cliquez surInstaller depuis le stockage
, sélectionnez le module.zip
et une fois installé, redémarrez le téléphone :
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2088318145-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Frq9WIQinJaxpWMvakjIQ%252Fuploads%252Fgit-blob-8190e06a75ffa491e447ad9278cb40312d5e82b5%252Fimage%2520%282%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=38ec0c4f&sv=1)
Après le redémarrage, allez dans
Certificats de confiance
->SYSTÈME
et vérifiez que le certificat Postswigger est présent
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F2088318145-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Frq9WIQinJaxpWMvakjIQ%252Fuploads%252Fgit-blob-b98c9fbbc98929f4f21cab6c8d6d02d3844d23bd%252Fimage%2520%283%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=6a7dba5f&sv=1)
Post Android 14
Dans la dernière version Android 14, un changement significatif a été observé dans la gestion des certificats d'autorité de certification (CA) fiables par le système. Auparavant, ces certificats étaient stockés dans /system/etc/security/cacerts/
, accessibles et modifiables par les utilisateurs disposant de privilèges root, ce qui permettait une application immédiate dans tout le 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 chemin APEX cacerts en écriture se soldent par un échec, car le système n'autorise pas de telles opérations. 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 certificat d'origine indépendamment des modifications au niveau du système de fichiers. Cette résilience est due à la configuration du montage /apex
avec une propagation PRIVÉE, garantissant que toute modification dans le répertoire /apex
n'affecte pas les autres processus.
L'initialisation d'Android implique le processus init
, qui, lors du démarrage du système d'exploitation, lance également le processus Zygote. Ce processus est responsable du lancement des processus d'application avec un nouveau namespace de montage incluant un montage privé /apex
, isolant ainsi les modifications apportées à ce répertoire des autres processus.
Néanmoins, une solution de contournement existe pour ceux qui ont besoin de modifier les certificats CA fiables par le système dans le répertoire /apex
. Cela implique de remonter manuellement /apex
pour supprimer la propagation PRIVÉE, le rendant ainsi inscriptible. Le processus consiste à copier le contenu de /apex/com.android.conscrypt
vers un autre emplacement, à démonter le répertoire /apex/com.android.conscrypt
pour éliminer la contrainte en lecture seule, puis à restaurer le contenu à son emplacement d'origine dans /apex
. Cette approche nécessite une action rapide pour éviter les plantages du système. Pour garantir l'application de ces modifications à l'échelle du système, il est recommandé de redémarrer le system_server
, ce qui redémarre efficacement toutes les applications et ramène le système à un état cohérent.
Montage par liaison à travers NSEnter
Configuration d'un répertoire inscriptible: Initialement, un répertoire inscriptible est établi en montant un
tmpfs
sur le répertoire existant des certificats système non-APEX. Cela est réalisé avec la commande suivante:
Préparation des certificats CA : Après la configuration du répertoire inscriptible, les certificats CA que l'on a l'intention d'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 autorisations et les étiquettes SELinux de ces certificats en conséquence.Montage de liaison pour Zygote : En utilisant
nsenter
, on entre dans l'espace de montage de Zygote. Zygote, étant le processus responsable du lancement des applications Android, nécessite cette étape pour garantir que toutes les applications initiées par la suite utilisent les certificats CA nouvellement configurés. La commande utilisée est :
Cela garantit que chaque nouvelle application lancée respectera la configuration mise à jour des certificats CA.
Application des 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 individuellement dans l'espace de nom de chaque application et effectuer un montage de liaison similaire. La commande nécessaire est:
Approche alternative - Redémarrage doux: Une méthode alternative consiste à effectuer le montage de liaison sur le processus
init
(PID 1), suivi d'un redémarrage doux du système d'exploitation avec les commandesstop && start
. Cette approche propagerait les modifications à travers tous les espaces de noms, évitant ainsi la nécessité de traiter individuellement chaque application en cours d'exécution. Cependant, cette méthode est généralement moins préférée en raison de l'inconvénient du redémarrage.
Références
Last updated