O problema que o heartbeat resolve
O cheat mais difícil de detetar é aquele que desativa discretamente o cliente do teu anticheat e depois corre sem ser observado. As verificações por assinatura podem levar hooks. A inspeção NUI pode ser bloqueada. As funções de integridade em runtime podem ser anuladas com patches. Assim que a camada de cliente fica em silêncio, um AC de camada única fica cego. O heartbeat anti-adulteração existe para tornar esse silêncio caro: a ausência de heartbeat é, por si só, uma deteção.
Como funciona o ciclo de heartbeat
O cliente Raven emite um payload assinado com uma cadência fixa (adaptativa por servidor, ver a entrada de changelog de 2026-02-17; anteriormente fixa em 1500 ms). O payload inclui um hash criptográfico do estado crítico em runtime (integridade dos recursos, impressão digital da tabela de hooks, endereços dos handlers de eventos) mais um timestamp e um nonce por sessão. O servidor verifica a assinatura, compara o hash com a linha de base esperada e regista o tempo entre chegadas. São detetados três modos de falha: o heartbeat não chega (cliente silencioso), o heartbeat chega mas o payload já não corresponde aos valores esperados (cliente adulterado) ou o heartbeat chega com a cadência errada (cliente repetido ou desatualizado).
Porque é que a cadência importa
Uma janela de heartbeat fixa é mais fácil de contornar. Um cheat que desative brevemente o cliente entre heartbeats consegue manter o ciclo vivo e continuar a correr sem ser observado. A cadência adaptativa por servidor (calibrada com a latência média de tick nas primeiras 24 h) torna essa janela imprevisível para o cheat sem criar problemas a jogadores legítimos em rotas de latência alta. A versão de 2026-03 reequilibrou a janela padrão, passando de 1500 ms fixos para um intervalo adaptativo de 800 a 1500 ms, o que baixou os falsos positivos em rotas EU/AS em cerca de 38%.
O que acontece quando o heartbeat falha
As respostas a falhas são configuráveis por servidor em três níveis. O nível 1 (aviso) marca o jogador no mapa em direto e notifica os admins pelo webhook de Discord configurado. O nível 2 (kick) retira o jogador do servidor com um motivo de desconexão genérico e regista o evento com provas completas (último heartbeat válido, timestamp atual, diferenças no payload). O nível 3 (ban automático) bane o jogador no servidor local e coloca-o em fila para promoção à Base de Dados Global de Bans depois da revisão de um admin. A configuração padrão é conservadora (avisar primeiro, escalar só em caso de repetição), porque a camada de heartbeat pode produzir falsos positivos durante problemas legítimos de rede.
Como o heartbeat interage com o trust score
Cada anomalia de heartbeat contribui para o trust score do jogador (introduzido na versão 2026.4.0, ver /changelog). Um heartbeat atrasado isolado é ruído. Vários heartbeats atrasados do mesmo jogador em várias sessões, um heartbeat que fica para trás especificamente quando o jogador entra em certos estados de jogo, ou um heartbeat que devolve sempre o mesmo hash apesar de o pacote de recursos ter sido atualizado: são todos sinais que colocam o jogador no mapa em direto para revisão dos admins muito antes de disparar qualquer ban de nível 3.