Como configurar anti-speed hack no MU Online

O speed hack é uma das trapaças mais destrutivas em servidores de MU Online porque ataca o coração da jogabilidade: a velocidade. Um jogador com speed hack ataca duas ou três vezes mais rápido do que deveria, anda como se teleportasse pelo mapa e limpa spots de XP num ritmo impossível para quem joga limpo. Em PvP ele é praticamente imbatível; em farm, ele quebra a economia. O agravante é que muitos administradores confiam apenas na proteção do lado do cliente — e essa proteção é justamente a parte que o trapaceiro controla e modifica. A defesa que realmente funciona vive no servidor: medir o intervalo entre as ações que o cliente envia e recusar tudo que vier acima do fisicamente possível. Este guia mostra como configurar e calibrar essa proteção. Todos os valores de velocidade, nomes de parâmetro e caminhos são exemplos que variam por season/emulador — você vai medir os seus próprios limites.

Pré-requisitos

• Acesso administrativo ao diretório do GameServer (ex.: C:\MuServer\GameServer\).
• Conhecimento de qual emulador/season o servidor roda (IGCN, MuEMU, X-Files, etc.).
• Um personagem de teste bem equipado por classe para medir velocidades reais.
• Acesso aos logs do GameServer para observar violações.
• SSMS conectado ao banco MuOnline, caso queira registrar violações e automatizar punições.
• Backup completo dos arquivos de configuração antes de editar.
• Idealmente, um segundo administrador com ping alto para testar falsos positivos.

> Nunca ative punição automática de speed hack sem antes rodar em modo de log. Jogadores com ping alto, picos de latência e reentrega de pacotes podem disparar violações pontuais. Calibrar antes de punir é o que impede que a proteção vire um gerador de reclamações.

Como o speed hack funciona (e como a defesa funciona)

No MU Online, cada ação do jogador — um golpe, um passo, o uso de uma habilidade — é enviada do cliente ao servidor como um pacote. Entre uma ação e a próxima existe um intervalo mínimo natural, determinado pela velocidade de ataque (attack speed) e de movimento (move speed) daquele personagem. O speed hack encurta artificialmente esse intervalo, fazendo o cliente disparar pacotes numa frequência mais alta do que o jogo permite.

A defesa do lado do servidor é conceitualmente simples: para cada tipo de ação, o servidor registra o horário do último pacote e calcula o intervalo até o próximo. Se o intervalo for menor do que o mínimo permitido para aquela classe e equipamento, é uma violação. Uma violação isolada pode ser lag; violações repetidas em uma janela curta são trapaça. A tabela abaixo resume os vetores comuns.

Passo 1 — Localizar os parâmetros de velocidade no GameServer

A maioria dos emuladores expõe limites de velocidade em um arquivo de configuração do GameServer, comumente em GameServer\Data\ ou em um .ini na raiz do GameServer. Os nomes variam bastante entre builds, mas o bloco costuma parecer com isto:

[SpeedHack]
Enable                = 1
AttackSpeedCheck      = 1
MoveSpeedCheck        = 1
Tolerance             = 15      ; margem percentual para absorver lag
ViolationLimit        = 5       ; violacoes na janela antes de agir
ViolationWindowSec    = 10      ; janela de contagem (segundos)
Punishment            = 0       ; 0=log, 1=kick, 2=ban temporario
LogEnable             = 1
LogPath               = Logs\SpeedHack\

> Se o seu build não tiver uma seção dedicada, procure por parâmetros com nomes como CheckSpeedHack, AttackSpeedLimit, MoveSpeedLimit ou MaxAttackSpeed espalhados pela configuração. A nomenclatura varia por season/emulador — consulte a documentação do seu compilado ou o fórum do emulador.

Comece sempre com Punishment = 0 (apenas log). Você vai ativar punição só depois da calibração.

Passo 2 — Medir as velocidades reais por classe

Aqui está o passo que a maioria dos administradores pula e que causa a maior parte dos falsos positivos: você precisa dos números reais do seu servidor. Attack speed e move speed dependem da classe, do nível, do equipamento e da season. Copiar valores de outro servidor é receita para desastre.

Para cada classe (DK, DW, Elf, MG, DL, etc.), faça o seguinte:

1. Crie ou use um personagem de teste da classe, bem equipado, no nível típico de endgame.
2. Anote o attack speed exibido (muitos builds mostram na tela de status ou via comando de GM).
3. Registre no log, com o hack desligado, o intervalo mínimo real entre golpes durante um combate intenso.
4. Repita com equipamentos de attack speed máximo (itens de excellent com opção de velocidade, buffs de swell/greater).
5. Anote o move speed em corrida contínua no mapa.

Monte uma tabela de referência por classe. Um exemplo ilustrativo (os números variam por season/emulador e servem só de formato):

Guarde essa referência. É a base de tudo que vem depois.

Passo 3 — Definir o teto com margem de tolerância

Com os números reais em mãos, defina o limite do servidor acima do máximo legítimo, adicionando uma margem para absorver lag e picos de rede. Se o intervalo mínimo real de golpe de uma classe é X ms, o servidor deve recusar apenas intervalos bem abaixo de X — nunca igual ou logo abaixo, ou você pega o jogador legítimo em pico de latência.

A margem se aplica de duas formas, combinadas:

• Tolerância percentual (Tolerance): quão abaixo do mínimo o servidor ignora antes de contar como violação. Uma margem inicial generosa evita falso positivo enquanto você calibra.
• Contagem de violações em janela (ViolationLimit / ViolationWindowSec): em vez de punir na primeira anomalia, só age quando várias violações se acumulam num curto período. Isso é o que distingue o lag ocasional do hack sustentado.

[SpeedHack]
Enable             = 1
Tolerance          = 20     ; comece generoso, aperte apos calibrar
ViolationLimit     = 6      ; 6 violacoes...
ViolationWindowSec = 8      ; ...em 8 segundos = padrao sustentado
Punishment         = 0      ; ainda em log

A lógica é clara: um speed hacker gera dezenas de violações por segundo de forma contínua. Um jogador com ping ruim gera uma ou duas esporádicas. A janela de contagem separa os dois.

Passo 4 — Registrar violações no banco para análise

O log em arquivo é útil, mas centralizar as violações no banco facilita a calibração e a auditoria. Crie uma tabela e, se o emulador oferecer hook, direcione as violações para ela; caso contrário, importe periodicamente do log.

USE MuOnline;
GO

CREATE TABLE dbo.SpeedHack_Log (
    LogID        INT IDENTITY(1,1) PRIMARY KEY,
    AccountID    VARCHAR(10)  NULL,
    CharName     VARCHAR(10)  NOT NULL,
    ViolationType VARCHAR(20) NOT NULL,   -- ATTACK, MOVE, SKILL
    MeasuredMs   INT          NULL,       -- intervalo medido
    AllowedMs    INT          NULL,       -- minimo permitido
    ViolCount    INT          NULL,       -- violacoes na janela
    ClientIP     VARCHAR(45)  NULL,
    DetectedAt   DATETIME     DEFAULT GETDATE()
);
GO

Depois de alguns dias em modo log, esta query revela quem são os suspeitos reais e ajuda a apertar os thresholds:

SELECT CharName, ViolationType,
       COUNT(*)          AS TotalViolacoes,
       AVG(MeasuredMs)   AS MediaIntervalo,
       MIN(MeasuredMs)   AS MenorIntervalo,
       MAX(ViolCount)    AS PicoNaJanela
FROM dbo.SpeedHack_Log
WHERE DetectedAt >= DATEADD(DAY, -3, GETDATE())
GROUP BY CharName, ViolationType
HAVING COUNT(*) > 50
ORDER BY TotalViolacoes DESC;

Contas com centenas de violações e intervalos absurdamente baixos são hackers. Contas com poucas violações e intervalos próximos do limite são jogadores com rede ruim — não puna estes.

Passo 5 — Ativar a punição gradual

Depois da calibração (mínimo 48 a 72 horas em log), ative a punição de forma escalonada. Comece por kick, que é reversível e reeducativo, antes de partir para ban.

[SpeedHack]
Enable             = 1
Tolerance          = 12     ; apertado apos calibrar
ViolationLimit     = 5
ViolationWindowSec = 8
Punishment         = 1      ; kick ao violar
LogEnable          = 1

Observe por mais alguns dias. Se os kicks estão pegando só hackers reais e não há reclamação de jogadores legítimos, você pode subir para ban temporário para reincidentes. A reação a um ban de speed hack faz parte da mesma disciplina de moderação de qualquer punição — registre motivo e evidência sempre. Se ainda não tem a base de moderação montada, vale começar pelo essencial em como criar servidor de MU Online antes de endurecer o anti-cheat.

Passo 6 — Automatizar ban de reincidentes

Para transformar violações graves e repetidas em ban temporário automático, agende uma procedure que atua sobre quem cruza um limiar alto de violações confirmadas:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_SpeedHack_Enforce
AS
BEGIN
    SET NOCOUNT ON;

    -- Banir contas com padrao sustentado de speed hack nas ultimas 2h
    UPDATE m
    SET m.bloc_code = 1
    FROM MEMB_INFO m
    INNER JOIN (
        SELECT AccountID
        FROM dbo.SpeedHack_Log
        WHERE DetectedAt >= DATEADD(HOUR, -2, GETDATE())
          AND MeasuredMs < AllowedMs * 0.5   -- metade do minimo = inequivoco
        GROUP BY AccountID
        HAVING COUNT(*) > 200
    ) s ON m.memb___id = s.AccountID
    WHERE m.bloc_code = 0;

    PRINT 'SpeedHack enforce concluido: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

O critério MeasuredMs < AllowedMs * 0.5 é deliberadamente severo: só banir automático quando a velocidade é claramente impossível (metade do intervalo mínimo). Casos limítrofes ficam para revisão humana. Agende no SQL Server Agent com intervalo de 30 minutos.

Passo 7 — Combinar com proteção do lado do cliente

O anti-speed hack do servidor é a autoridade final, mas dificultar a trapaça no cliente reduz o volume de tentativas. Se o seu build suporta GameGuard, HackShield ou um módulo anti-cheat equivalente, mantenha-o ativo em paralelo. Ele tenta bloquear a injeção e a modificação de memória que originam o speed hack, enquanto a validação no servidor garante que o que passar mesmo assim seja recusado. As duas camadas juntas cobrem tanto a prevenção quanto a detecção.

Erros comuns e soluções

Checklist de lançamento

• Seção de anti-speed hack localizada no GameServer
• Velocidades reais medidas por classe com personagem de teste
• Tabela de referência de attack/move speed documentada
• Teto definido acima do máximo legítimo, com margem
• Tolerância e janela de violação configuradas
• Punishment = 0 (log) ativo por 48-72h de calibração
• Tabela SpeedHack_Log recebendo violações
• Query de análise revisada; thresholds apertados com base nos dados
• Teste com conta de ping alto para descartar falso positivo
• Punição escalonada: kick antes de ban
• SP_SpeedHack_Enforce com critério severo e revisão da fila
• Proteção do lado do cliente (GameGuard/anti-cheat) ativa em paralelo
• Backup dos arquivos de config feito antes de editar

Anti-speed hack bem-feito não é sobre encontrar o número mágico — é sobre medir, calibrar e escalar com cuidado. Ao validar a velocidade no servidor, medir os limites reais do seu build, absorver o lag com tolerância e janela, e só endurecer a punição depois de ver os dados, você elimina os trapaceiros que quebram o PvP e a economia sem transformar cada jogador de ping alto em suspeito. É essa disciplina que mantém a competição justa e o servidor confiável.

Perguntas frequentes