m00ddy/cve-2026-0073-android-client-tls-auth-bypasstranslating original python exploit to C
CVE‑2026‑0073 é um bug lógico no daemon ADB do Android (adbd) que permite a um atacante contornar a autenticação mútua TLS e abrir um shell remoto em um dispositivo que tenha a depuração sem fio ativada e tenha sido pareado com qualquer computador pelo menos uma vez. A causa raiz é uma única API mal utilizada: o valor de retorno de EVP_PKEY_cmp() do OpenSSL é tratado como um booleano em vez de um resultado de três valores.
quando ativamos a depuração sem fio nas configurações de desenvolvedor do Android, o dispositivo inicia uma instância adbd que escuta em uma porta TCP aleatória. Nota: este recurso foi introduzido a partir do Android 11.
o protocolo tem duas fases:
adbd exige que o cliente apresente um certificadoadbd extrai a chave pública desse certificado/data/misc/adb/adb_keys. as chaves são colocadas lá durante pareamentos anteriores (o exploit requer que pelo menos uma chave esteja aqui)shell
a comparação de chaves é feita usando EVP_PKEY_cmp(key1, key2) do OpenSSL, que retornano arquivo daemon/auth.cpp a função vulnerável adb_tls_verify_cert() se parece com algo assim:
int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {
authorised = true;
}
já que if(cmp) retorna verdadeiro enquanto cmp for diferente de zero, um valor de retorno -1 de EVP_PKEY_cmp() leva à autorização. isso significa que, como a chave armazenada é RSA, quando o cliente apresenta um certificado EC ou ed25519, a função retorna -1 e o atacante obtém acesso autorizado.
alvo: um dispositivo Android com depuração sem fio ativada e pelo menos uma chave RSA em seu keystore (foi pareado uma vez, por qualquer pessoa).
handshake em texto claro: o atacante conecta à porta TCP do adbd e troca CNXN/STLS.
handshake TLS com certificado EC: o atacante gera uma chave EC P‑256 efêmera e um certificado autoassinado. esta chave é deliberadamente não RSA.
comparação falha: EVP_PKEY_cmp(RSA, EC) retorna -1 → if (cmp) é verdadeiro → adbd marca o transporte como autorizado.
pós‑TLS: O atacante evita enviar um CNXN do host (que redefiniria o transporte) e abre diretamente um fluxo shell: com uma grande janela delayed_ack.
Resultado: Shell remoto como o usuário shell, sem interação do usuário, sem notificação e sem necessidade de possuir qualquer chave privada legítima.
O script Python requer um interpretador Python 3 e a biblioteca cryptography instalada na máquina do atacante. Uma implementação em C compila para um binário independente sem dependências externas além do OpenSSL/libssl do sistema, que está presente em praticamente todo sistema Linux por padrão. Isso reduz drasticamente a barreira para implantação. Além disso, um programa em C pode ser compilado de forma cruzada para qualquer arquitetura alvo (x86_64, ARM, MIPS). Isso significa que o exploit poderia ser compilado e executado diretamente em dispositivos embarcados como roteadores, Raspberry Pis, ou até mesmo outro dispositivo Android atuando como atacante, sem necessidade de ambiente Python. E um binário C compilado pode ser removido de símbolos, empacotado (UPX) e é opaco sem um desmontador, o que o torna mais furtivo que um script Python.
executando o exploit: forneça o IP e a PORTA da interface de depuração sem fio e você terá um shell no dispositivo.
docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>
abrindo uma calculadora
am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator
LLM foi usado para traduzir o exploit de Python para C, o exploit original está aqui. a tradução não foi correta 1:1 e enfrentamos muitos problemas, portanto um loop de análise de código e idas e vindas em conversas foi necessário para corrigir bugs na tradução e chegar a um exploit funcional completo.