1
felipebevi
2 min de leitura ·

Coloquei WhatsApp e Telegram em celulares de 2004 e o difícil foi o TLS

Sou o desenvolvedor do ZapTijolo, um app que leva WhatsApp, Telegram e um assistente de IA para celulares Java ME: Nokia Series 40 e S60, Motorola e BlackBerry. Quero contar a parte técnica, que foi bem mais estranha do que eu imaginava.

A arquitetura

O celular roda um MIDlet de cerca de 155 KB (CLDC 1.0 / MIDP 2.0, telas nativas LCDUI). Ele não tem memória nem bibliotecas para rodar um cliente moderno, então um servidor em Go faz o trabalho pesado: segura a sessão do Telegram (gotd, API oficial) e a do WhatsApp como aparelho vinculado (whatsmeow, não oficial). Com o app aberto, o celular consulta o servidor a cada 60 segundos por um protocolo enxuto.

O TLS de 2007

  • Muitos Nokia só falam TLS 1.0 com RSA e AES-CBC-SHA e não mandam SNI. Sem SNI, um proxy reverso não sabe para onde mandar a conexão, então a API do celular roda numa porta própria, fora do proxy, com cadeia de certificados própria.
  • O Nokia 6500 slide compara a hora local como se fosse UTC. No Brasil (UTC−3), um certificado recém-emitido ficava "ainda não válido" por horas. Solução: os certificados começam a valer em 2007.
  • O navegador desses aparelhos não abre o HTTPS moderno (Let's Encrypt com SNI), então a página de instalação precisa existir também em HTTP.

Outras surpresas

  • O Nokia 6600 (2003) só aceita app CLDC 1.0: qualquer outra coisa dá "Versão inválida". O app inteiro foi rebaixado para CLDC 1.0.
  • Navegadores S40 ignoram display:block e padding em links. Botões viraram células de tabela com bgcolor, como em 2005.
  • Áudio: o celular grava AMR. Converter direto de AMR para Opus saía com timestamps errados; passar sempre por PCM no servidor resolveu.
  • Um Player de áudio esquecido aberto bloqueia o próximo. Fechar sempre, até no erro.
  • Pouca memória (heap de 1–2 MB): fotos limitadas a 96 KB e áudio a 320 KB.

O que não é

O WhatsApp é não oficial (aparelho vinculado) e o smartphone principal precisa entrar online a cada 14 dias. A compatibilidade depende do firmware de cada aparelho, já rodou até num Samsung com Windows Mobile. As mensagens passam pelo servidor, porque o celular antigo não roda os clientes modernos.

Por demandar um servidor 24/7 e uma segurança entre APP/SERVER, não deixa de ser um serviço pago (R$ 9,99/mês, 3 dias grátis; a IA é adicional): https://zaptijolo.com.br

Pergunta para quem chegou até aqui: qual celular da gaveta você traria de volta?

Carregando publicação patrocinada...
1

Os certificados começam em 2007 para o 6500, que lê a hora local como UTC. A instalação, porém, continua em HTTP, porque o navegador não abre o HTTPS moderno. O JAR do MIDlet vai assinado, ou o arquivo baixa por esse HTTP sem outra checagem?

1

Boa pergunta, e a resposta honesta é: não vai assinado, e pelo HTTP não existe outra checagem de integridade além do tamanho declarado no JAD (que também vem pelo HTTP). Quem estiver no meio do caminho no momento do download consegue trocar o arquivo.

Eu cheguei a implementar a assinatura MIDP 2.0 (RSA/SHA-1 no JAD), mas ela não resolve o problema nesses aparelhos: o celular só confia em assinaturas que encadeiam numa raiz que já vem nele (fabricante, operadora ou os programas antigos tipo Java Verified), e essas raízes não emitem mais nada. Com certificado próprio, o aparelho recusa ou trata como não confiável, então a assinatura daria uma sensação de segurança que não existe.

O que existe hoje:

a página de instalação tenta HTTPS primeiro; o HTTP é a alternativa para o navegador que não abre o HTTPS moderno;
quem quiser evitar o HTTP pode baixar o JAR pelo painel (HTTPS, com login) no computador e passar para o celular por cabo, Bluetooth ou cartão;
depois de instalado, o app fala com o servidor por TLS próprio com a chave do servidor fixada no app, e o celular só entra na conta depois do pareamento com o código de 6 números.

Isso protege a comunicação depois da instalação, não a instalação em si: se o JAR for trocado no download, o pinning não ajuda. O risco é de quem está no caminho naquele momento (Wi-Fi público, por exemplo), por isso a recomendação é instalar numa rede de confiança ou pelo cabo.

Uma melhoria que dá pra fazer rápido é publicar o SHA-256 de cada JAR na página em HTTPS, para quem quiser conferir no computador antes de passar pro celular. Vou colocar na lista.