Uma chamada que não pede nada

Um telemóvel acende com uma videochamada a entrar por VoLTE, a norma de voz sobre LTE que hoje transporta a maioria das chamadas nas redes modernas. A pessoa que o segura ainda não tocou em nada. Algures abaixo do sistema operativo, numa parte do chip de que a maioria dos proprietários nunca ouviu falar, o modem já está a processar por conta própria a sinalização da videochamada no seu próprio núcleo de processador separado.

Esse núcleo separado é o alvo. Investigadores de segurança da SSD Secure Disclosure publicaram um aviso a 17 de agosto de 2026 que descreve uma cadeia de exploração funcional contra o Unisoc T612, um chipset presente numa vasta gama de telemóveis Android económicos e de gama média. O caminho de entrada passa pelo tratamento, por parte do modem, da sinalização de videochamadas VoLTE, não pelo sistema operativo Android que o utilizador vê.

O The Hacker News, que também noticiou o aviso, resumiu a importância com clareza: não se trata de uma fragilidade teórica descrita num artigo de laboratório, mas de uma cadeia demonstrada em que uma exploração funcional pode levar de uma chamada telefónica ao controlo do kernel do dispositivo, sem que o utilizador precise de abrir uma aplicação, clicar numa ligação ou conceder qualquer permissão além de deixar o telemóvel tocar.

Dentro da cadeia de três fases

Os investigadores descrevem a exploração como três fases encadeadas. A primeira é o que chamam de egg hunter, uma técnica que percorre a memória à procura de uma pequena carga previamente colocada assim que o atacante dispõe de algum tipo de acesso de escrita, em vez de precisar de conhecer antecipadamente os endereços exatos de memória. É um passo de reconhecimento que transforma um ponto de apoio estreito num ponto utilizável.

A segunda fase é a mais determinante: uma forma de contornar a MPU do chip, a unidade de proteção de memória, a funcionalidade de hardware que deveria manter o ambiente de execução do modem isolado da memória sensível. A SSD Secure Disclosure afirma que a exploração desativa essa proteção e depois escreve diretamente shellcode ao nível do kernel, dando ao atacante acesso físico irrestrito à memória a partir do próprio ambiente de execução do modem, uma zona que nunca deveria ter alcançado tal profundidade.

A terceira fase é um trampolim através de do_sys_open, uma função de baixo nível do kernel usada para abrir ficheiros, que a cadeia reaproveita para passar do acesso bruto à memória ao controlo total do kernel do lado Android. Encadeadas, as três fases levam um atacante desde uma videochamada VoLTE recebida até ao controlo do próprio kernel do sistema operativo, algo próximo do nível máximo de acesso que um dispositivo pode conceder.

Uma família de chips, não um único telemóvel

A SSD Secure Disclosure e o The Hacker News indicam ambos dois dispositivos confirmados como afetados: o Xiaomi Redmi A5 e o Motorola E13, dois dos telemóveis Android de gama de entrada mais vendidos na Europa e além dela. Ambos são exatamente o tipo de dispositivo que uma empresa compra em grandes quantidades para pessoal que precisa de um telemóvel funcional, não de um topo de gama.

A exposição não se limita a esses dois modelos. Os chipsets Unisoc representam cerca de 14 por cento do mercado mundial de sistemas num chip para smartphones, uma quota construída quase inteiramente sobre dispositivos económicos e de gama média, e o T612 em particular equipa telemóveis vendidos sob marcas como Honor, Realme, vivo, Samsung e Motorola. Nem todos os telemóveis com Unisoc usam o T612, mas o alcance da família de chips em várias marcas importantes significa que a exposição prática é maior do que dois nomes de modelo sugerem.

Essa combinação, um chip amplamente usado num segmento de mercado pouco glamoroso, é precisamente o que torna a falha relevante a nível comercial e não apenas académico. Os dispositivos Android económicos e de gama média são a escolha padrão para frotas, entregas, retalho, armazéns e pessoal de campo, exatamente as categorias de hardware que se compram em volume e se atualizam com menos frequência.

Por que motivo o processo normal de correção ainda não se aplica

Aqui está o pormenor que separa esta história de uma vulnerabilidade de chip rotineira: à data desta publicação não foi atribuído qualquer identificador CVE à falha, e não existe qualquer correção da Unisoc. A SSD Secure Disclosure declarou sem rodeios que contactou o fabricante através de dois canais distintos, correio eletrónico e LinkedIn, e não conseguiu obter qualquer resposta. Esse silêncio faz agora parte da própria divulgação.

A gestão de vulnerabilidades empresarial habitual funciona com números CVE. Os scanners verificam bases de dados de vulnerabilidades conhecidas, as listas de verificação de compras referem identificadores CVE, e os ciclos de correção são medidos em função deles. Uma falha sem CVE simplesmente não aparece em nenhuma dessas ferramentas, o que significa que uma organização pode executar um processo de gestão de vulnerabilidades totalmente conforme e ainda assim ter visibilidade zero sobre uma exploração de kernel ativa e ativável remotamente na sua própria frota de dispositivos.

Para uma empresa europeia com uma política BYOD, ou que entrega telemóveis Android económicos ou de gama média ao seu pessoal, a resposta prática não pode esperar por um alerta de scanner que não tem nada para procurar. As equipas de compras e de gestão de dispositivos deveriam verificar já hoje, por modelo de dispositivo e chipset, se existe hardware Unisoc T612 em uso, em vez de esperar por uma entrada CVE que pode não surgir segundo qualquer calendário previsível.

Nada disto significa que nunca vai chegar uma correção. Significa que, por agora, a única forma fiável de saber se uma frota está exposta é olhar diretamente para o hardware que está implementado, porque o sistema habitual de alerta precoce não tem nada sobre que alertar.

Leia a seguir: A Google deixou de absorver o preço da memória  |  Duas Ferramentas Open Source Caíram em Horas