WAP Guard

Um pequeno aplicativo Android que limpa os rastros do "SMS da Morte" (CVE-2026-58882): um SMS WAP Push malformado que derruba o com.android.phone, descarta chamadas e permanece na fila, fazendo com que a falha se repita até que a mensagem seja removida.

O WAP Guard não impede a falha, porque apenas o patch de segurança do Android corrige o bug — o boletim de outubro de 2026, para Android 14–17. O que ele faz é remover as mensagens presas da fila de SMS pendentes, para que o problema não continue voltando e para que o telefone tenha menos chance de entrar em um ciclo de reinicialização.

No Android 12 e 13 não há correção: eles executam o mesmo código e estão fora de suporte, então a limpeza é a única mitigação além de atualizar o aparelho.

Como funciona

Por meio do Shizuku, ele executa, como o usuário shell, os mesmos passos de recuperação que o pesquisador publicou para o ADB:

1. Encontra linhas em content://sms/raw cujo port de destino é WAP Push (2948) e que estão presas há mais de 2 minutos. WAP Push legítimo (notificações de MMS, provisionamento da operadora) sai da fila em milissegundos, então uma mensagem ainda em entrega nunca é tocada.
2. Em Clear: lê o app-op WRITE_SMS atual do shell, permite-o temporariamente, exclui exatamente aqueles IDs de linha, restaura o modo anterior (mesmo se a exclusão falhar) e então consulta novamente para verificar se sumiram. Apenas aqueles IDs — mais restrito do que a exclusão por address='<SENDER>' nos passos ADB publicados, e não precisa saber o remetente.

A idade de uma linha não pode ser simplesmente lida da sua coluna date. Essa coluna contém o timestamp do centro de serviço do PDU, não um horário de recebimento local — o InboundSmsHandler passa sms.getTimestampMillis() diretamente para a linha — então o SMSC do remetente controla isso, e uma mensagem envenenada datada com anos de antecedência nunca pareceria presa. Linhas datadas com mais de um minuto de adiantamento em relação ao relógio local são, portanto, cronometradas a partir de quando o WAP Guard as viu pela primeira vez no relógio local.

Todo comando shell tem um timeout, e tanto seu código de saída quanto sua saída são verificados. Uma concessão de WRITE_SMS deixada para trás por uma execução interrompida no meio da limpeza é revogada na próxima verificação, já que o finally não é executado quando o processo morre.

A tela principal também compara o nível de patch de segurança do dispositivo com o primeiro nível corrigido (2026-10-01) e informa Android 12–13 como não corrigível. Este é um indicador rápido, não um teste em nível de código: um fabricante poderia aplicar o backport da correção antes.

Verificação em segundo plano

Uma escolha exclusiva, Desligado por padrão:

	Intervalo	Custo
Desligado	—	Verifica quando você abre o app
15 min	O mínimo do WorkManager, maior sob Doze	Nenhum digno de nota
30 s	Modo vigilância, um serviço em primeiro plano	Notificação permanente, mais bateria

Um seletor em vez de dois toggles, porque os intervalos não são aditivos: WRITE_SMS é estado global do shell e não por chamador, então duas limpezas rodando ao mesmo tempo brigam por ele — uma restaura o modo anterior enquanto a outra ainda está excluindo, e essa exclusão falha. As limpezas são serializadas em um lock pelo mesmo motivo, já que o botão manual Clear pode se sobrepor a uma verificação em segundo plano.

O polling é o único mecanismo disponível. Não há evento para interceptar: WapPushOverSms.dispatchWapPdu chama decodeWapPdu antes de construir o intent WAP_PUSH_DELIVER_ACTION, então o decode lança a exceção dentro do com.android.phone e nenhum broadcast é jamais despachado para uma mensagem envenenada. O intervalo de polling é, portanto, a janela de exposição, que é a razão de existir o modo vigilância — 15 minutos de ciclo de falhas versus uma ou duas falhas.

Qualquer que seja a escolha, abrir o app limpa imediatamente em vez de esperar pela próxima verificação.

Se está acontecendo agora

Limpar a fila acaba com isso. As linhas só são perigosas porque ficam em content://sms/raw e são reprocessadas a cada inicialização, então uma vez excluídas o ciclo é quebrado — nada fica corrompido, e nenhuma limpeza adicional é necessária a menos que mais mensagens cheguem.

O problema é que um telefone que reinicia a cada dois minutos pode não ficar ligado tempo suficiente para você fazer qualquer coisa, então vale a pena saber o que cortar o rádio lhe proporciona.

O modo avião, ou remover o SIM, impede a chegada de novas cópias. Uma mensagem que o telefone nunca confirma é reenviada pela operadora — a pesquisa relata uma mensagem causando interrupções intermitentes por até uma semana. Sem rádio, não há entrega nem novas tentativas, o que lhe dá um telefone estável para trabalhar.

O que isso não faz:

• Não limpa nada. As linhas já na fila são reprocessadas a cada inicialização, independentemente do rádio, então se você já está em loop, ainda precisa limpá-las. O modo avião bloqueia a próxima cópia, não a que você já tem.
• As mensagens esperam por você. Tudo o que a operadora não entregou permanece do lado dela e chega quando você se reconectar.
• Você fica sem serviço, incluindo chamadas de emergência. É exatamente o que o ataque já estava tirando de você, então trate isso como uma medida provisória.
• O eSIM torna tudo mais difícil. Você não pode remover um eSIM, e desativá-lo exige passar pelas Configurações em um telefone que não para de reiniciar.

Mover o SIM para um telefone não-Android vale a pena considerar: esse dispositivo confirma as mensagens pendentes, então a operadora para de reenviá-las, e você pode então limpar o telefone Android sem que novas cópias cheguem no meio da limpeza. Isso decorre do comportamento de novas tentativas, e não de um passo publicado.

Como último recurso absoluto, adb shell pm clear com.android.providers.telephony esvazia a fila — junto com todas as suas configurações de SMS, MMS e APN. Limpar as linhas específicas, que é o que este aplicativo faz, quase sempre é suficiente.

Limitações

Nada aqui sobrevive a uma reinicialização, porque o Shizuku também não sobrevive sem root. Após a primeira reinicialização forçada, você precisa reemparelhar a depuração sem fio; o modo Watch percebe o binder morto, desliga-se em vez de drenar a bateria em verificações que só podem falhar, e avisa você.

Portanto, sob um ataque sustentado, a resposta honesta é que o WAP Guard encurta cada travamento, mas não pode impedi-lo. As correções reais são o patch de outubro de 2026, ou a sua operadora filtrar SMS binários para a porta 2948.

Requisitos

• Android 12+ com o Shizuku em execução (a depuração sem fio é suficiente; root não é necessário)
• Em Samsung: defina o uso de bateria do aplicativo como Sem restrições, ou a verificação em segundo plano será encerrada

Compilação

./gradlew assembleRelease
./gradlew testReleaseUnitTest   # row parsing, staleness, app-op mode

Kotlin e Jetpack Compose com Material 3 Expressive, minSdk 31, compileSdk 36.

As releases são assinadas com a chave de debug, portanto esta é uma build pessoal para sideload: a chave de debug é universalmente conhecida, então não trate um APK daqui como autenticado — compile você mesmo se isso for importante para você.

Créditos

Pesquisa de vulnerabilidade e o procedimento de recuperação via ADB: Mark Blaszczyk, smsofdeath.com.

Licença

MIT