Como auditar itens suspeitos com SQL no MU Online

Auditar itens suspeitos é o trabalho de investigação forense do administrador de MU Online. Enquanto o anti-dupe previne e a detecção automática alerta, a auditoria manual é onde você senta com o banco de dados e pergunta, item por item: isto aqui é legítimo? Um jogador denunciou que fulano apareceu do nada com cinco sets Excellent perfeitos. Um alerta automático apontou um serial repetido. O mercado despencou de preço da noite para o dia. Em todos esses casos, o próximo passo é o mesmo: abrir o SQL e reconstruir a história de cada item suspeito — de onde veio, por onde passou, se é o que diz ser. Este tutorial avançado mostra como conduzir essa investigação de forma metódica, transformando suspeita em evidência.

O princípio que guia toda auditoria forense de itens é o da coerência: um item legítimo é internamente coerente e externamente rastreável. Internamente, suas opções, nível e atributos formam uma combinação que o jogo é capaz de gerar. Externamente, ele tem uma origem registrada, um dono, um histórico de movimentação que faz sentido no tempo. Um item forjado ou duplicado quebra a coerência em algum ponto: uma opção que não existe naquele slot, um serial que se repete, uma quantidade que excede o que já foi impresso, um surgimento sem rastro. A auditoria é a arte de encontrar essas quebras.

Pré-requisitos

• Acesso de leitura ao banco de dados do servidor (SQL Server, MySQL ou o SGBD do seu emulador).
• Ferramenta de consulta: SSMS, HeidiSQL, DBeaver ou equivalente.
• Backup restaurado ou réplica — audite sobre uma cópia, nunca em produção no horário de pico.
• Conhecimento do esquema do emulador: onde ficam personagem, inventário, warehouse, e como os itens são codificados (blob hexadecimal ou tabela normalizada).
• Documentação do formato de item do seu emulador, se os itens forem armazenados como blob (para decodificar bytes em atributos).
• Idealmente, acesso a tabelas de log (drops, trades, comandos de GM) para cruzar com o estado atual.

> Aviso: todos os nomes de tabela e coluna abaixo (Character, warehouse, T_ItemSerial, Serial, ItemOptions, T_DropLog) são exemplos da linha Season 6 e derivados. Nomes e formatos variam por season e emulador. Confirme o mapeamento antes de executar qualquer query, especialmente as que cruzam logs.

Se você ainda está estruturando o banco do servidor, o guia de como criar servidor de MU Online cobre a instalação do SGBD e a organização das tabelas antes de você chegar à parte forense.

Os quatro eixos da suspeita

Uma auditoria eficiente não olha item por item ao acaso; ela procura padrões em quatro eixos. Cada eixo responde a uma pergunta diferente.

Uma boa investigação percorre os quatro eixos. Um item pode ser único e coerente, mas aparecer sem procedência — e isso já basta para investigar mais fundo.

Eixo 1: unicidade — caçando seriais duplicados

Se o seu emulador grava serial por item, a duplicação é trivial de provar: dois itens ativos com o mesmo serial são um dupe, ponto final.

-- Seriais que aparecem em mais de uma cópia ativa
SELECT Serial, COUNT(*) AS Copias
FROM T_ItemSerial
WHERE Active = 1
GROUP BY Serial
HAVING COUNT(*) > 1
ORDER BY Copias DESC;

Para cada serial retornado, o próximo passo é descobrir quem tem as cópias e quando elas surgiram:

SELECT s.Serial, s.OwnerChar, s.OriginType, s.CreatedAt
FROM T_ItemSerial s
WHERE s.Serial = @serialSuspeito
ORDER BY s.CreatedAt;

O CreatedAt das cópias costuma contar a história: se duas cópias nascem com poucos segundos de diferença, você está diante de um dupe em tempo real, e o intervalo aponta a operação explorada (um trade, uma movimentação de baú). Se o emulador não usa serial, este eixo se apoia em fingerprint: itens raros com exatamente a mesma assinatura de opções em contas diferentes surgindo no mesmo intervalo.

Eixo 2: coerência interna — itens impossíveis

Nem todo item suspeito é duplicado; muitos são forjados ou editados por um cliente hackeado ou por um ex-GM abusivo. A marca desses itens é a incoerência interna: uma combinação de atributos que o jogo é incapaz de gerar. Um item com mais opções Excellent do que o máximo permitido, uma opção Ancient em um item que não pertence a nenhum conjunto Ancient, um nível de refinamento acima do teto, uma opção que só existe em outra classe de item.

Se as opções estão em colunas normalizadas, a query é direta:

-- Itens com mais opções Excellent do que o máximo legítimo (ex.: 6)
SELECT CharID, Serial, ItemCode, ExcOptionCount
FROM ItemOptions
WHERE ExcOptionCount > 6;

Se as opções estão codificadas em um blob hexadecimal, você precisa decodificar. Cada emulador tem seu formato — os primeiros bytes indicam o código do item, os seguintes o nível (+0 a +15), o byte de opções Excellent, a flag Ancient, o serial. Com o mapa do formato em mãos, escreva funções que extraem cada campo do blob e aplique as mesmas regras de coerência. O importante é ter uma tabela de referência do que é possível: para cada item, quantas opções Excellent no máximo, quais opções são válidas, qual o teto de refinamento. Tudo que foge dessa tabela é suspeito.

Eixo 3: volume — mais itens do que o mundo gerou

Este eixo aplica o princípio de conservação: a quantidade de um item que existe não pode ser maior do que a quantidade que já foi gerada menos a que foi destruída. Se o boss X dropou 40 unidades da Jóia rara desde o início do servidor, e o banco mostra 180 unidades ativas, 140 vieram de lugar nenhum.

-- Total de um item raro atualmente em circulação
SELECT ItemCode, COUNT(*) AS EmCirculacao
FROM T_ItemSerial
WHERE ItemCode = @itemRaro AND Active = 1
GROUP BY ItemCode;

-- Total já dropado segundo o log
SELECT ItemCode, COUNT(*) AS JaDropado
FROM T_DropLog
WHERE ItemCode = @itemRaro
GROUP BY ItemCode;

Quando o "em circulação" supera o "já dropado" (somado a crafts e eventos legítimos), você tem uma injeção. O volume não diz quem fez, mas diz quanto e serve de termômetro geral: rode-o periodicamente para todos os itens raros e você terá um mapa de onde a economia foi corrompida.

Eixo 4: procedência — itens sem rastro

Todo item legítimo deveria ter uma origem registrada. Um item ativo cujo serial não aparece em nenhum log de drop, craft, evento ou comando de GM é um órfão — e órfãos merecem investigação.

-- Itens ativos sem origem registrada em nenhum log
SELECT s.Serial, s.OwnerChar, s.ItemCode, s.CreatedAt
FROM T_ItemSerial s
LEFT JOIN T_DropLog d  ON s.Serial = d.Serial
LEFT JOIN T_CraftLog c ON s.Serial = c.Serial
LEFT JOIN T_GMItemLog g ON s.Serial = g.Serial
WHERE s.Active = 1
  AND d.Serial IS NULL
  AND c.Serial IS NULL
  AND g.Serial IS NULL;

Este LEFT JOIN triplo cruza o item com todas as fontes legítimas de origem; o que sobra sem correspondência não veio de lugar nenhum conhecido. Cuidado com falsos positivos aqui: itens muito antigos, anteriores à implementação dos logs, podem aparecer sem rastro sem serem fraudulentos. Filtre por CreatedAt posterior à data em que o logging entrou no ar.

Montando o dossiê da investigação

Encontrar um item suspeito é o começo, não o fim. Antes de qualquer ação, monte um dossiê com toda a evidência, porque punir sem prova documentada é como o problema volta a te assombrar. Exporte para uma tabela de custódia:

-- Snapshot de custódia antes de qualquer ação
SELECT s.Serial, s.OwnerChar, s.ItemCode, s.OriginType, s.CreatedAt,
       GETDATE() AS AuditadoEm, @motivo AS Motivo
INTO T_AuditCustodia_20260710
FROM T_ItemSerial s
WHERE s.Serial IN (/* seriais confirmados */);

O dossiê deve conter: o serial e os atributos completos do item, o dono atual e o histórico de donos, os timestamps de criação e movimentação, e as contas relacionadas — porque dupes raramente envolvem uma conta só. Cruze o dono do item com contas que compartilham IP, hardware ID ou padrão de login para mapear a rede envolvida antes de agir.

Passo a passo da auditoria

1. Restaure um backup em ambiente isolado ou aponte para uma réplica de leitura.
2. Rode o eixo de unicidade: liste seriais duplicados e ordene por número de cópias.
3. Rode o eixo de volume: compare circulação com o total gerado para cada item raro.
4. Rode o eixo de coerência: procure itens com atributos impossíveis.
5. Rode o eixo de procedência: liste órfãos sem origem registrada (filtrando por data).
6. Investigue cada suspeito: reconstrua o histórico de donos e timestamps.
7. Mapeie a rede: cruze donos com IP, HWID e padrões de login.
8. Monte o dossiê de custódia exportando toda a evidência antes de agir.
9. Decida a ação (congelar, remover item, banir) com base no dossiê.
10. Documente a decisão e arquive a evidência.

Erros comuns e soluções

Checklist de lançamento

• Ambiente de auditoria isolado (backup ou réplica) preparado
• Esquema e formato de item do emulador mapeados
• Query de unicidade (seriais duplicados) validada
• Query de volume (circulação vs. gerado) validada
• Query de coerência (atributos impossíveis) validada
• Query de procedência (órfãos) validada com filtro de data
• Rotina de reconstrução de histórico de donos definida
• Cruzamento de contas por IP/HWID/login preparado
• Tabela de custódia para dossiê criada
• Procedimento de decisão e documentação escrito

A auditoria forense de itens é o que separa um servidor que reage a boatos de um servidor que age sobre evidências. Percorra os quatro eixos com método, documente antes de punir e trate cada item suspeito como um caso a ser provado — não como uma condenação antecipada. É assim que se mantém a economia limpa e a confiança da comunidade intacta.

Perguntas frequentes