hacktricks/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

# Instalar Certificado Burp

{{#include ../../banners/hacktricks-training.md}}


## Em uma Máquina Virtual

Primeiro de tudo, você precisa baixar o certificado Der do Burp. Você pode fazer isso em _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_

![](<../../images/image (367).png>)

**Exporte o certificado no formato Der** e vamos **transformá-lo** em uma forma que o **Android** vai conseguir **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á-la assim:
```bash
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
```
Então, para **configurar o certificado do burp faça**:
```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
```
Uma vez que a **máquina terminar de reiniciar**, o certificado 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 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**: Basta **arrastar e soltar** o certificado DER Burp **mudando a extensão** para `.crt` no celular para que ele seja armazenado na pasta Downloads e ir para `Instalar um certificado` -> `Certificado CA`

<figure><img src="../../images/image (53).png" alt="" width="164"><figcaption></figcaption></figure>

- Verifique se o certificado foi armazenado corretamente indo para `Credenciais confiáveis` -> `USUÁRIO`

<figure><img src="../../images/image (54).png" alt="" width="334"><figcaption></figcaption></figure>

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 na seção **`Módulos`**, clique em **`Instalar do armazenamento`**, selecione o módulo `.zip` e, uma vez instalado, **reinicie** o telefone:

<figure><img src="../../images/image (55).png" alt="" width="345"><figcaption></figcaption></figure>

- Após reiniciar, vá para `Credenciais confiáveis` -> `SISTEMA` e verifique se o certificado Postswigger está lá

<figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>

## Pós Android 14

Na última versão do Android 14, uma mudança significativa foi observada no manuseio de certificados de Autoridade Certificadora (CA) confiáveis pelo sistema. Anteriormente, esses certificados estavam armazenados em **`/system/etc/security/cacerts/`**, acessíveis e modificáveis por usuários com privilégios de root, o que permitia 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 falham, 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; os aplicativos continuam a acessar os dados do certificado original, independentemente das mudanças no nível do sistema de arquivos. Essa resiliência se deve ao **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. Este processo é responsável por lançar processos de aplicativos com um novo namespace de montagem que inclui uma montagem privada **`/apex`**, isolando assim as mudanças neste diretório de outros processos.

No entanto, existe uma solução para aqueles que precisam modificar os certificados CA confiáveis pelo sistema dentro do diretório **`/apex`**. Isso envolve remontar manualmente **`/apex`** para remover a propagação PRIVADA, tornando-o assim gravável. O processo inclui copiar o conteúdo de **`/apex/com.android.conscrypt`** para outro local, desmontar o diretório **`/apex/com.android.conscrypt`** para eliminar a restrição de somente leitura e, em seguida, restaurar o conteúdo ao seu local original dentro de **`/apex`**. Essa abordagem requer ação rápida para evitar falhas no sistema. Para garantir a aplicação em todo o sistema dessas mudanças, é recomendável reiniciar o `system_server`, que efetivamente reinicia todos os aplicativos e traz o sistema a 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"
```
### Bind-mounting through NSEnter

1. **Configurando 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 CA**: Após a configuração do diretório gravável, os certificados CA que se pretende usar devem ser copiados para este diretório. Isso pode envolver a cópia dos certificados padrão de `/apex/com.android.conscrypt/cacerts/`. É essencial ajustar as permissões e os rótulos SELinux desses certificados de acordo.

3. **Montagem 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 esta etapa para garantir que todos os aplicativos iniciados a partir de agora utilizem os novos certificados CA configurados. O comando utilizado é:
```bash
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
```
Isso garante que cada novo aplicativo iniciado seguirá a configuração atualizada dos certificados CA.

4. **Aplicando Mudanças em Aplicativos em Execução**: Para aplicar as mudanças em aplicativos já em execução, `nsenter` é novamente usado para entrar no namespace de cada aplicativo individualmente e realizar um bind mount 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`. Essa abordagem propagaria as mudanças em todos os namespaces, evitando a necessidade de abordar individualmente cada aplicativo em execução. No entanto, esse método é geralmente menos preferido devido ao inconveniente de reiniciar.

## Referências

- [https://httptoolkit.com/blog/android-14-install-system-ca-certificate/](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)


{{#include ../../banners/hacktricks-training.md}}