Como investigar logs de trade e drop no MU Online

Quando um jogador abre um ticket dizendo que outro está "vendendo item dropado que não existe" ou quando de repente aparecem dez Excellent iguais no mercado do servidor, a resposta não está no seu palpite — está nos logs. Investigar logs de trade e drop no MU Online é um trabalho de detetive: você coleta registros de fontes diferentes, sincroniza os relógios, cruza o inventário do banco com os eventos gravados e monta uma linha do tempo defensável antes de punir qualquer conta. Este guia mostra o método completo, do que precisa estar ligado antes do incidente até como fechar o caso sem cometer injustiça. Os nomes de arquivos, tabelas e colunas citados são exemplos que variam por season/emulador; o método, porém, é o mesmo em qualquer versão.

Pré-requisitos

Para conduzir uma investigação séria você precisa de:

• Acesso administrativo ao servidor (RDP/SSH) e ao banco de dados (SQL Server, MySQL ou o SGBD do seu emulador) com permissão de leitura nas tabelas de itens, contas e trade.
• Logs de trade, drop e banco já ativos e retidos — isto é inegociável. Se estavam desligados durante o incidente, não há investigação possível.
• Relógios sincronizados entre GameServer, banco e sistema operacional (idealmente com NTP), para que os timestamps batam.
• Uma cópia de leitura dos logs para trabalhar sem risco de alterar os originais (a cadeia de custódia importa se o caso virar disputa pública).
• Conhecimento básico de SQL para consultar inventário e histórico de transações.
• Uma planilha ou ferramenta simples para montar a linha do tempo cruzando eventos.

Se o seu servidor ainda não tem os logs estruturados, resolva isso primeiro; depois volte para investigar. E se você ainda está montando o servidor do zero, comece por como criar servidor de MU Online.

Entenda as fontes de log antes de abrir qualquer arquivo

Uma investigação boa começa sabendo quais registros existem e o que cada um prova. No MU Online típico você lida com três grandes fontes:

• Log de drop (ItemLog / DropLog) — registra quando um item nasce no mundo: qual monstro/mapa gerou, qual jogador pegou, timestamp e, se o emulador suportar, o serial do item. É a "certidão de nascimento" do item.
• Log de trade (TradeLog) — registra transferências entre jogadores: quem deu, quem recebeu, quais itens, valor de zen envolvido e timestamp. É o "registro de transmissão de posse".
• Log/estado do banco (inventário e histórico) — o inventário atual de cada personagem, o baú (warehouse) e, dependendo do emulador, tabelas de auditoria. É a "fotografia do presente".

A regra mental: drop diz de onde o item veio, trade diz por onde ele passou, banco diz onde ele está agora. Fraude aparece quando essas três fontes se contradizem — um item que aparece no inventário sem certidão de drop, ou o mesmo serial em dois lugares ao mesmo tempo.

Mapa das fontes e do que cada uma prova

O log de conexão entra como fonte auxiliar valiosa: cruzar o IP de login com os horários de trade revela quando duas "contas diferentes" são operadas pela mesma pessoa.

Etapa 1 — Congele o cenário e preserve as evidências

Antes de consultar qualquer coisa:

1. Não avise o suspeito. Se ele perceber, some com os itens (trade em cadeia, warehouse, alt accounts).
2. Copie os logs relevantes do dia do incidente e dos dias vizinhos para uma pasta de trabalho separada. Trabalhe na cópia.
3. Tire um snapshot do banco ou ao menos exporte o inventário das contas envolvidas naquele instante. O item pode se mover enquanto você investiga.
4. Anote a origem do caso: quem reportou, o que alegou, prints. É o ponto de partida da linha do tempo.

Preservar antes de investigar evita que a própria investigação altere as evidências.

Etapa 2 — Sincronize os relógios e normalize os timestamps

O erro que arruína mais investigações é timestamp desalinhado. Se o GameServer grava em horário local e o banco em UTC, o mesmo evento aparece com três horas de diferença e você "prova" uma impossibilidade que não existe.

• Confirme o fuso de cada fonte (SO, GameServer, banco).
• Escolha um fuso de referência para a investigação e converta tudo para ele na planilha.
• Se possível, ligue NTP para os próximos casos — sincronia contínua evita o problema na origem.

Só depois de normalizar os horários é que a linha do tempo tem valor.

Etapa 3 — Reconstrua a linha do tempo do item

Aqui está o coração do método. Pegue o item ou serial em disputa e reconstrua sua história em ordem cronológica:

1. Nascimento: encontre o evento de drop. Qual monstro/mapa, quem pegou, quando.
2. Trânsito: liste todos os trades que envolvem aquele item/serial, em ordem.
3. Estado atual: confirme no banco onde o item está agora.

Uma cadeia legítima é contínua: nasce com o jogador A, é comercializado A→B, e agora está com B. Uma cadeia fraudulenta tem buraco ou bifurcação: o item aparece com B sem nunca ter sido dropado, ou o mesmo serial está com B e com C simultaneamente (duplicação clássica).

Consulta ilustrativa para achar itens com serial repetido no inventário (exemplo, varia por season/emulador):

-- Procura o mesmo serial de item em mais de um dono
SELECT ItemSerial, COUNT(*) AS ocorrencias
FROM CharacterItems
GROUP BY ItemSerial
HAVING COUNT(*) > 1
ORDER BY ocorrencias DESC;

Se o resultado traz seriais com ocorrencias > 1, você tem um forte indício de duplicação — o mesmo item existindo em dois lugares.

Etapa 4 — Leia o log de trade com olhos de investigador

Um trade suspeito raramente é um único evento gritante; é um padrão. Ao varrer o TradeLog, procure:

• Repetição anômala: a mesma conta recebendo itens caros de várias contas diferentes em poucos minutos (padrão de "mula" coletando de contas descartáveis).
• Trade unilateral: item valioso saindo por zero ou por um zen simbólico, repetidamente — típico de transferência para alt, não de venda real.
• Contas recém-criadas: doador ou receptor com conta de horas de vida participando de trades de item topo de linha.
• Rajada temporal: dezenas de trades no mesmo segundo/minuto, sugerindo automação.

Exemplo de consulta para trades de alto valor em janela curta:

-- Trades acima de um limiar em uma janela de tempo
SELECT FromAccount, ToAccount, ItemName, Zen, TradeTime
FROM TradeLog
WHERE TradeTime BETWEEN '2026-07-10 21:00' AND '2026-07-10 23:00'
  AND (Zen = 0 OR ItemGrade >= 3)      -- itens de alto grade ou trade sem zen
ORDER BY TradeTime;

Repare que nenhum desses padrões prova fraude sozinho. Uma conta secundária do próprio jogador gera trade unilateral legítimo. O padrão levanta a hipótese; o cruzamento a confirma.

Etapa 5 — Cruze com o log de drop e com o banco

Agora una as pontas. Para cada item suspeito da linha do tempo:

• Tem certidão de drop? Se o item apareceu num trade mas nunca consta no DropLog nem em nenhuma origem legítima (quest, evento, loja), é forte sinal de item injetado ou duplicado.
• A quantidade fecha? Se o DropLog registra que só um Excellent daquele tipo caiu no dia, mas há cinco idênticos circulando, quatro vieram de lugar nenhum.
• O IP bate? Cruze o log de conexão: se doador e receptor logam do mesmo IP nos mesmos horários, "duas contas" viram uma pessoa movendo itens entre alts — o que muda a leitura do caso.

Esse cruzamento de três fontes é o que separa uma acusação sólida de um chute. Nunca feche o caso com uma fonte só.

Etapa 6 — Distinga fraude de comportamento legítimo

Antes de qualquer punição, descarte ativamente as explicações inocentes:

• Doação real entre amigos ou membros de guild.
• Conta secundária do mesmo jogador (venda interna, não fraude).
• Venda combinada com pagamento por fora (o log mostra trade sem zen porque o zen foi em outra transação).
• Evento ou bug de sistema que gerou o item de forma legítima naquele período.

Se, depois de descartar todas essas, a cadeia continua com buraco ou o serial continua duplicado, aí sim você tem um caso. O ônus é seu de provar, não do jogador de se defender de um print solto.

Etapa 7 — Documente o caso e aja proporcionalmente

Feche a investigação com um dossiê:

1. Resumo: o que foi alegado e o que foi encontrado.
2. Linha do tempo: eventos em ordem, com fonte e timestamp normalizado de cada um.
3. Evidência-chave: o serial duplicado, o buraco na cadeia, o padrão de mula — com a consulta ou trecho de log que a sustenta.
4. Explicações descartadas: por que não é doação/alt/bug.
5. Ação: a punição proporcional (rollback do item, remoção do duplicado, suspensão ou ban), com a data.

Documentar protege você quando o jogador contestar publicamente e cria jurisprudência interna para casos futuros.

Erros comuns e soluções

Checklist de lançamento

• Logs de drop, trade e banco confirmados ativos e retidos
• Relógios de SO, GameServer e banco sincronizados (NTP idealmente)
• Rotina de cópia/preservação de logs definida para casos futuros
• Acesso de leitura ao banco e às tabelas de item/conta garantido
• Consultas-modelo (serial duplicado, trades de alto valor) prontas e testadas
• Procedimento de congelamento de cenário documentado (snapshot antes de apurar)
• Cruzamento com log de conexão/IP incorporado ao fluxo
• Modelo de dossiê de caso criado (resumo, linha do tempo, evidência, ação)
• Política de punição proporcional definida e comunicada à equipe
• Equipe de GM treinada a não acusar com fonte única

Investigar trade e drop não é caçar bruxas — é montar uma linha do tempo honesta a partir de fontes que se confirmam. Com os logs ligados antes do incidente, os relógios sincronizados e o cruzamento de drop, trade e banco, você troca o "eu acho" pelo "os registros mostram", e é isso que sustenta uma decisão justa diante da comunidade.

Perguntas frequentes