O Google Hackeou o Próprio Celular — e Precisou de Apenas 5 Linhas de Código

Imagine receber uma mensagem de áudio no Google Messages. Você nem abre. Nem lê. Nem toca na tela. Mas nesse momento, alguém já tem controle total do seu Pixel 10 — câmera, microfone, fotos, senhas, tudo.

Parece ficção científica, mas foi exatamente isso que Seth Jenkins, pesquisador do Google Project Zero, demonstrou esta semana. Ele construiu uma cadeia de exploits que vai de zero interação do usuário até root completo no Pixel 10, o flagship mais recente do Google. E a parte mais assustadora? A segunda etapa do ataque inteiro exigiu 5 linhas de código e menos de um dia para ser desenvolvida.

O que é um 0-click exploit (e por que você deveria se preocupar)

A maioria dos ataques que conhecemos exige alguma ação da vítima. Clicar num link. Baixar um app. Abrir um anexo. Um exploit 0-click dispensa tudo isso. O simples fato de receber dados — uma mensagem, uma chamada, um arquivo — é suficiente para comprometer o dispositivo.

O Project Zero, divisão de elite de segurança do Google, já tinha demonstrado ataques semelhantes no Pixel 9 no início de 2026. Agora, a equipe adaptou a técnica para o Pixel 10, mostrando que mesmo as defesas mais modernas do Android continuam insuficientes contra pesquisadores determinados.

A diferença entre um 0-click e qualquer outro vetor é brutal: não existe defesa comportamental. Não importa o quão cuidadoso você seja, o quão paranóico com links suspeitos — se alguém sabe seu número de telefone e o exploit existe, já era.

Stage 1: O codec de áudio que processa antes de você decidir

A primeira etapa do ataque explora a CVE-2025-54957, uma vulnerabilidade no Dolby Unified Decoder (UDC). Esse é o componente responsável por decodificar áudio Dolby Digital em praticamente todos os dispositivos modernos — Android, iOS, Windows, smart TVs, streaming boxes.

O pulo do gato está em como o Google Messages funciona: mensagens de áudio recebidas são transcritas automaticamente antes do usuário abrir a conversa. Ou seja, o codec de áudio é acionado sem nenhuma interação. O atacante envia um áudio Dolby malformado, o Messages tenta transcrever, o decoder processa o payload, e pronto — código arbitrário executando no processo do Messages.

Atacante envia áudio Dolby → Google Messages recebe
                           → Transcrição automática inicia
                           → Dolby UDC processa o áudio
                           → Buffer overflow no decoder
                           → Execução de código no contexto do Messages

Jenkins já tinha usado essa mesma vulnerabilidade no Pixel 9. Para o Pixel 10, o desafio foi diferente: o novo dispositivo usa RET PAC (Pointer Authentication Codes) em vez do tradicional -fstack-protector. Isso significa que o stack canary — aquela proteção clássica contra buffer overflow — foi substituído por autenticação criptográfica de ponteiros de retorno.

Parece mais seguro, certo? Na teoria, sim. Na prática, Jenkins encontrou alvos alternativos para sobrescrita que não dependiam de ponteiros autenticados. O endereço do decoder mudou, as proteções mudaram, mas a vulnerabilidade fundamental continuava lá.

O que é RET PAC?

Para quem não vive no mundo de exploit dev, uma explicação rápida. ARM Pointer Authentication (PAC) adiciona uma assinatura criptográfica aos ponteiros antes de armazená-los na stack. Quando a função retorna, o processador verifica a assinatura. Se alguém sobrescreveu o ponteiro de retorno, a assinatura não bate e o programa crasha em vez de executar código do atacante.

// Pseudocódigo simplificado do PAC
void funcao() {
    // Na entrada: ponteiro de retorno recebe assinatura
    // lr = sign(lr, sp, key)

    // ... código da função ...

    // Na saída: verifica assinatura antes de retornar
    // if (verify(lr, sp, key) == false) crash();
    // return lr;
}

É uma defesa robusta contra ataques ROP (Return-Oriented Programming) tradicionais. Mas não protege contra todos os tipos de sobrescrita — e foi exatamente nessa brecha que Jenkins operou.

Stage 2: 5 linhas de código para acessar toda a memória do kernel

Se a Stage 1 é sofisticada, a Stage 2 é quase cômica de tão simples.

Após obter execução de código no processo do Messages (que roda como o app, sem privilégios elevados), Jenkins precisava de uma forma de escalar para root. No Pixel 9, ele usou o driver BigWave. No Pixel 10, com chip Tensor G5, esse driver não existia mais.

Então ele e o colega Jann Horn fizeram uma “revisão rápida” nos drivers do Tensor G5. Em duas horas, encontraram algo absurdo no driver VPU (Video Processing Unit) — o componente de decodificação de vídeo do chip.

O handler mmap do driver VPU permitia mapear memória física arbitrária no espaço do usuário. O bug é tão simples que dá raiva:

// Código vulnerável (simplificado) do vpu_mmap
static int vpu_mmap(struct file *file, struct vm_area_struct *vma)
{
    // Mapeia memória física com base no tamanho que o USUÁRIO pediu
    // Sem verificar se o tamanho excede a região de registradores
    return remap_pfn_range(vma, vma->vm_start,
                           vma->vm_pgoff,
                           vma->vm_end - vma->vm_start,  // tamanho controlado pelo atacante!
                           vma->vm_page_prot);
}

O problema: a função remap_pfn_range usa o tamanho da VMA (Virtual Memory Area) que o usuário solicita via mmap(), não o tamanho real da região de registradores do hardware. Se você pedir 4KB, recebe 4KB de registradores. Se pedir 4GB, recebe 4GB de memória física — incluindo a imagem inteira do kernel na memória.

E tem mais. No Pixel, o kernel sempre reside no mesmo endereço físico. Sem KASLR efetivo na memória física. O offset entre os registradores do VPU e o código do kernel é previsível e constante.

O exploit completo da Stage 2 precisou de 5 linhas de código:

// Pseudocódigo do exploit (5 linhas que dão root)
int fd = open("/dev/vpu", O_RDWR);
void *mem = mmap(NULL, HUGE_SIZE, PROT_READ | PROT_WRITE,
                 MAP_SHARED, fd, 0);
// mem agora aponta para toda a memória física
// kernel_base = mem + KNOWN_OFFSET
// Sobrescrever credenciais do processo atual → root

Menos de um dia para desenvolver. Duas horas para encontrar o bug. Cinco linhas para explorar. Root completo num Pixel 10 zerado com todas as atualizações até novembro de 2025. Lembra do Copy Fail, o exploit de 732 bytes que comprometia qualquer Linux? Mesma energia.

A cadeia completa: do áudio ao root

Juntando as duas etapas, o fluxo completo do ataque fica assim:

1. Atacante envia áudio Dolby malicioso via Google Messages
2. Messages transcreve automaticamente (0-click)
3. CVE-2025-54957: buffer overflow no Dolby UDC
4. Execução de código no processo do Messages
5. Exploit abre /dev/vpu e faz mmap gigante
6. Mapeia toda a memória física (incluindo o kernel)
7. Sobrescreve credenciais do processo → root
8. Controle total do dispositivo

O que deu errado no driver VPU

Vamos ser diretos: esse bug não deveria existir em 2025. Um handler mmap que não verifica limites é o tipo de falha que aparece em exercícios de CTF de nível intermediário — como o bug de 18 anos do Nginx que foi descoberto recentemente, não em drivers de produção de um chip de $900.

O padrão correto seria algo como:

static int vpu_mmap_correto(struct file *file, struct vm_area_struct *vma)
{
    size_t size = vma->vm_end - vma->vm_start;

    // VERIFICAÇÃO QUE FALTAVA
    if (size > VPU_REGISTER_REGION_SIZE)
        return -EINVAL;

    return remap_pfn_range(vma, vma->vm_start,
                           vma->vm_pgoff,
                           size,
                           vma->vm_page_prot);
}

Uma linha. Uma única verificação de if separava o Pixel 10 de um exploit trivial para root. Quando o pesquisador do Project Zero diz que encontrou isso em “uma revisão rápida de 2 horas”, a pergunta natural é: como ninguém mais encontrou antes? Não seria a primeira vez — o Claude encontrou um bug no Linux que passou despercebido por 23 anos.

A resposta possível: drivers de hardware proprietário para chips customizados (como o Tensor G5) passam por menos escrutínio do que o kernel Linux mainline. O código do VPU provavelmente foi escrito por engenheiros de firmware do parceiro de silício do Google, não pela equipe de kernel Android. E os processos de revisão de segurança claramente falharam em cobrir esse componente.

Timeline: 71 dias entre o report e o patch

Um ponto positivo nessa história é a velocidade de resposta:

71 dias entre o report e o patch. Para contexto, o bug anterior do BigWave (usado no exploit do Pixel 9) levou significativamente mais tempo. O Android também reclassificou o VPU como severidade High — uma melhoria nos processos de triagem, segundo Jenkins.

Se seu Pixel está com o Security Patch Level de fevereiro de 2026 ou posterior, você já está protegido contra essa cadeia específica.

O que isso significa para o ecossistema Android

Essa pesquisa expõe três problemas estruturais que vão muito além do Pixel 10.

Primeiro: drivers de hardware são o elo fraco. O kernel Linux mainline passa por revisões rigorosas. Drivers proprietários de chips customizados? Nem tanto. À medida que fabricantes como Google, Samsung e Qualcomm criam silício cada vez mais complexo, a superfície de ataque em drivers cresce proporcionalmente.

Segundo: defesas modernas não são suficientes. O Pixel 10 tem PAC, MTE (Memory Tagging Extension), CFI (Control Flow Integrity) — praticamente tudo que existe de state-of-the-art em mitigação de exploits. E ainda assim, um bug trivial num driver de vídeo bypassa tudo, porque essas defesas protegem o fluxo de execução, não o acesso direto à memória física.

Terceiro: a transcrição automática é um risco. Qualquer feature que processa dados externos automaticamente — sem interação do usuário — é uma superfície de ataque 0-click por definição. Transcrição de áudio, preview de imagens, renderização de notificações ricas… cada uma dessas features precisa rodar em sandboxes isolados com privilégios mínimos.

Como verificar se você está protegido

Se você usa um Pixel, vá em Configurações → Sobre o telefone → Nível do patch de segurança do Android. Se mostra fevereiro de 2026 ou posterior, essa cadeia específica não funciona mais.

Para outros dispositivos Android: a CVE-2025-54957 (Dolby UDC) afeta todos os dispositivos Android que usam o codec Dolby. O patch para essa parte veio no Android Security Bulletin de janeiro de 2026. Verifique se o fabricante do seu dispositivo já aplicou.

A vulnerabilidade do VPU é específica do Tensor G5 (Pixel 10), mas bugs similares podem existir em drivers de outros chips. A lição aqui não é “mude de celular”, mas sim “mantenha atualizado e toque a vida”.

A transparência que a indústria precisa

Eu tenho minhas críticas ao Google, mas uma coisa eles fazem melhor que qualquer outro fabricante de celulares: financiam uma equipe interna (Project Zero) para hackear seus próprios produtos e publicar tudo abertamente. A Apple não faz isso. A Samsung não faz isso. A Qualcomm não faz isso.

Quando o Project Zero encontra um bug no Pixel, publica o exploit completo — código, técnicas, timeline. Isso permite que outros pesquisadores aprendam, que a comunidade de segurança audite, e que a indústria inteira se beneficie. O paper do Pixel 9 de janeiro de 2026 diretamente levou à descoberta e correção do bug do VPU no Pixel 10.

Esse ciclo de “hackear → publicar → corrigir → repetir” é provavelmente a razão pela qual os Pixels, apesar dos bugs, continuam entre os dispositivos Android mais seguros em médio prazo. O problema não é ter vulnerabilidades — todo software complexo tem. O problema é não procurar por elas.

Se o Tensor G6 chegar no Pixel 11 sem que os drivers passem por uma auditoria de segurança tão rigorosa quanto o kernel, aí sim teremos algo para reclamar. Por enquanto, o fato de que uma “revisão rápida de 2 horas” encontrou um bug trivial em driver de produção sugere que o Google tem trabalho sério a fazer na cadeia de supply chain de firmware dos seus chips.

—

Fonte de inspiração: A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens — Google Project Zero