Como criar contas de GM/Admin com segurança no MU Online

Contas de GM e Admin são as chaves-mestras do seu servidor de MU Online. Uma única conta administrativa comprometida permite que um atacante crie itens perfeitos, injete zen infinito, apague personagens, altere rankings e destrua a economia em minutos — e muitas vezes o dono do servidor só percebe quando os jogadores começam a reclamar. Criar essas contas não é difícil; criá-las com segurança exige cuidado com senha, nível de acesso, isolamento, log e um plano de revogação. Este tutorial mostra o processo completo, do INSERT no banco à auditoria contínua, sempre lembrando que nomes de tabela, campos e valores de ctl_code são exemplos que variam por season/emulador.

Pré-requisitos

• Acesso ao banco de dados do servidor, via SQL Server Management Studio (SSMS) para emuladores baseados em MSSQL ou phpMyAdmin/HeidiSQL para os baseados em MySQL.
• Conhecimento do schema do seu emulador: saber se a tabela de contas é MEMB_INFO, accounts ou outra, e qual campo controla o nível (ctl_code, AccountLevel, etc.).
• Gerenciador de senhas para gerar e guardar senhas fortes e únicas.
• Ambiente de teste para validar a criação antes de mexer na produção.
• Acesso ao arquivo de configuração do GameServer, caso seu emulador use uma GMList além do ctl_code.
• Política mínima definida: quem terá acesso, com qual nível, e como o acesso será revogado. Se ainda está montando o servidor do zero, comece por como criar um servidor de MU Online.

Como o MU Online define uma conta administrativa

Na maioria dos emuladores, o nível de acesso de uma conta é um número guardado no banco. Em servidores baseados no schema clássico, a tabela é MEMB_INFO e o campo é ctl_code. O valor 0 é jogador comum; valores maiores liberam comandos e privilégios. A escala exata muda entre distribuições — em alguns, 1 já é Admin; em outros existe uma gradação (1 = GM, 8 = Admin). Alguns emuladores modernos ignoram o ctl_code e usam uma GMList no config do GameServer, onde você associa nick a nível numérico. Muitos usam os dois. Antes de criar qualquer conta, descubra qual modelo o seu servidor usa.

A tabela abaixo mostra uma escala típica de exemplo:

Passo 1 — Gerar uma senha forte e única

Antes do INSERT, gere a senha. Contas de GM são alvo de força bruta e engenharia social. Regras mínimas:

• No mínimo 16 caracteres, misturando maiúsculas, minúsculas, números e símbolos.
• Única — nunca reaproveitada de e-mail, Discord ou outra conta do servidor.
• Gerada por gerenciador de senhas, não inventada de cabeça.
• Guardada apenas no gerenciador, nunca em txt na área de trabalho ou no chat do Discord.

Lembre que o formato de armazenamento da senha varia por emulador: alguns guardam em texto puro (péssimo, mas comum em builds antigas), outros usam MD5, e os mais novos usam hash melhor. Se seu emulador tem coluna de senha em texto puro, trate o banco inteiro como sensível e restrinja o acesso ao SQL.

Passo 2 — Criar a conta no banco

Com a senha em mãos, crie a conta. Exemplo em MSSQL para schema clássico (varia por season/emulador):

USE MuOnline;

-- Criar conta administrativa nova
INSERT INTO MEMB_INFO
    (memb___id, memb__passwd, memb_name, sno__numb, bloc_code, ctl_code)
VALUES
    ('adm_bruno', 'S3nh4-F0rt3-Unica!2026', 'Bruno Admin',
     '000-000-000-0000', 0, 8);

-- Confirmar criação
SELECT memb___id, memb_name, ctl_code, bloc_code
FROM MEMB_INFO
WHERE memb___id = 'adm_bruno';

Pontos de atenção:

1. sno__numb precisa de um valor válido no formato que o emulador espera; alguns validam o tamanho da string.
2. bloc_code = 0 garante que a conta não nasce bloqueada.
3. ctl_code define o nível — use o mínimo necessário para a função da pessoa.
4. Se a senha é armazenada com hash, use a função do emulador ou o painel, não um texto puro que o servidor não vai reconhecer.

Para elevar uma conta existente em vez de criar nova:

-- Promover conta já existente a GM sênior
UPDATE MEMB_INFO
SET ctl_code = 2
WHERE memb___id = 'conta_do_moderador';

-- Auditar todas as contas com acesso administrativo
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

Passo 3 — Aplicar o nível mínimo necessário

O erro mais comum é dar Admin (ctl_code máximo) para todo mundo da equipe. Aplique o princípio do menor privilégio: cada pessoa recebe só o que precisa para o trabalho dela. Um moderador de chat não precisa criar itens; um organizador de eventos não precisa banir contas em massa. Quanto menos contas têm poder total, menor a superfície de ataque e mais fácil a auditoria. Mapeie funções para níveis antes de distribuir acesso, e documente esse mapa.

Passo 4 — Isolar a conta administrativa

Uma conta de Admin não deve se misturar com a vida normal do servidor:

• Nick e conta dedicados: não use a conta que você usa para jogar. Se sua conta de jogo vazar num phishing de Discord, o dano fica contido.
• Sem participação em economia real: contas de GM não devem comprar, vender ou tradar com jogadores. Isso evita suspeita de favorecimento e mantém os logs limpos.
• IP restrito quando possível: alguns emuladores e painéis permitem restringir login administrativo a IPs conhecidos. Combine com acesso remoto seguro ao servidor.
• E-mail de recuperação forte: a conta de e-mail ligada à conta administrativa também precisa de senha forte e verificação em duas etapas.

Passo 5 — Configurar a GMList (se o emulador usar)

Muitos emuladores modernos exigem que o nick esteja numa GMList no config do GameServer, além do ctl_code no banco. Formato de exemplo (ini):

[GMList]
; nick = nível de acesso (varia por emulador)
adm_bruno   = 8
gm_suporte  = 1
gm_eventos  = 2

[GMConfig]
LogGMCommands   = 1   ; registrar todos os comandos de GM
GMInvisible     = 1   ; permite GM ficar invisível
RestrictByIP    = 0   ; 1 = valida IP do GM

Se o nick estiver no banco com ctl_code alto mas fora da GMList (ou vice-versa), o acesso pode não funcionar como esperado. Mantenha os dois sincronizados.

Passo 6 — Habilitar log de todas as ações

Nenhuma conta administrativa deve agir sem deixar rastro. Configure o LogServer ou os logs do GameServer para registrar autor, ação, alvo e horário — especialmente para criação de item, entrega de zen/coin, banimento e alteração de personagem. Além do log do jogo, registre também quem acessou o SQL e quando. Um servidor sem log administrativo é impossível de auditar depois de um incidente.

Passo 7 — Testar o acesso

Depois de criar, valide antes de confiar:

1. Faça login com a conta nova num cliente de teste.
2. Execute um comando de baixo impacto compatível com o nível (por exemplo, /post num staging).
3. Confirme que o log registrou a ação.
4. Tente um comando acima do nível da conta e confirme que é negado.
5. Verifique no banco que o ctl_code continua o esperado.

Rotação e revogação de acesso

Acesso administrativo não é permanente. Sempre que alguém sai da equipe, ou você suspeita de vazamento:

-- Revogar acesso administrativo imediatamente
UPDATE MEMB_INFO
SET ctl_code = 0
WHERE memb___id = 'gm_que_saiu';

E, se usar GMList, remova o nick de lá também, e troque qualquer senha que tenha sido compartilhada. Faça uma revisão trimestral de todas as contas com ctl_code > 0 para eliminar acessos esquecidos — a query de auditoria do Passo 2 serve para isso.

Erros comuns e soluções

Boas práticas de segurança

• Uma conta administrativa por pessoa — nada de conta compartilhada pela equipe inteira.
• Senha única e forte por conta, guardada em gerenciador, com verificação em duas etapas no e-mail associado.
• Menor privilégio sempre: dê o nível mínimo que a função exige.
• Nunca use a conta de Admin para jogar ou tradar.
• Log obrigatório em toda ação geradora de valor.
• Auditoria periódica das contas com ctl_code > 0.
• Revogação imediata na saída de qualquer membro da staff.

Checklist de lançamento

• Modelo de acesso do emulador identificado (ctl_code, GMList ou ambos)
• Escala de níveis mapeada por função da equipe
• Senhas fortes e únicas geradas em gerenciador
• Contas administrativas separadas das contas de jogo
• ctl_code aplicado com menor privilégio possível
• GMList sincronizada com o banco (se aplicável)
• Log de comandos de GM habilitado e testado
• Acesso validado em teste, incluindo negação de comando acima do nível
• Verificação em duas etapas nos e-mails das contas administrativas
• Procedimento de revogação documentado e testado
• Auditoria periódica de contas com acesso agendada

Perguntas frequentes