WhatsApp não oficial: protocolos, libs e gateways

Não é "hackear". O evolution-go é um cliente WhatsApp não oficial — ele se conecta da mesma forma que o WhatsApp Web/Desktop, usando a biblioteca whatsmeow (Go).

Como funciona de verdade

1. Multi-Device do WhatsApp Web: seu celular é o dispositivo primário. Existe um protocolo (WebSocket + Protocol Buffers, com handshake Noise) que o WhatsApp Web usa para parear.
2. O whatsmeow reimplementa esse protocolo (engenharia reversa do tráfego do Web/Desktop), não explora um bug.
3. No pareamento, o celular gera um QR code com uma chave pública temporária. Você escaneia → o celular transmite as chaves de identidade/prekeys pelo canal cifrado → o novo dispositivo passa a operar como um "companion device", com suas próprias chaves, mas vinculado à mesma conta.
4. Depois disso, a API REST do evolution-go manda/recebe mensagens se passando por esse dispositivo pareado.

Ou seja: exige acesso físico ao celular para escanear o QR (ou código de pareamento aprovado no aparelho). Não dá para invadir um WhatsApp alheio só rodando isso.

Riscos/alertas

• Viola os Termos de Uso do WhatsApp; a conta pode ser banida.
• Se a máquina onde roda vazar a sessão (as credenciais do dispositivo pareado), outra pessoa assume a conta — esse é o vetor real de "hack" nesse stack: servidor mal configurado (GLOBAL_API_KEY fraca, Redis/Postgres expostos) ou backups de sessão vazados.
• Bibliotecas não oficiais já tiveram falhas de confiança (o próprio Evolution teve polêmicas de licenciamento/telemetria). Trate como código sensível.

whatsmeow é a biblioteca Go que implementa o protocolo do WhatsApp Web Multi-Device. É a peça de baixo nível que projetos como o evolution-go usam para conversar com os servidores do WhatsApp. Criada por Tulir Asokan, licença MPL-2.0, ~7.4k stars.

Ponto central: não é oficial da Meta. É engenharia reversa do comportamento do WhatsApp Web/Desktop, mantida por comunidade.

O que ela faz

• Envia/recebe mensagens (texto e mídia) em chats privados e grupos
• Gerencia grupos, convites e links de convite
• Notificações de digitação, recibos de entrega/leitura
• Lê e escreve app state (lista de contatos, fixar/silenciar chats)
• Trata retry receipts quando a descriptografia falha
• Status/Stories (experimental)

Como funciona por dentro

A estrutura de pastas revela as camadas:

• socket/ — a conexão real. WebSocket + handshake Noise (o mesmo esquema de cifragem de transporte que o WhatsApp Web usa). Também trata keepalive e reconexão.
• binary/ — codifica/decodifica os "nós" binários do protocolo WhatsApp (formato tokenizado, com dicionário de tokens e packing de bits). É aqui que mora a engenharia reversa do wire format.
• proto/ — as definições Protobuf (geradas em Go) das mensagens do WhatsApp.
• store/ — persistência. Guarda a identidade do dispositivo (par de chaves), sessões Signal, prekeys e app state. Você normalmente usa sqlstore (SQLite/Postgres).
• appstate/ — sincronização do estado do app (contatos, configurações) usando o esquema de patches/versões do WhatsApp.
• types/ — tipos de mensagem (texto, imagem, reação, poll, etc).
• argo/ — serialização da estrutura de mensagem para o formato compacto que o WhatsApp exige.
• Raiz: client.go (o Client), pair.go/pair-code.go (pareamento por QR e por código), prekeys.go, send.go, message.go, call.go, group.go, newsletter.go, presence.go, etc.

Fluxo típico de uso

container, _ := sqlstore.New("sqlite3", "file:session.db", nil)
deviceStore, _ := container.GetFirstDevice()
client := whatsmeow.NewClient(deviceStore, nil)

client.AddEventHandler(func(evt interface{}) { /* trata eventos */ })

if client.Store.ID == nil {
    qrChan, _ := client.GetQRChannel(...)
    client.Connect()          // gera QR
    // imprime/entrega o QR para o usuário escanear no celular
} else {
    client.Connect()          // já pareado, reconecta
}

client.SendMessage(ctx, jid, &waE2E.Message{ ... })

O pareamento é o mesmo do WhatsApp Web: QR (ou código de 8 dígitos) → o celular aprova → o dispositivo ganha sua própria chave de identidade mas fica vinculado à mesma conta. Tudo fim-a-fim cifrado via Signal (prekeys + double ratchet).

Limitações e observações

• Chamadas não são implementadas (call.go existe mas o suporte é incompleto).
• Broadcast lists não funcionam (o WhatsApp Web também não suporta).
• É frágil por natureza: você quebra quando a Meta muda o protocolo, e a conta pode ser banida por uso automatizado — não é canal oficial.
• O mesmo problema resolvido em Node.js é o Baileys; o evolution-api usa Baileys, o evolution-go usa whatsmeow.

Se você quer entender o protocolo a fundo, comece por socket/ (transporte/handshake) e binary/ (formato dos pacotes) — o resto é consequência desses dois.

O whatsmeow é uma biblioteca: você a importa no seu programa Go e ela vive dentro do seu processo. O evolution-go é um serviço/produto que embrulha essa biblioteca e resolve tudo que um time precisa para operar WhatsApp em produção.

Camada por camada, o Evolution adiciona

1. API REST + Swagger

Em vez de você escrever Go para cada operação, expõe endpoints prontos: POST /instance/create, GET /instance/{name}/qrcode, POST /message/sendText, POST /message/sendMedia, GET /instance/{name}/status, DELETE /instance/{name}. Documentação em /swagger/index.html.

2. Multi-instância (multi-tenant)

O whatsmeow gerencia um Client/dispositivo. O Evolution gerencia vários números simultâneos, cada um com seu store, status, webhook e ciclo de vida — nomes de instância, criação, reconexão e remoção via HTTP.

3. Distribuição de eventos

O whatsmeow entrega eventos via callback em Go (AddEventHandler). O Evolution transforma isso em canais prontos para integrar: WebSocket, Webhook HTTP, AMQP/RabbitMQ e NATS. Você recebe mensagens/eventos sem estar no processo Go.

4. Persistência

Opcional de mensagens/estado em PostgreSQL via GORM (DATABASE_SAVE_MESSAGES), com bancos separados para auth e usuários. No whatsmeow você escolhe e monta seu store manualmente.

5. Armazenamento de mídia

Integração com MinIO/S3 para upload/download de imagens, vídeos, áudios e documentos.

6. Autenticação e controle de acesso

GLOBAL_API_KEY + middlewares de auth/validação em cima da API. A biblioteca não tem noção de API key.

7. Licenciamento (gate comercial)

Registro, ativação e heartbeat periódico. Sem licença, os endpoints retornam 503. Isso é regra de negócio da Evolution Foundation, não existe no whatsmeow.

8. Manager (UI web)

Painel em /manager/login para configurar URL/chave e fazer o fluxo de pareamento/QR sem escrever código.

9. Operação/Deploy

Dockerfile, Makefile (make docker-build, make docker-run, make dev), .env.example — configuração padronizada, pronto para subir em VPS.

O que ele não muda: continua sendo cliente não oficial, o risco de ban é o mesmo, e chamadas/broadcast lists seguem sem suporte (vêm da limitação do whatsmeow).

São dois recursos do próprio WhatsApp que o whatsmeow (e portanto o Evolution) não consegue usar via API:

Chamadas (calls)

São as chamadas de voz e vídeo do WhatsApp (individuais e em grupo), incluindo o "tocar" pra avisar o outro número. No WhatsApp Web/Desktop isso aparece como aquele botão de telefone/câmera.

Por que não funciona: chamada de voz/vídeo usa um stack separado — sinalização própria, WebRTC para o áudio/vídeo e servidores de relay/STUN da Meta. O call.go existe, mas só recebe alguns eventos básicos; não implementa estabelecer, atender, áudio/vídeo nem encerrar. Ou seja, não dá para "discar" ou atender uma ligação pela API.

Broadcast lists (listas de transmissão)

É o recurso "Lista de transmissão" do WhatsApp: você cria uma lista de contatos (ex.: "Clientes") e, ao mandar uma mensagem pra ela, cada contato recebe como uma conversa individual — ninguém vê os outros destinatários nem sabe que é uma lista. Diferente de um grupo, onde todos se veem.

Por que não funciona: o WhatsApp Web/Desktop também não suporta listas de transmissão — elas só existem no app móvel e são gerenciadas no servidor a partir do celular primário, com um fluxo que os clientes web/linked não recebem. Como o whatsmeow se comporta como um dispositivo linked (igual ao Web), ele não consegue criar nem disparar para essas listas.

Não é "migrar" — é reescrever. whatsmeow é Go e não existe tradução automática; o que você migra é o comportamento do protocolo, usando Baileys/whatsmeow como referência. E é difícil, mas o ecossistema Elixir já está resolvendo isso.

Quão difícil é, de fato

Reescrever do zero: muito difícil (meses a 1 ano+). Motivos:

• Volume e maturidade: whatsmeow tem ~1.667 commits e anos de engenharia reversa de casos de borda. Não é só "mandar mensagem": é token dictionary binário, handshake Noise com certificados, Signal double ratchet, retry receipts, LTHash do app state, encoding WAM (analytics), cifragem de mídia.
• Crypto tem buracos no Erlang: :crypto (OpenSSL) cobre AES-GCM, HKDF, X25519, HMAC, SHA. Não cobre XEdDSA (o esquema de assinatura do Signal que o WhatsApp usa). Você acaba precisando de NIF (Rust/C) — exatamente o que os ports fazem.
• Não dá pra embutir Go na BEAM de forma limpa: Go tem runtime próprio (goroutines), e NIF que bloqueia scheduler + panic/segfault do Go derruba a VM. NIF do whatsmeow é má ideia; sidecar é o caminho.

O que já existe (não comece do zero)

O ecossistema Elixir é todo baseado em Baileys, não em whatsmeow:

• baileys_ex (jeffhuen) — port do Baileys para Elixir, com Signal Protocol em Elixir puro + NIFs Rust (snow para Noise, xeddsa). Está em alpha, ~1.263 downloads, 6 stars. Supervisão OTP com :gen_statem.
• amarula (Roberto Trevisan) — outro port do Baileys, MIT, v0.3.0.
• irish — abordagem sidecar: roda Baileys num subprocesso Deno e conversa com ele. Muito mais simples e robusto, mas mantém processo externo.
• whatsapp_elixir / whatsapp_sdk — wrappers da Cloud API oficial da Meta (nada a ver com protocolo não oficial).

Por que portar Baileys e não whatsmeow

• Modelo de concorrência: Baileys é event-emitter/async → mapeia quase direto para GenServer/Task. Go (interfaces, canais, goroutines) não traduz tão limpo para OTP.
• Licença: whatsmeow é MPL-2.0 (copyleft por arquivo — um port é derivado e herda obrigações). Baileys é MIT, muito mais permissivo para derivar. Não é coincidência os ports Elixir serem MIT e citarem Baileys.

Recomendação prática

Resumo: portar whatsmeow é hard pela via errada. Se quer Elixir nativo, o atalho real é contribuir num port de Baileys já existente (baileys_ex/amarula); se quer resultado rápido, sidecar. E em qualquer caso você assume a manutenção eterna de acompanhar as mudanças do protocolo da Meta.

Baileys é o equivalente do whatsmeow, mas em TypeScript/Node.js: uma biblioteca que implementa o protocolo do WhatsApp Web Multi-Device direto por WebSocket, sem automação de navegador (nada de Puppeteer/headless Chrome).

Como no whatsmeow, não é oficial da Meta — é engenharia reversa — e o uso viola os Termos de Uso, com risco de ban.

Origem e manutenção

• Criada por Adiwajshing (adiwajshing/Baileys), virou o padrão de fato para bots de WhatsApp em JS.
• Hoje é mantida pela comunidade em WhiskeySockets/Baileys (repositório atual). Versão atual da linha v7 está em RC (o baileys_ex rastreia a v7.0.0-rc14).
• Licença MIT — por isso é a base preferida dos ports (Elixir, Rust, etc.), diferente do MPL do whatsmeow.

O que faz

• Pareamento por QR ou código (companion device)
• Envio/recebimento de mensagens — texto e mídia (imagem, vídeo, áudio, doc, sticker)
• Grupos e comunidades, convites, participantes
• Notificações de digitação, recibos de leitura/entrega
• App state sync (contatos, fixar/silenciar, arquivar)
• Status, presença, chamadas (parcial, igual ao whatsmeow)

import makeWASocket, { useMultiFileAuthState } from '@whiskeysockets/baileys'

const { state, saveCreds } = await useMultiFileAuthState('auth_info')
const sock = makeWASocket({ auth: state })
sock.ev.on('creds.update', saveCreds)
sock.ev.on('messages.upsert', m => console.log(m))

Baileys vs whatsmeow

Contexto do fio: o evolution-api (Node) usa Baileys; o evolution-go usa whatsmeow. São a mesma ideia em linguagens diferentes. E, por ser MIT e por o modelo event-emitter mapear bem para OTP, Baileys é a referência que os ports Elixir estão seguindo — não o whatsmeow.

"Na teoria" depende da dimensão — não existe vencedor único:

• Performance/recursos → Go (evolution-go): multi-thread real, footprint baixo (dezenas de MB), um binário só, aguenta muito mais instâncias por host.
• Maturidade/features → Node (evolution-api): é o projeto original, muito mais antigo, feature set e ecossistema enormes.
• Aposta segura hoje → Node. Go só ganha se escala/recursos forem o gargalo real.

Comparação por dimensão

O que pesa de verdade

1. Maturidade assimétrica: os dois são da mesma fundação, mas o Node é o produto maduro. O evolution-go tem 19 commits — é early. Em teoria, a arquitetura Go é melhor; na prática, o Node entrega mais coisas hoje.
2. Event loop vs goroutines: Baileys num processo Node lida com todos os números no mesmo loop. Com muitas instâncias ativas (milhares de eventos/s), isso vira head-of-line blocking. Go distribui em cores. Esse é o argumento técnico mais forte do Go.
3. Protocol parity: Baileys tem comunidade gigante e implementa mais cantos (mais tipos de mensagem, newsletters, etc.). O whatsmeow é excelente, mas o produto em cima é imaturo.
4. Licenciamento: o 503 até ativar + heartbeat do evolution-go é um gate comercial e um ponto de dependência externa. Se for auto-hospedar de forma crítica, isso incomoda.

Recomendação

• Precisa de features/integrações e quer algo provado → Node (evolution-api).
• Muitos números por máquina, memória/custo importam, time Go → Go, aceitando que é mais imaturo.
• Só quer o protocolo e vai construir o resto → use a lib direto: Baileys (Node) ou whatsmeow (Go), sem o Evolution por cima. Aí a escolha é de linguagem, não de produto.

Resumo: em teoria Go ganha em engenharia (concorrência/recursos); Node ganha em produto (maturidade/features). Na prática, hoje, o Node ainda é a escolha mais segura — o Go é a aposta de arquitetura.

Existem várias, em três camadas. Contexto importante: em início de 2026 a Meta intensificou a detecção de clientes não oficiais — avisos de "sua conta pode estar em risco" estão atingindo usuários de todas as libs (Baileys, whatsmeow, WEBJS), mesmo em baixo volume. Vale para qualquer opção abaixo.

1. Gateways prontos (alternativas diretas ao Evolution)

WAHA — WhatsApp HTTP API (devlikeapro/waha, ~7.3k stars, Apache-2.0)

A alternativa mais forte. É um "glue layer" Node que suporta 4 engines trocáveis por variável de ambiente:

• WEBJS — whatsapp-web.js (Puppeteer/Chromium)
• WPP — WPPConnect (Puppeteer)
• NOWEB — Baileys (WebSocket, sem browser)
• GOWS — whatsmeow (Go), geração nova

Design esperto: se uma abordagem quebrar, você troca de engine sem reescrever a integração. Modelo: core grátis + tier pago (Plus).

GOWA (aldinokemal/go-whatsapp-web-multidevice)

Go/whatsmeow, REST API + UI, multi-account, webhooks, MCP e Chatwoot. É o "evolution-go" sem o gate de licença.

WPPConnect Server

Node, Puppeteer, comunidade brasileira grande, servidor pronto.

Cobalt (Auties00/Cobalt)

Java/Kotlin, completo, standalone, para quem está no ecossistema JVM.

Outros: chrishubert/whatsapp-api (wrapper do whatsapp-web.js), salman0ansari/whatsapp-api-nodejs, CodeChat, OpenWA, Venom.

2. Bibliotecas (você constrói o resto)

Protocolo direto (WebSocket, sem browser) — leves, mais arriscados de detecção:

• Baileys (TS/Node) — a dominante
• whatsmeow (Go)
• whatsapp-rust (Rust), baileyrs (Rust+JS)
• Elixir: baileys_ex, amarula

Automação de browser (Puppeteer/Chromium) — mais pesadas, historicamente mais "invisíveis":

• whatsapp-web.js, WPPConnect/wa-js, Venom

Custo: browser roda Chromium, então são centenas de MB por instância vs. dezenas na via WebSocket.

3. Oficial (Meta)

• WhatsApp Business Cloud API — oficial, templates, janela de 24h, pago por conversa.
• BSPs (revendedores oficiais): Twilio, Infobip, 360dialog, Gupshup, Bird, Vonage, Wati, Zenvia.

Como escolher

Resumo: WAHA é a alternativa mais direta e flexível ao Evolution; GOWA é o caminho Go livre; e se ban/compliance for inegociável, a única resposta é a API oficial.

É uma trava de execução em runtime, separada da licença legal. O arquivo é deliberadamente ofuscado (nome c0.go, identificadores como _sn, _kni, _txz) para dificultar remoção. Detalhe crucial: o heartbeat é non-blocking.

Servidor de licença

https://license.evolutionfoundation.com.br — ofuscado em c0.go:35-45, montado a partir de fragmentos de string. Há um decodificador XOR (_k54v) com duas chaves (_k1/_k0) que nunca são usadas — código morto/isca.

Requisições são assinadas: header X-Api-Key + X-Signature = HMAC-SHA256(body, api_key) (c0.go:85-107).

O gate

GateMiddleware (c0.go:638): allowlist apenas /health, /server/ok, /license/*, /manager*, /assets*, /passkey-ceremony*, /swagger*, /ws e estáticos. Todo o resto → HTTP 503:

{ "error": "service not activated", "code": "LICENSE_REQUIRED",
  "register_url": "https://<host>/manager/login" }

Como ativa (ordem real no código, c0.go:441)

1. Licença no banco (runtime_configs.api_key) → ativa na hora; dispara /v1/activate non-blocking.
2. GLOBAL_API_KEY → usada como token de licença: tenta /v1/activate; se OK, salva key+tier e ativa. Detalhe: _58 (c0.go:891) aceita a string crua como API key se o exchange falhar.
3. EVOLUTION_OPERATOR_EMAIL → /v1/register/auto.
4. Nada disso → inativo, banner "License Registration Required" e 503.

O detalhe que importa: heartbeat não derruba nada

StartHeartbeat (c0.go:839): a cada 30 min chama /v1/heartbeat; se falha, só imprime ⚠ Heartbeat failed (non-blocking) — não desativa. E ValidateContext (c0.go:623) checa apenas estado local: flag _txz + sha256(api_key + instance_id) batendo com o hash capturado na ativação.

• Depois de ativada, nunca revalida remotamente. Sem expiração, sem grace period — ficar offline indefinidamente continua funcionando.
• Só a primeira ativação precisa de rede. Se a key já está no banco, o boot nem depende do servidor deles.
• O que derruba é só: nunca ter ativado, ou adulterar api_key no banco (quebra o hash local).

Binding e telemetria

• instance_id = UUID determinístico de hostname + MAC (primeira interface não-loopback), ou aleatório se indisponível (c0.go:274-307). Guardado em runtime_configs.instance_id.
• Não é hardware-lock rígido: no boot o hash é recomputado com o id atual, então mover o banco para outra máquina ainda funciona (só muda a identidade reportada).
• O heartbeat envia instance_id, uptime_seconds, version e um telemetry_bundle com contagens agregadas messages_sent/messages_recv desde o último beat (c0.go:924) — sem conteúdo de mensagem.

Licença de código (separada do gate técnico)

LICENSE:3-9 — Apache-2.0 + condições: (a) não remover LOGO/copyright do frontend; (b) Usage Notification: exibir aviso visível de que usa Evolution Go, senão pode exigir licença comercial.

Comparei três: GOWA (Go livre), Evolution Go (Go com gate) e Evolution API (Node, o produto maduro). A diferença mais importante não é feature — é licença e maturidade.

Leitura rápida

• GOWA vence em liberdade: MIT, sem gate, MCP nativo e um cuidado de segurança acima da média (HMAC nos webhooks, filtros por evento/JID, SHA-256 pinning da UI). É o "evolution-go sem catraca".
• Evolution Go perde hoje para o GOWA em quase tudo: menos commits, sem MCP, e o gate de licença. Só ganha em brokers de eventos (RabbitMQ/NATS) e no Manager embutido.
• Evolution API (Node) continua sendo o mais completo em produto: ecossistema de integrações e maturidade que os dois Go não têm. Preço: mais memória e o event loop único.

São filosofias opostas: o GOWA é um motor só, em Go. O WAHA é uma camada de cola que roda vários motores e deixa você trocar por variável de ambiente. Detalhe importante: o motor GOWS do WAHA é o whatsmeow — ou seja, o WAHA praticamente contém o GOWA como uma de suas opções.

Leitura rápida

• A diferença central não é feature — é arquitetura. O WAHA aposta em redundância de motor; o GOWA aposta em simplicidade e controle.
• O WAHA contém o GOWA: ao rodar GOWS, é literalmente o whatsmeow por baixo. A vantagem do WAHA é poder cair para Baileys ou Chromium sem reescrever nada.
• O GOWA entrega grátis o que no WAHA é Plus: multi-conta, MCP, webhook por device e Chatwoot nativo.
• O WAHA é mais maduro e mais testado (7.4k stars, 2.366 commits) e tem as melhores ferramentas de operação (dashboard, Swagger, imagem por engine).