Como detectar multi-conta e abuso de múltiplas contas no seu servidor de MU Online

Multi-conta bem gerenciado é só um jogador com duas contas casuais; multi-conta abusado é um exército de bots ou contas-fantasma monopolizando drops raros, vagas de evento e rankings — e isso corrói a confiança da comunidade mais rápido que qualquer outro problema de gameplay. Detectar esse abuso exige cruzar dados técnicos (IP, HWID, timing de conexão) com padrões de comportamento em jogo (trade, movimentação, participação em eventos). Este tutorial mostra como montar essa investigação do zero, com queries práticas no banco de contas e critérios objetivos para diferenciar coincidência de fraude.

Por que multi-conta vira problema

O dano de multi-conta abusivo aparece em três frentes. Na economia, um único jogador controlando 5 contas pode monopolizar bosses de drop raro, revender para si mesmo (self-trade) para lavar Zen, ou inflar preços artificialmente segurando estoque. Nos eventos, contas extras ocupam vagas limitadas (Devil Square, Chaos Castle, Battle Soccer), tirando a chance de jogadores reais e distorcendo o ranking de premiação. Na comunidade, quando o abuso vira conhecido publicamente, jogadores legítimos sentem que o esforço não vale a pena e migram para outro servidor — a métrica que mais dói para quem administra.

Sinais técnicos de correlação entre contas

Três fontes de dado formam a base de qualquer investigação:

Nenhum sinal isolado é prova definitiva. A prática correta é somar pontos: uma conta que compartilha IP e HWID e tem padrão de login sincronizado com outra tem correlação forte; uma que só compartilha IP, correlação fraca.

Coletando IP e HWID no login

A maioria dos emuladores de MU (MuEMU, IGCN, X-Team) já grava o IP de conexão na tabela de contas ou em log de acesso — normalmente AccountCharacter, MEMB_STAT ou uma tabela de auditoria dedicada. HWID costuma exigir um agente no cliente ou launcher que envie um hash do hardware no handshake; se seu emulador não coleta isso nativamente, vale integrar um launcher de terceiros com esse recurso antes de investir tempo em detecção manual.

-- Exemplo de tabela típica de acesso (nomes variam por emulador)
SELECT AccountID, LastIP, HWID, LastLoginDate
FROM MEMB_STAT
WHERE LastIP = '203.0.113.45';

Query de correlação por IP

Para levantar todas as contas que compartilham IP nos últimos 30 dias:

SELECT LastIP, COUNT(DISTINCT AccountID) AS Contas, GROUP_CONCAT(AccountID) AS Lista
FROM MEMB_STAT
WHERE LastLoginDate >= DATEADD(day, -30, GETDATE())
GROUP BY LastIP
HAVING COUNT(DISTINCT AccountID) >= 3
ORDER BY Contas DESC;

Esse resultado é o ponto de partida, não a conclusão. IPs com 3+ contas em cidades grandes ou redes móveis são comuns e geralmente legítimos; o sinal fica forte quando o mesmo grupo de contas aparece também na query de HWID abaixo.

Query de correlação por HWID

SELECT HWID, COUNT(DISTINCT AccountID) AS Contas, GROUP_CONCAT(AccountID) AS Lista
FROM MEMB_STAT
WHERE HWID IS NOT NULL AND HWID <> ''
GROUP BY HWID
HAVING COUNT(DISTINCT AccountID) >= 2
ORDER BY Contas DESC;

Cruzar o resultado desta query com a anterior (mesmo IP e mesmo HWID) já elimina a maioria dos falsos positivos de rede compartilhada e aponta para contas quase certamente controladas pela mesma pessoa.

Padrões comportamentais que confirmam abuso

Depois da correlação técnica, valide com comportamento em jogo:

• Login sincronizado: múltiplas contas entrando e saindo em janelas de poucos segundos, repetidamente, indica um único operador alternando entre clientes ou usando multi-client automatizado.
• Self-trade: transferências de item ou Zen entre as contas correlacionadas, sem contrapartida de mercado (preço muito abaixo ou acima do justo).
• Participação simultânea impossível: duas contas do mesmo grupo em eventos com limite de personagem por conta/IP acontecendo ao mesmo tempo, quando o evento deveria bloquear isso.
• Movimentação em espelho: personagens de contas diferentes seguindo o mesmo trajeto de farm, no mesmo horário, dia após dia — típico de bot multi-client.

Ferramentas e logs úteis no lado servidor

Além das tabelas de conta, vale auditar:

IPs de datacenter/VPN/proxy merecem atenção redobrada: jogador legítimo raramente joga MU por trás de uma VPS comercial, então esse sinal sozinho já levanta suspeita mesmo sem múltiplas contas.

Diferenciando lan house, família e abuso real

Antes de punir, pergunte: as contas jogam em horários incompatíveis com uma única pessoa (dois personagens ativos simultaneamente em farm manual, exigindo atenção)? Há histórico de pagamento/IP em cidades diferentes ao longo do tempo? Existe benefício econômico claro (itens raros concentrados, Zen lavado)? Familiares e lan houses tendem a ter horários de uso não sobrepostos e nenhum padrão de self-trade; o abusador de multi-conta quase sempre tem as duas coisas.

Definindo limites de conta por evento

A prevenção é mais barata que a investigação. Configure limites técnicos direto no evento:

• Um personagem por IP em eventos de recompensa individual (Blood Castle, Devil Square).
• Cooldown de entrada vinculado ao HWID, não só à conta, para eventos com prêmio raro.
• Limite de compra na loja de eventos por HWID/IP, evitando que uma pessoa esvazie o estoque com 5 contas.

Esses limites reduzem drasticamente o volume de investigação manual necessária depois.

Política de punição escalonada

Uma política clara evita acusações de arbitrariedade e protege a equipe de moderação:

Documente cada caso com prints das queries e logs — isso protege a equipe se o jogador contestar publicamente a punição.

Comunicando a punição sem gerar desconfiança

Evite divulgar detalhes técnicos exatos de como a detecção funciona (isso ensina o próximo abusador a escapar). Ao anunciar uma punição em massa, use linguagem genérica ("uso indevido de múltiplas contas identificado por análise de conexão e comportamento") e, quando possível, mostre números agregados (quantas contas, qual evento) para reforçar transparência sem expor o método.

Erros comuns e soluções

Checklist de investigação de multi-conta

• Query de correlação por IP rodada nos últimos 30 dias.
• Query de correlação por HWID cruzada com a de IP.
• Logs de trade/leilão revisados para self-trade entre contas suspeitas.
• Logs de participação em evento checados para simultaneidade impossível.
• Contexto de lan house/família descartado antes de concluir abuso.
• Política de punição escalonada documentada e aplicada de forma consistente.
• Limites técnicos por IP/HWID configurados nos eventos de maior risco.

Depois de estabilizar a detecção de multi-conta, o próximo passo natural é revisar a configuração geral de anti-cheat e dos eventos do servidor para reduzir a superfície de abuso desde a raiz — veja o tutorial de criação de servidor de MU Online para revisar a base de configuração do seu ambiente.

Perguntas frequentes