Cómo auditar ítems sospechosos con SQL en MU Online

Auditar ítems sospechosos es el trabajo de investigación forense del administrador de MU Online. Mientras que el anti-dupe previene y la detección automática alerta, la auditoría manual es donde te sientas con la base de datos y preguntas, ítem por ítem: ¿esto es legítimo? Un jugador denunció que fulano apareció de la nada con cinco sets Excellent perfectos. Una alerta automática señaló un serial repetido. El mercado se desplomó de precio de la noche a la mañana. En todos esos casos, el siguiente paso es el mismo: abrir el SQL y reconstruir la historia de cada ítem sospechoso: de dónde vino, por dónde pasó, si es lo que dice ser. Este tutorial avanzado muestra cómo conducir esa investigación de forma metódica, convirtiendo la sospecha en evidencia.

El principio que guía toda auditoría forense de ítems es el de la coherencia: un ítem legítimo es internamente coherente y externamente rastreable. Internamente, sus opciones, nivel y atributos forman una combinación que el juego es capaz de generar. Externamente, tiene un origen registrado, un dueño, un historial de movimiento que tiene sentido en el tiempo. Un ítem forjado o duplicado quiebra la coherencia en algún punto: una opción que no existe en ese slot, un serial que se repite, una cantidad que excede lo que ya se ha impreso, un surgimiento sin rastro. La auditoría es el arte de encontrar esas quiebras.

Requisitos previos

• Acceso de lectura a la base de datos del servidor (SQL Server, MySQL o el SGBD de tu emulador).
• Herramienta de consulta: SSMS, HeidiSQL, DBeaver o equivalente.
• Backup restaurado o réplica — audita sobre una copia, nunca en producción en hora pico.
• Conocimiento del esquema del emulador: dónde están el personaje, el inventario, el warehouse, y cómo están codificados los ítems (blob hexadecimal o tabla normalizada).
• Documentación del formato de ítem de tu emulador, si los ítems se almacenan como blob (para decodificar bytes en atributos).
• Idealmente, acceso a tablas de log (drops, trades, comandos de GM) para cruzar con el estado actual.

> Aviso: todos los nombres de tabla y columna de abajo (Character, warehouse, T_ItemSerial, Serial, ItemOptions, T_DropLog) son ejemplos de la línea Season 6 y derivados. Los nombres y formatos varían por season y emulador. Confirma el mapeo antes de ejecutar cualquier consulta, especialmente las que cruzan logs.

Si aún estás estructurando la base de datos del servidor, la guía de cómo crear un servidor de MU Online cubre la instalación del SGBD y la organización de las tablas antes de que llegues a la parte forense.

Los cuatro ejes de la sospecha

Una auditoría eficiente no mira ítem por ítem al azar; busca patrones en cuatro ejes. Cada eje responde a una pregunta diferente.

Una buena investigación recorre los cuatro ejes. Un ítem puede ser único y coherente, pero aparecer sin procedencia, y eso ya basta para investigar más a fondo.

Eje 1: unicidad — cazando seriales duplicados

Si tu emulador graba un serial por ítem, la duplicación es trivial de probar: dos ítems activos con el mismo serial son un dupe, punto final.

-- Seriales que aparecen en más de una copia activa
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, el siguiente paso es descubrir quién tiene las copias y cuándo surgieron:

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

El CreatedAt de las copias suele contar la historia: si dos copias nacen con pocos segundos de diferencia, estás ante un dupe en tiempo real, y el intervalo apunta a la operación explotada (un trade, un movimiento de baúl). Si el emulador no usa serial, este eje se apoya en el fingerprint: ítems raros con exactamente la misma firma de opciones en cuentas diferentes surgiendo en el mismo intervalo.

Eje 2: coherencia interna — ítems imposibles

No todo ítem sospechoso es duplicado; muchos son forjados o editados por un cliente hackeado o por un ex-GM abusivo. La marca de esos ítems es la incoherencia interna: una combinación de atributos que el juego es incapaz de generar. Un ítem con más opciones Excellent que el máximo permitido, una opción Ancient en un ítem que no pertenece a ningún conjunto Ancient, un nivel de refinamiento por encima del techo, una opción que solo existe en otra clase de ítem.

Si las opciones están en columnas normalizadas, la consulta es directa:

-- Ítems con más opciones Excellent que el máximo legítimo (ej.: 6)
SELECT CharID, Serial, ItemCode, ExcOptionCount
FROM ItemOptions
WHERE ExcOptionCount > 6;

Si las opciones están codificadas en un blob hexadecimal, necesitas decodificar. Cada emulador tiene su formato: los primeros bytes indican el código del ítem, los siguientes el nivel (+0 a +15), el byte de opciones Excellent, la flag Ancient, el serial. Con el mapa del formato en mano, escribe funciones que extraigan cada campo del blob y aplica las mismas reglas de coherencia. Lo importante es tener una tabla de referencia de lo que es posible: para cada ítem, cuántas opciones Excellent como máximo, qué opciones son válidas, cuál es el techo de refinamiento. Todo lo que se sale de esa tabla es sospechoso.

Eje 3: volumen — más ítems de los que el mundo generó

Este eje aplica el principio de conservación: la cantidad de un ítem que existe no puede ser mayor que la cantidad que ya se ha generado menos la que se destruyó. Si el boss X dropeó 40 unidades de la Joya rara desde el inicio del servidor, y la base de datos muestra 180 unidades activas, 140 vinieron de la nada.

-- Total de un ítem raro actualmente en circulación
SELECT ItemCode, COUNT(*) AS EmCirculacao
FROM T_ItemSerial
WHERE ItemCode = @itemRaro AND Active = 1
GROUP BY ItemCode;

-- Total ya dropeado según el log
SELECT ItemCode, COUNT(*) AS JaDropado
FROM T_DropLog
WHERE ItemCode = @itemRaro
GROUP BY ItemCode;

Cuando el "en circulación" supera el "ya dropeado" (sumado a crafts y eventos legítimos), tienes una inyección. El volumen no dice quién lo hizo, pero dice cuánto y sirve de termómetro general: ejecútalo periódicamente para todos los ítems raros y tendrás un mapa de dónde se corrompió la economía.

Eje 4: procedencia — ítems sin rastro

Todo ítem legítimo debería tener un origen registrado. Un ítem activo cuyo serial no aparece en ningún log de drop, craft, evento o comando de GM es un huérfano, y los huérfanos merecen investigación.

-- Ítems activos sin origen registrado en ningún 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 triple cruza el ítem con todas las fuentes legítimas de origen; lo que sobra sin correspondencia no vino de ningún lugar conocido. Cuidado con los falsos positivos aquí: los ítems muy antiguos, anteriores a la implementación de los logs, pueden aparecer sin rastro sin ser fraudulentos. Filtra por CreatedAt posterior a la fecha en que el logging entró en funcionamiento.

Montando el dossier de la investigación

Encontrar un ítem sospechoso es el comienzo, no el fin. Antes de cualquier acción, monta un dossier con toda la evidencia, porque castigar sin prueba documentada es como el problema vuelve a acecharte. Exporta a una tabla de custodia:

-- Snapshot de custodia antes de cualquier acción
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 (/* seriales confirmados */);

El dossier debe contener: el serial y los atributos completos del ítem, el dueño actual y el historial de dueños, los timestamps de creación y movimiento, y las cuentas relacionadas, porque los dupes raramente involucran una sola cuenta. Cruza el dueño del ítem con cuentas que comparten IP, hardware ID o patrón de login para mapear la red involucrada antes de actuar.

Paso a paso de la auditoría

1. Restaura un backup en un entorno aislado o apunta a una réplica de lectura.
2. Ejecuta el eje de unicidad: lista los seriales duplicados y ordénalos por número de copias.
3. Ejecuta el eje de volumen: compara la circulación con el total generado para cada ítem raro.
4. Ejecuta el eje de coherencia: busca ítems con atributos imposibles.
5. Ejecuta el eje de procedencia: lista los huérfanos sin origen registrado (filtrando por fecha).
6. Investiga cada sospechoso: reconstruye el historial de dueños y timestamps.
7. Mapea la red: cruza a los dueños con IP, HWID y patrones de login.
8. Monta el dossier de custodia exportando toda la evidencia antes de actuar.
9. Decide la acción (congelar, remover ítem, banear) con base en el dossier.
10. Documenta la decisión y archiva la evidencia.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Entorno de auditoría aislado (backup o réplica) preparado
• Esquema y formato de ítem del emulador mapeados
• Consulta de unicidad (seriales duplicados) validada
• Consulta de volumen (circulación vs. generado) validada
• Consulta de coherencia (atributos imposibles) validada
• Consulta de procedencia (huérfanos) validada con filtro de fecha
• Rutina de reconstrucción del historial de dueños definida
• Cruce de cuentas por IP/HWID/login preparado
• Tabla de custodia para el dossier creada
• Procedimiento de decisión y documentación escrito

La auditoría forense de ítems es lo que separa a un servidor que reacciona a rumores de un servidor que actúa sobre evidencias. Recorre los cuatro ejes con método, documenta antes de castigar y trata cada ítem sospechoso como un caso por probar, no como una condena anticipada. Así es como se mantiene la economía limpia y la confianza de la comunidad intacta.

Preguntas frecuentes