# Instalar Certificado Burp
Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)! Outras formas de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
## Em uma Máquina Virtual Primeiramente, você precisa baixar o certificado Der do Burp. Você pode fazer isso em _**Proxy**_ --> _**Opções**_ --> _**Importar/Exportar certificado CA**_ ![](<../../.gitbook/assets/image (367).png>) **Exporte o certificado no formato Der** e vamos **transformá-lo** para uma forma que o **Android** será capaz de **entender.** Note que **para configurar o certificado burp na máquina Android no AVD** você precisa **executar** esta máquina **com** a opção **`-writable-system`**.\ Por exemplo, você pode executá-lo assim: {% code overflow="wrap" %} ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` {% endcode %} Em seguida, para **configurar o certificado do burp**, faça o seguinte: {% code overflow="wrap" %} ```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 ``` {% endcode %} Uma vez que a **máquina terminar de reiniciar**, o certificado do Burp estará em uso por ela! ## Usando Magisc Se você **rootou seu dispositivo com Magisc** (talvez um emulador), e você **não consegue seguir** os **passos anteriores** para instalar o certificado do Burp porque o **sistema de arquivos é somente leitura** e você não pode remontá-lo como gravável, há outra maneira. Explicado em [**este vídeo**](https://www.youtube.com/watch?v=qQicUW0svB8) você precisa: 1. **Instalar um certificado CA**: Apenas **arraste e solte** o certificado DER do Burp **alterando a extensão** para `.crt` no celular para que ele seja armazenado na pasta Downloads e vá para `Instalar um certificado` -> `Certificado CA`
* Verifique se o certificado foi armazenado corretamente indo para `Credenciais confiáveis` -> `USUÁRIO`
2. **Torná-lo confiável pelo sistema**: Baixe o módulo Magisc [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (um arquivo .zip), **arraste e solte** no telefone, vá para o aplicativo **Magics** no telefone para a seção **`Módulos`**, clique em **`Instalar do armazenamento`**, selecione o módulo `.zip` e uma vez instalado **reinicie** o telefone:
* Após reiniciar, vá para `Credenciais confiáveis` -> `SISTEMA` e verifique se o certificado do Postswigger está lá
## Pós Android 14 No lançamento mais recente do Android 14, foi observada uma mudança significativa no tratamento de certificados de Autoridade de Certificação (CA) confiáveis pelo sistema. Anteriormente, esses certificados estavam localizados em **`/system/etc/security/cacerts/`**, acessíveis e modificáveis por usuários com privilégios de root, o que permitia a aplicação imediata em todo o sistema. No entanto, com o Android 14, o local de armazenamento foi movido para **`/apex/com.android.conscrypt/cacerts`**, um diretório dentro do caminho **`/apex`**, que é imutável por natureza. Tentativas de remontar o caminho **APEX cacerts** como gravável são frustradas, pois o sistema não permite tais operações. Mesmo tentativas de desmontar ou sobrepor o diretório com um sistema de arquivos temporário (tmpfs) não contornam a imutabilidade; aplicativos continuam acessando os dados do certificado original, independentemente de alterações no nível do sistema de arquivos. Essa resiliência se deve à montagem **`/apex`** ser configurada com propagação PRIVADA, garantindo que quaisquer modificações dentro do diretório **`/apex`** não afetem outros processos. A inicialização do Android envolve o processo `init`, que, ao iniciar o sistema operacional, também inicia o processo Zygote. Esse processo é responsável por lançar processos de aplicativos com um novo espaço de montagem que inclui uma montagem privada **`/apex`**, isolando assim as alterações neste diretório de outros processos. No entanto, existe uma solução alternativa para aqueles que precisam modificar os certificados CA confiáveis pelo sistema dentro do diretório **`/apex`**. Isso envolve remontar manualmente o **`/apex`** para remover a propagação PRIVADA, tornando-o gravável. O processo inclui copiar o conteúdo de **`/apex/com.android.conscrypt`** para outra localização, desmontar o diretório **`/apex/com.android.conscrypt`** para eliminar a restrição somente leitura e, em seguida, restaurar o conteúdo para sua localização original dentro de **`/apex`**. Esta abordagem requer ação rápida para evitar falhas no sistema. Para garantir a aplicação dessas alterações em todo o sistema, é recomendável reiniciar o `system_server`, o que efetivamente reinicia todos os aplicativos e coloca o sistema em um estado consistente. ```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" ``` ### Montagem de ligação através do NSEnter 1. **Configurar um Diretório Gravável**: Inicialmente, um diretório gravável é estabelecido montando um `tmpfs` sobre o diretório de certificados do sistema não-APEX existente. Isso é alcançado com o seguinte comando: ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` 2. **Preparando Certificados da CA**: Após a configuração do diretório gravável, os certificados da CA que se pretende usar devem ser copiados para este diretório. Isso pode envolver copiar os certificados padrão de `/apex/com.android.conscrypt/cacerts/`. É essencial ajustar as permissões e rótulos SELinux desses certificados adequadamente. 3. **Montagem de Bind para Zygote**: Utilizando `nsenter`, entra-se no namespace de montagem do Zygote. O Zygote, sendo o processo responsável por iniciar aplicativos Android, requer este passo para garantir que todos os aplicativos iniciados daqui em diante utilizem os certificados da CA recém-configurados. O comando usado é: ```bash nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` Isso garante que todo novo aplicativo iniciado seguirá a configuração atualizada de certificados CA. 4. **Aplicando Alterações aos Aplicativos em Execução**: Para aplicar as alterações aos aplicativos que já estão em execução, `nsenter` é novamente usado para entrar individualmente no namespace de cada aplicativo e realizar uma montagem de bind semelhante. O comando necessário é: ```bash nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` 5. **Abordagem Alternativa - Reinicialização Suave**: Um método alternativo envolve realizar o bind mount no processo `init` (PID 1) seguido por uma reinicialização suave do sistema operacional com os comandos `stop && start`. Esta abordagem propagaria as alterações em todos os namespaces, evitando a necessidade de abordar individualmente cada aplicativo em execução. No entanto, este método geralmente é menos preferido devido ao inconveniente de reinicialização. ## Referências * [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)! Outras maneiras de apoiar o HackTricks: * Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com) * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family) * **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.