Como integrar um anti-cheat de terceiros no MU Online

Integrar um anti-cheat de terceiros ao seu servidor de MU Online é um dos passos mais delicados da administração: feito bem, ele fecha buracos que a proteção nativa do emulador não cobre; feito mal, derruba jogadores legítimos em massa e mancha a reputação do servidor no primeiro dia. A diferença entre os dois cenários está no processo. Este guia mostra como acoplar uma solução externa de forma controlada — carregando o módulo no cliente, validando a presença dele no servidor via heartbeat, mantendo uma whitelist e um plano de rollback — para que a proteção entre em produção sem virar dor de cabeça. Os nomes de arquivos, chaves e limiares citados aqui são exemplos que variam por season/emulador; use-os como referência de conceito, não como valores absolutos.

Pré-requisitos

Antes de encostar em qualquer configuração, tenha em mãos:

• Acesso administrativo ao servidor (RDP no VPS Windows ou SSH no Linux) e permissão para reiniciar GameServer, ConnectServer e o serviço do anti-cheat.
• Um ambiente de teste espelho — mesma season, mesmos arquivos de cliente e mesma versão de emulador do que roda em produção. Nunca teste anti-cheat direto no servidor público.
• Backup completo do cliente (Main.exe e pasta de dados) e dos arquivos de configuração do servidor (GameServerInfo.ini, CSConfig.ini ou equivalentes).
• O pacote do anti-cheat de terceiros com a documentação oficial: DLL/executável do módulo, chave de licença (se houver) e o guia de integração do fornecedor.
• Um canal de alerta já funcionando (log centralizado, webhook de Discord ou e-mail) para receber os eventos do anti-cheat.
• Conhecimento básico de edição hexadecimal ou de patch do Main.exe, já que muitas integrações exigem injetar a chamada de carregamento no cliente.

Se você ainda não tem a base do servidor montada, comece pelo guia de como criar servidor de MU Online e volte aqui depois que o ambiente estiver estável.

Como um anti-cheat de terceiros se encaixa na arquitetura

O MU Online é um jogo cliente-servidor com um cliente notoriamente frágil: o Main.exe roda na máquina do jogador, que tem controle total sobre memória, arquivos e tráfego. Um anti-cheat de terceiros trabalha justamente nesse território hostil, geralmente cumprindo quatro funções:

1. Integridade de arquivos — calcula hash dos arquivos críticos do cliente e detecta Main.exe modificado, DLLs injetadas ou data files adulterados.
2. Proteção de memória — monitora o processo do jogo contra leitura/escrita externa, injeção de DLL e hooks de API usados por trainers e speed hacks.
3. Detecção comportamental — observa padrões (velocidade impossível, teleporte, ataques fora de alcance) e sinaliza.
4. Vínculo com o servidor — envia um sinal periódico (o heartbeat) provando que o módulo está vivo e íntegro; sem esse sinal, o servidor derruba a sessão.

O ponto que quase todo administrador iniciante erra é achar que basta o cliente carregar o anti-cheat. Sem o vínculo do lado do servidor, o jogador simplesmente fecha o processo do anti-cheat e joga livre. A integração real é uma via de mão dupla: o cliente executa o módulo e o servidor exige a prova de que ele está rodando.

Camadas de proteção e onde o terceiro entra

O anti-cheat de terceiros brilha nas duas últimas linhas — proteção de memória e attestation — que são exatamente as mais difíceis de fazer só com o emulador. As primeiras camadas continuam sendo responsabilidade do servidor. Não desative nada nativo ao adicionar o terceiro; some, não substitua.

Etapa 1 — Preparar o ambiente de teste espelho

Nunca integre anti-cheat direto em produção. Monte um espelho:

1. Provisione uma VPS ou máquina separada com o mesmo Windows Server e a mesma season do servidor real.
2. Copie os binários do servidor e um snapshot recente do banco (pode ser reduzido, com poucas contas de teste).
3. Ajuste o ConnectServer do cliente de teste para apontar ao IP do espelho, não ao público.
4. Crie de três a cinco contas de teste: uma "limpa" (cliente íntegro), uma com Main.exe alterado, uma sem o módulo do anti-cheat e uma com um trainer conhecido, se você tiver um para testar detecção.

Esse espelho é onde todo ajuste de limiar acontece antes de chegar perto dos jogadores reais.

Etapa 2 — Carregar o módulo no cliente

O anti-cheat precisa iniciar junto com o jogo. Há três abordagens comuns, da mais limpa à mais invasiva:

• Pelo launcher: o updater/launcher inicia o processo do anti-cheat e só então sobe o Main.exe. É a abordagem preferida porque não toca no binário do jogo.
• Injeção pelo Main.exe: você aplica um patch no cliente para carregar a DLL do anti-cheat no startup. Exige backup e edição hexadecimal cuidadosa.
• Wrapper/bootstrap: um executável intermediário inicia o anti-cheat, valida e repassa a execução ao jogo.

Exemplo de configuração no lado do launcher (chaves ilustrativas, variam por season/emulador):

; launcher.ini
[AntiCheat]
Enabled=1
ModulePath=.\anticheat\acmod.exe
StartBeforeClient=1
LicenseKey=SUA-CHAVE-AQUI
FailIfMissing=1     ; não sobe o jogo se o módulo não iniciar

Se FailIfMissing estiver ligado, um cliente sem o módulo nem abre o jogo — o que é bom, mas exige que o updater realmente distribua o módulo a todos. Por isso o launcher e o anti-cheat andam juntos.

Etapa 3 — Configurar o serviço do anti-cheat no servidor

A maioria das soluções de terceiros roda um serviço/daemon do lado do servidor que recebe os relatórios dos clientes e expõe o veredito. Configure-o antes de ligar qualquer bloqueio:

; acserver.conf (exemplo — varia por fornecedor/season)
listen_port = 44405
heartbeat_interval = 15      ; segundos entre sinais do cliente
heartbeat_grace = 45         ; tolerância antes de considerar morto
mode = log_only              ; comece SEM kick/ban
report_endpoint = http://127.0.0.1:8080/ac/report
webhook_alert = https://discord.com/api/webhooks/...

Repare em mode = log_only. Este é o ponto mais importante do guia inteiro. Você começa apenas registrando, nunca punindo. Só depois de observar os dados reais é que sobe a severidade.

Etapa 4 — Amarrar o heartbeat ao GameServer

O heartbeat é o que impede o jogador de fechar o anti-cheat e seguir jogando. A lógica é:

1. O módulo no cliente envia um sinal assinado a cada N segundos ao serviço do anti-cheat.
2. O serviço marca a sessão como "viva" e íntegra.
3. O GameServer, a cada tick de manutenção, verifica se cada sessão logada tem heartbeat válido dentro da janela de tolerância.
4. Sessão sem heartbeat válido dentro da janela é derrubada (kick).

Se você tem a fonte do GameServer, amarre a checagem ao loop de manutenção de conexões. Se não tem, opere por consulta externa: um pequeno serviço lê o status do anti-cheat e emite kick via comando de GM/API para as contas sem sinal. Pseudocódigo da checagem:

para cada sessao ativa no GameServer:
    status = anticheat.consultar(sessao.account, sessao.ip)
    se status.ultimo_heartbeat > agora - heartbeat_grace:
        continua        # ok, módulo vivo
    senao:
        registra_alerta(sessao, "heartbeat ausente")
        se mode != log_only:
            kick(sessao, motivo="anti-cheat inativo")

Note de novo o se mode != log_only. Enquanto estiver em modo log, você só coleta — ninguém é derrubado por engano.

Etapa 5 — Whitelist e tratamento de exceções

Toda integração precisa de válvulas de escape para não punir quem não deve:

• Whitelist de contas: contas de GM, testers e o time de suporte não devem ser derrubadas por regras comportamentais durante manutenção.
• Whitelist de módulos/processos: overlays legítimos (gravadores, ferramentas de acessibilidade) podem disparar a proteção de memória. Documente e libere os conhecidos.
• Whitelist de hash de cliente: quando você lança um patch novo, o hash do Main.exe muda; atualize a lista de hashes válidos antes de publicar, ou todo mundo vira falso positivo.

Exemplo:

[Whitelist]
accounts = admin, gm_bruno, tester01
processes = obs64.exe, nvidia_share.exe
client_hashes = 9f2a...c1, a70b...44   ; hash do patch atual e do anterior

Manter o hash do patch anterior por alguns dias evita derrubar quem ainda não atualizou.

Etapa 6 — Subir a severidade de forma gradual

Com dados de log em mãos, promova a severidade em degraus, nunca de uma vez:

1. Dias 1–3: log_only. Colete alertas, identifique falsos positivos, ajuste whitelists e limiares.
2. Dias 4–6: kick. Passe a derrubar sessões que violam regras claras (sem heartbeat, hash inválido), mas ainda sem banir.
3. Dia 7+: ban seletivo. Só para violações de alta confiança (injeção de DLL detectada, trainer conhecido). Deixe o comportamental em kick por mais tempo, pois é onde nascem os falsos positivos.

A cada degrau, observe o volume de eventos. Um pico de kicks logo após subir a severidade quase sempre significa limiar mal calibrado, não uma horda de cheaters.

Etapa 7 — Alertas e observabilidade

Ligue os alertas desde o modo log:

• Webhook de Discord/e-mail para cada evento de alta severidade.
• Log centralizado com conta, IP, tipo de violação e timestamp para investigação posterior.
• Painel de contagem (mesmo que simples) mostrando eventos por hora — picos anômalos ajudam a distinguir ataque real de bug de configuração.

Cruzar os eventos do anti-cheat com os logs nativos do GameServer é o que transforma alerta solto em caso investigável.

Erros comuns e soluções

Checklist de lançamento

• Backup completo do cliente e das configs do servidor feito e testado
• Ambiente espelho montado com a mesma season/emulador
• Módulo carregando pelo launcher (ou patch aplicado com backup)
• Serviço do anti-cheat rodando em log_only
• Heartbeat amarrado ao GameServer e testado (fechar o módulo derruba a sessão no espelho)
• Whitelist de contas, processos e hashes preenchida
• Alertas (Discord/e-mail) recebendo eventos de teste
• Cenários de teste validados: cliente limpo, hash alterado, sem módulo, sem heartbeat
• Plano de rollback documentado (como voltar ao estado sem anti-cheat em minutos)
• Cronograma de subida de severidade definido (log → kick → ban)
• Camadas nativas do emulador confirmadas ativas (não foram desativadas)
• Aviso aos jogadores publicado sobre a nova proteção e possíveis instabilidades iniciais

Plano de rollback

Tenha o caminho de volta pronto antes de ligar qualquer bloqueio. Um rollback bem-feito é: colocar o serviço em log_only (ou desligá-lo), remover a exigência de heartbeat no GameServer, republicar o launcher sem FailIfMissing e restaurar o Main.exe do backup se você tiver aplicado patch. Documente cada passo com o comando exato para que, sob pressão de um sábado à noite lotado, você execute em minutos e não em pânico.

Integrar anti-cheat de terceiros é menos sobre a ferramenta e mais sobre disciplina de processo: espelho, modo log, whitelist, subida gradual e rollback pronto. Faça nessa ordem e a proteção entra em produção protegendo o servidor — não os cheaters da sua reputação.

Perguntas frequentes