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

# Instalar Certificado Burp

<details>

<summary><strong>Aprenda hacking em AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Outras formas de apoiar o HackTricks:

* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

## 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** em um formato que o **Android** possa **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:

{% code overflow="wrap" %}
```bash
C:\Users\<UserName>\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**:

{% 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 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, existe outra maneira.

Explicado [**neste vídeo**](https://www.youtube.com/watch?v=qQicUW0svB8), você precisa:

1. **Instalar um certificado CA**: Simplesmente **arraste e solte** o certificado Burp DER **mudando a extensão** para `.crt` no celular para que seja armazenado na pasta Downloads e vá para `Instalar um certificado` -> `Certificado CA`

<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" width="164"><figcaption></figcaption></figure>

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

<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).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="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1).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="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt="" width="314"><figcaption></figcaption></figure>

## Pós Android 14

Mudanças:

* Até agora, os certificados CA confiáveis pelo sistema estavam em **`/system/etc/security/cacerts/`**. Em um emulador AOSP padrão, esses poderiam ser **modificados diretamente com acesso root** com configuração mínima, tendo **efeito imediato em todo lugar**.
* No Android 14, os certificados CA confiáveis pelo sistema geralmente estarão em **`/apex/com.android.conscrypt/cacerts`**, e todo o **`/apex` é imutável**.
* Esse caminho **APEX cacerts não pode ser remontado como gravável** - remontagens simplesmente falham. De fato, mesmo que você desmonte todo o caminho de um shell root, os aplicativos ainda podem ler seus certificados sem problemas.
* A técnica alternativa de **montar um diretório tmpfs por cima também não funciona** - mesmo que isso signifique que `ls /apex/com.android.conscrypt/cacerts` possa não retornar nada (ou qualquer outra coisa que você queira), os aplicativos ainda verão os mesmos dados originais.
* Porque a montagem `/apex` é [explicitamente montada](https://cs.android.com/android/platform/superproject/main/+/main:system/core/init/mount\_namespace.cpp;l=97;drc=566c65239f1cf3fcb0d8745715e5ef1083d4bd3a) **com propagação PRIVADA**, de modo que todas as alterações nas montagens dentro do caminho `/apex` nunca são compartilhadas entre processos.

Isso é feito pelo processo `init` que inicia o SO, que então lança o processo [Zygote](https://en.wikipedia.org/wiki/Booting\_process\_of\_Android\_devices#Zygote) (com um novo namespace de montagem copiado do pai, incluindo sua **própria montagem `/apex` privada**), que por sua vez **inicia cada processo de aplicativo** sempre que um aplicativo é lançado no dispositivo (que cada um por sua vez então **copia essa mesma montagem `/apex` privada**).

### Remontando pontos de montagem recursivamente

* Você pode remontar `/apex` manualmente, removendo a propagação PRIVADA e tornando-o gravável (ironicamente, parece que remover completamente a propagação privada _realmente_ se propaga por todo lugar)
* Você copia todo o conteúdo de `/apex/com.android.conscrypt` para outro lugar
* Então você desmonta `/apex/com.android.conscrypt` completamente - removendo a montagem somente leitura que fornece imutavelmente este módulo
* Então você copia o conteúdo de volta, para que ele viva diretamente na montagem `/apex`, onde ele pode ser modificado (você precisa fazer isso rapidamente, pois [aparentemente](https://infosec.exchange/@g1a55er/111069489513139531) você pode ver falhas de outra forma)
* Isso deve ter efeito imediato, mas eles recomendam matar `system_server` (reiniciando todos os aplicativos) para que tudo volte 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"
```
### Montagem vinculada através do NSEnter

* Primeiro, precisamos configurar um diretório gravável em algum lugar. Para fácil compatibilidade com a abordagem existente, estou fazendo isso com uma montagem `tmpfs` sobre o diretório de certificados do sistema não-APEX ainda presente:

```bash
mount -t tmpfs tmpfs /system/etc/security/cacerts
```
* Em seguida, você coloca os certificados CA de seu interesse neste diretório (por exemplo, você pode querer copiar todos os padrões existentes do diretório de certificados CA `/apex/com.android.conscrypt/cacerts/`) e definir as permissões e rótulos SELinux apropriadamente.
* Então, use `nsenter` para entrar no namespace de montagem do Zygote e montar este diretório sobre o diretório APEX:

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

O processo Zygote gera cada aplicativo, copiando seu namespace de montagem para fazer isso, então isso garante que todos os aplicativos recém-lançados (tudo que for iniciado a partir de agora) usarão isso.
* Então, use `nsenter` para entrar no namespace de cada aplicativo já em execução e faça o mesmo:

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

Alternativamente, se você não se importar com a UX desajeitada, você deve ser capaz de fazer a montagem vinculada no próprio `init` (PID 1) e depois executar `stop && start` para reiniciar suavemente o SO, recriando todos os namespaces e propagando suas mudanças em todos os lugares (mas pessoalmente eu me importo com a reinicialização desajeitada, então estou ignorando completamente esse caminho).

<details>

<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Outras formas de apoiar o HackTricks:

* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Obtenha o [**merchandising oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>