Como auditar a economia do seu servidor de MU Online com SQL

A economia de um servidor de MU Online é um organismo vivo: Zen entra pelo drop de monstros e sai por taxas e upgrades; itens raros são impressos por bosses e destruídos em falhas de refinamento. Quando esse fluxo está saudável, o servidor prospera. Quando um bug de duplicação (dupe), um exploit de drop ou uma conta comprometida injeta valor artificial, a economia inflaciona, os preços disparam e os jogadores honestos abandonam o servidor. Auditar a economia com SQL é a forma mais direta e confiável de enxergar o que está acontecendo por baixo do jogo — sem depender de denúncias ou de sorte. Este tutorial mostra, em nível avançado, como escrever queries para detectar itens duplicados, Zen inflacionado e contas anômalas, e como transformar isso em relatórios periódicos.

O princípio que guia toda auditoria econômica é o de conservação: em uma economia saudável, o que existe deve ser explicável pelo que foi gerado menos o que foi destruído. Quando um valor aparece sem origem — Zen que ninguém farmou, um item raro em quantidade maior do que já caiu — você tem um sintoma. As queries a seguir existem para encontrar esses valores inexplicáveis rapidamente.

Pré-requisitos

• Acesso de leitura ao banco de dados do servidor (SQL Server, MySQL ou o SGBD que seu emulador usa).
• Ferramenta de consulta: SQL Server Management Studio, HeidiSQL, DBeaver ou similar.
• Idealmente, uma réplica ou backup restaurado para rodar queries pesadas sem impactar produção.
• Conhecimento do esquema do seu emulador: nomes das tabelas de conta, personagem, inventário e warehouse.
• Permissão para criar objetos (views, tabelas de snapshot) se você quiser automatizar relatórios.

> Aviso: todos os nomes de tabela e coluna abaixo (AccountCharacter, Character, warehouse, Money, Serial) são exemplos da linha Season 6 e derivados. O esquema real varia por emulador. Sempre confira o mapeamento antes de executar qualquer comando, especialmente os que alteram dados.

Se ainda está montando a infraestrutura de banco do zero, o guia de como criar servidor de MU Online cobre a instalação base do SGBD antes de você chegar à parte de auditoria.

Regra de ouro: nunca audite com UPDATE ou DELETE

Auditoria é uma atividade de leitura. Toda query deste tutorial é SELECT. Você investiga, exporta evidências e só age depois — e mesmo a ação deve preferir congelar/isolar a apagar. Rodar DELETE ou UPDATE durante uma investigação destrói a própria trilha que você está tentando reconstruir. Se precisar corrigir algo, faça em uma etapa separada, documentada, e sempre com backup imediatamente anterior.

Passo 1: mapear o Zen em circulação

O primeiro indicador de saúde econômica é a distribuição de Zen. Comece medindo o total e a concentração. Se poucas contas detêm a maior parte do Zen do servidor, ou se o total cresce mais rápido que a base de jogadores, algo está errado.

-- Total de Zen no servidor (personagens + warehouse)
-- Nomes de coluna de exemplo: Money no personagem, Money no baú
SELECT
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character)  AS zen_personagens,
    (SELECT SUM(CAST(Money AS BIGINT)) FROM warehouse)  AS zen_baus;

Em seguida, veja quem concentra o Zen. Uma cauda longa e suave é normal; um degrau abrupto (uma conta com ordens de magnitude a mais que a segunda colocada) é suspeito.

-- Top 20 personagens por Zen
SELECT TOP 20
    Name,
    AccountID,
    Money AS zen,
    cLevel AS nivel,
    ResetCount AS resets
FROM Character
ORDER BY CAST(Money AS BIGINT) DESC;

> Interpretação: compare o topo com o esforço. Um personagem com Zen altíssimo, mas nível e resets baixos, não farmou aquilo — recebeu, comprou de dupe ou explorou um bug. O descompasso entre riqueza e progressão é um dos sinais mais confiáveis de anomalia.

Passo 2: detectar Zen inflacionado ao longo do tempo

Um número absoluto diz pouco sem histórico. A forma robusta de detectar inflação é comparar snapshots. Crie uma tabela de snapshot e alimente-a periodicamente (idealmente por um job agendado).

-- Tabela de histórico econômico (crie uma vez)
CREATE TABLE EconomySnapshot (
    snapshot_date   DATETIME       NOT NULL DEFAULT GETDATE(),
    total_zen       BIGINT         NOT NULL,
    total_contas    INT            NOT NULL,
    contas_ativas   INT            NOT NULL
);

-- Inserção periódica (rode via job diário)
INSERT INTO EconomySnapshot (total_zen, total_contas, contas_ativas)
SELECT
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character),
    (SELECT COUNT(*) FROM MEMB_INFO),
    (SELECT COUNT(*) FROM MEMB_INFO WHERE ConnectStat = 1);

Com snapshots acumulados, calcule a variação. O que importa não é o Zen total, e sim o Zen por conta ativa: se ele sobe consistentemente, há mais dinheiro perseguindo os mesmos itens — inflação.

-- Evolução do Zen por conta ativa (detecta inflação)
SELECT
    snapshot_date,
    total_zen,
    contas_ativas,
    total_zen / NULLIF(contas_ativas, 0) AS zen_por_conta_ativa
FROM EconomySnapshot
ORDER BY snapshot_date DESC;

Um salto abrupto de zen_por_conta_ativa entre dois dias consecutivos, sem que tenha havido um evento oficial de bônus, é o sinal clássico de um dupe de Zen ou exploit de drop. Priorize a investigação da janela de tempo em que o salto ocorreu.

Passo 3: detectar itens duplicados

A detecção de dupes depende de como o emulador armazena itens. Há dois cenários:

Cenário A — o emulador tem serial único por item. É o caso ideal. Um serial repetido em locais diferentes é prova direta de duplicação.

-- Itens com o mesmo serial aparecendo mais de uma vez (dupe direto)
-- Assume uma tabela normalizada de itens com coluna Serial
SELECT Serial, COUNT(*) AS ocorrencias
FROM ItemInstance
GROUP BY Serial
HAVING COUNT(*) > 1
ORDER BY ocorrencias DESC;

Cenário B — itens são blobs no inventário/baú (sem serial). É o caso mais comum em emuladores clássicos: o inventário é um campo binário/hexadecimal. Aqui você não detecta por serial, e sim por excesso de volume e padrões. A ideia é comparar quantos exemplares de um item raro existem contra quantos poderiam plausivelmente ter caído.

-- Contagem de um item raro específico no baú de todos os jogadores
-- Busca a assinatura hex do item dentro do blob do warehouse (exemplo)
SELECT COUNT(*) AS total_encontrado
FROM warehouse
WHERE Items LIKE '%<ASSINATURA_HEX_DO_ITEM>%';

Se uma asa de nível 3 que só cai de um boss semanal, dropada talvez 10 vezes na história do servidor, aparece em 60 baús, você tem duplicação — independentemente de haver serial. O volume não fecha com a emissão. Registre a assinatura hex de cada item raro num catálogo próprio para tornar essa checagem rápida e repetível.

Passo 4: caçar contas anômalas

Contas problemáticas costumam se destacar em pelo menos uma dimensão fora da curva. Cruze idade da conta, riqueza, tempo de jogo e progressão.

-- Contas novas com riqueza desproporcional (possível recebedor de dupe)
SELECT
    m.memb___id     AS conta,
    m.RegDate       AS criada_em,
    c.Name          AS personagem,
    c.Money         AS zen,
    c.ResetCount    AS resets
FROM MEMB_INFO m
JOIN AccountCharacter a ON a.Id = m.memb___id
JOIN Character c        ON c.AccountID = m.memb___id
WHERE m.RegDate > DATEADD(DAY, -7, GETDATE())   -- conta com menos de 7 dias
  AND CAST(c.Money AS BIGINT) > 1000000000       -- limiar de exemplo: 1 bilhão
ORDER BY CAST(c.Money AS BIGINT) DESC;

Outro padrão útil: várias contas com o mesmo IP ou criadas no mesmo intervalo curto, concentrando itens raros — típico de rede de dupe ou de contas-mula.

-- Múltiplas contas compartilhando o mesmo IP de registro (exemplo)
SELECT IP AS ip_registro, COUNT(*) AS qtde_contas
FROM MEMB_INFO
GROUP BY IP
HAVING COUNT(*) > 5
ORDER BY qtde_contas DESC;

> Cuidado com falsos positivos: LAN houses, famílias e NAT de operadora compartilham IP legitimamente. IP repetido é um indício, não uma condenação. Sempre corrobore com outro sinal (riqueza, itens raros, horários) antes de agir.

Tabela de indicadores e limiares

Use a tabela abaixo como painel mental. Os limiares são exemplos e devem ser calibrados ao porte do seu servidor.

Passo 5: transformar auditoria em relatório periódico

Auditar uma vez não protege ninguém; o valor está na repetição. Consolide as principais queries em uma view e agende a coleta de snapshots. Assim, cada dia gera uma linha de histórico que você pode comparar.

-- View de resumo econômico diário (leitura rápida)
CREATE VIEW vw_ResumoEconomico AS
SELECT
    CAST(GETDATE() AS DATE)                                   AS data_ref,
    (SELECT SUM(CAST(Money AS BIGINT)) FROM Character)        AS zen_total,
    (SELECT COUNT(*) FROM MEMB_INFO)                          AS contas,
    (SELECT MAX(CAST(Money AS BIGINT)) FROM Character)        AS maior_zen_individual;

Agende a inserção diária de snapshot via job do SGBD (SQL Server Agent, evento do MySQL ou tarefa externa — varia por emulador e SO). Com o histórico em mãos, um simples gráfico do zen_por_conta_ativa ao longo das semanas revela tendências que nenhuma inspeção pontual mostraria.

Erros comuns e soluções

Checklist de auditoria

• Backup ou réplica disponível para rodar queries pesadas com segurança
• Esquema real do emulador mapeado (tabelas de conta, personagem, baú)
• Todas as queries de investigação são somente leitura (SELECT)
• Snapshot de economia sendo coletado diariamente e armazenado
• Catálogo de assinaturas hex dos itens raros criado e atualizado
• Top de Zen e volume de raros revisados e comparados com a emissão esperada
• Contas anômalas identificadas e congeladas antes de qualquer punição
• Evidências (saldos, itens, logs, IPs) exportadas e documentadas
• Revisão manual profunda agendada semanalmente
• Auditoria extra planejada após eventos e atualizações grandes

Perguntas frequentes