ZenBoost — Segurança & Fluxo de Dados

O que é o ZenBoost

Otimizador de ping para jogos na mesma categoria de ExitLag/WTFast. Ele captura o tráfego dos executáveis de jogo configurados e o encaminha pelos relays ZenBoost quando a rota medida pelo relay é melhor que a direta — se a sua já está boa, o app mostra isso na tela em vez de fingir resultado.

Privilégios & pegada no sistema

Pergunta	Resposta
Administrador	Necessário — para carregar o driver de filtro WinDivert e aplicar os ajustes de desempenho (registro, plano de energia, propriedades do adaptador). Sem admin, o app abre e mede normalmente, só não aplica boost nem tweaks.
Driver instalado	WinDivert 2.2.2 — filtro de rede open-source e assinado, mesma classe de tecnologia do winpkfilter/nfapi do ExitLag. Carrega somente enquanto o boost está ativo; descarrega ao parar/fechar.
Serviço persistente	Nenhum. Sem Windows service, sem scheduled task, nada residente depois que o app fecha.
Autostart	Opcional, controlado pelo usuário, via chave `Run` padrão do registro.
Certificados instalados	Nenhum. Detalhes na próxima seção.

TLS & pinning de certificado

O app empacota a própria CA (ca.pem) e a carrega num QSslConfiguration local ao processo — ela substitui a lista de CAs confiáveis do próprio app, e de mais nada. O cert store do Windows nunca é tocado (sem certutil, sem escrita no root store).

É o oposto de um root CA de MITM: isso deixa o cliente mais estrito, não mais fraco — o app só consegue validar TLS contra a API do ZenBoost. Nem site público ele aceitaria.

Código: cpp/src/main.cpp — carrega a CA → configuração TLS padrão do processo.

O que o driver de rede vê (resposta honesta)

O WinDivert não filtra por processo no nível kernel — então a resposta honesta é: o filtro enxerga todos os pacotes UDP de saída (e SYNs TCP, quando a captura TCP está ativa). O app então decide por processo:

Camada FLOW recebe metadados de fluxo com ProcessId — src/dst/porta/PID, sem payload. É assim que identificamos o dono do pacote.
Não é jogo configurado → reinjetado na hora (WinDivertSend), intocado, sem leitura além dos cabeçalhos IP/UDP, nunca desviado, nunca logado.
É jogo configurado → encapsulado, cifrado e enviado ao relay.
TCP → só pacotes SYN de conexão nova (tcp.Syn && !tcp.Ack), e também só para processo de jogo.

O driver pode ver o tráfego em nível kernel, mas o código só toca no que é jogo. É a mesma arquitetura que o ExitLag usa — e só funciona com o boost ligado.

Código: cpp/src/capture.cpp — filtros, atribuição por fluxo, caminho de reinjeção.

Criptografia do túnel

Desde a 1.1.1, o plano de dados do relay é cifrado — não apenas encapsulado.

// pacote v2 "Z2"
magic | type | uid | exp | sid | seq | nonce(12) | ciphertext | tag(8)

Cifra: ChaCha20 (RFC 8439) — escolhida sobre AES por ser rápida em software, mesmo sem AES-NI.
Construção: encrypt-then-MAC — o tag HMAC-SHA256 cobre cabeçalho + nonce + ciphertext, e é verificado antes de decifrar.
Chaves: por sessão, derivadas da credencial efêmera de relay (HMAC(cred.key, "zb-enc-v1")). A credencial é emitida pela API, expira sozinha (campo exp) e deriva do master via HMAC(master, "zb1|uid|exp") — relays não precisam de banco.
Nonces: únicos por pacote, derivados deterministicamente de HMAC(enc_key, sid|seq|type) — retransmissão do mesmo pacote produz o mesmo ciphertext, nunca reuso de nonce.
Replay: janela deslizante de sequência descarta datagramas repetidos/antigos.
Compatibilidade: relays aceitam v1 (ZB, só autenticado) e v2; a resposta sai na versão que chegou. Clientes 1.1.1+ sempre enviam v2.

Caveat honesto: é criptografia hop-by-hop, como toda VPN/relay (WireGuard, ExitLag funcionam igual). No fio é ciphertext — ISP e observadores intermediários não leem nada. Dentro do relay, o pacote é decifrado para ser reencaminhado — o relay é um ponto de confiança, como qualquer VPS. Nosso compromisso: payloads nunca são logados nem armazenados, e o código do relay é auditável.

Código: zenboost/protocol.py e cpp/src/proto.h — mesmo formato nos dois lados.

Dados que saem da máquina

O quê	Destino	Motivo
Email/senha	API (TLS pinado)	Login
Telemetria de sessão	API	Ping direto vs relay, perda, FPS — a "prova" que o app mostra
Crash reports	API	Device id (hashed) + stack trace `módulo+offset` + versão — desligável nas Configurações
Tráfego do jogo	Relays	O produto em si — UDP/TCP encapsulados e cifrados

O app não lê memória de jogo, não injeta em processos e não toca anti-cheat. O HUD é uma overlay passiva click-through; a telemetria de FPS vem do PresentMon, ferramenta open-source da Intel.

Sobre crash reports: nada de dump de memória na rede — o .dmp fica só na máquina do usuário. O que sobe é texto: código da exceção, stack como módulo+offset (sem endereços ASLR) e as últimas linhas de log. O usuário pode desligar tudo em Configurações → Relatórios de erro — desligou, nada sai do PC. Throttle no cliente (máx 20/10min) e no servidor (por device).

Atualizações

Todo release é assinado: o updater verifica assinatura Ed25519 + SHA-256 antes de instalar, contra uma chave pública compilada no cliente. A cadeia de confiança não depende de TLS.

Code-signing Authenticode está no roadmap (exige certificado OV/EV pago — o produto está em beta e é autofinanciado). Até lá, o aviso do SmartScreen é esperado; as garantias verificáveis são o canal de update assinado e os hashes SHA-256 publicados.

Verificação do binário

Cada release publica SHA-256 + assinatura Ed25519 em /v1/latest. Verifique o instalador:

# PowerShell / Prompt
certutil -hashfile ZenBoost-Setup-<versão>.exe SHA256

O servidor também registra o hash do exe por release e sinaliza clientes cujo hash auto-reportado diverge — uma armadilha para binários adulterados.

Reportar uma vulnerabilidade

Fale direto com o desenvolvedor — pelo Discord ou pelo canal em que este documento chegou. Descreva versão, reprodução e impacto. Não há programa de bug bounty ainda (o produto está em beta), mas reports legítimos são tratados com prioridade e creditados.