Cómo detectar multicuentas y abuso de múltiples cuentas en tu servidor de MU Online

Una multicuenta bien gestionada es solo un jugador con dos cuentas casuales; una multicuenta abusada es un ejército de bots o cuentas fantasma monopolizando drops raros, cupos de eventos y rankings, y eso corroe la confianza de la comunidad más rápido que cualquier otro problema de gameplay. Detectar este abuso exige cruzar datos técnicos (IP, HWID, timing de conexión) con patrones de comportamiento en el juego (comercio, movimiento, participación en eventos). Este tutorial muestra cómo armar esta investigación desde cero, con consultas prácticas en la base de datos de cuentas y criterios objetivos para diferenciar coincidencia de fraude.

Por qué la multicuenta se convierte en un problema

El daño de la multicuenta abusiva aparece en tres frentes. En la economía, un solo jugador controlando 5 cuentas puede monopolizar jefes de drop raro, revenderse a sí mismo (self-trade) para lavar Zen, o inflar precios artificialmente reteniendo stock. En los eventos, las cuentas extra ocupan cupos limitados (Devil Square, Chaos Castle, Battle Soccer), quitando la oportunidad a jugadores reales y distorsionando el ranking de premiación. En la comunidad, cuando el abuso se hace público, los jugadores legítimos sienten que el esfuerzo no vale la pena y migran a otro servidor: la métrica que más duele a quien administra.

Señales técnicas de correlación entre cuentas

Tres fuentes de datos forman la base de cualquier investigación:

Ninguna señal aislada es prueba definitiva. La práctica correcta es sumar puntos: una cuenta que comparte IP y HWID y tiene un patrón de login sincronizado con otra tiene una correlación fuerte; una que solo comparte IP, correlación débil.

Recolectando IP y HWID en el login

La mayoría de los emuladores de MU (MuEMU, IGCN, X-Team) ya registran la IP de conexión en la tabla de cuentas o en un log de acceso, normalmente AccountCharacter, MEMB_STAT o una tabla de auditoría dedicada. El HWID suele requerir un agente en el cliente o launcher que envíe un hash del hardware en el handshake; si tu emulador no lo recolecta de forma nativa, vale la pena integrar un launcher de terceros con esa función antes de invertir tiempo en detección manual.

-- Ejemplo de tabla típica de acceso (los nombres varían según el emulador)
SELECT AccountID, LastIP, HWID, LastLoginDate
FROM MEMB_STAT
WHERE LastIP = '203.0.113.45';

Consulta de correlación por IP

Para listar todas las cuentas que comparten IP en los últimos 30 días:

SELECT LastIP, COUNT(DISTINCT AccountID) AS Contas, GROUP_CONCAT(AccountID) AS Lista
FROM MEMB_STAT
WHERE LastLoginDate >= DATEADD(day, -30, GETDATE())
GROUP BY LastIP
HAVING COUNT(DISTINCT AccountID) >= 3
ORDER BY Contas DESC;

Este resultado es el punto de partida, no la conclusión. Las IPs con 3+ cuentas en ciudades grandes o redes móviles son comunes y generalmente legítimas; la señal se vuelve fuerte cuando el mismo grupo de cuentas aparece también en la consulta de HWID de abajo.

Consulta de correlación por HWID

SELECT HWID, COUNT(DISTINCT AccountID) AS Contas, GROUP_CONCAT(AccountID) AS Lista
FROM MEMB_STAT
WHERE HWID IS NOT NULL AND HWID <> ''
GROUP BY HWID
HAVING COUNT(DISTINCT AccountID) >= 2
ORDER BY Contas DESC;

Cruzar el resultado de esta consulta con la anterior (misma IP y mismo HWID) ya elimina la mayoría de los falsos positivos de red compartida y señala cuentas casi con certeza controladas por la misma persona.

Patrones de comportamiento que confirman el abuso

Después de la correlación técnica, valida con el comportamiento en el juego:

• Login sincronizado: múltiples cuentas entrando y saliendo en ventanas de pocos segundos, repetidamente, indica un solo operador alternando entre clientes o usando multi-cliente automatizado.
• Self-trade: transferencias de ítems o Zen entre las cuentas correlacionadas, sin contrapartida de mercado (precio muy por debajo o por encima de lo justo).
• Participación simultánea imposible: dos cuentas del mismo grupo en eventos con límite de personaje por cuenta/IP sucediendo al mismo tiempo, cuando el evento debería bloquearlo.
• Movimiento en espejo: personajes de cuentas distintas siguiendo la misma ruta de farmeo, en el mismo horario, día tras día, típico de un bot multi-cliente.

Herramientas y logs útiles del lado del servidor

Además de las tablas de cuenta, vale la pena auditar:

Las IPs de datacenter/VPN/proxy merecen atención redoblada: un jugador legítimo rara vez juega MU detrás de una VPS comercial, así que esta señal por sí sola ya levanta sospecha incluso sin múltiples cuentas.

Diferenciando cibercafé, familia y abuso real

Antes de sancionar, pregúntate: ¿las cuentas juegan en horarios incompatibles con una sola persona (dos personajes activos simultáneamente en farmeo manual, que exige atención)? ¿Hay historial de pago/IP en ciudades distintas a lo largo del tiempo? ¿Existe un beneficio económico claro (ítems raros concentrados, Zen lavado)? Los familiares y cibercafés tienden a tener horarios de uso no superpuestos y ningún patrón de self-trade; el abusador de multicuentas casi siempre tiene ambas cosas.

Definiendo límites de cuenta por evento

La prevención es más barata que la investigación. Configura límites técnicos directo en el evento:

• Un personaje por IP en eventos de recompensa individual (Blood Castle, Devil Square).
• Cooldown de entrada vinculado al HWID, no solo a la cuenta, para eventos con premio raro.
• Límite de compra en la tienda de eventos por HWID/IP, evitando que una persona vacíe el stock con 5 cuentas.

Estos límites reducen drásticamente el volumen de investigación manual necesaria después.

Política de sanción escalonada

Una política clara evita acusaciones de arbitrariedad y protege al equipo de moderación:

Documenta cada caso con capturas de las consultas y logs; esto protege al equipo si el jugador impugna públicamente la sanción.

Comunicando la sanción sin generar desconfianza

Evita divulgar detalles técnicos exactos de cómo funciona la detección (eso le enseña al próximo abusador a escapar). Al anunciar una sanción masiva, usa un lenguaje genérico ("uso indebido de múltiples cuentas identificado mediante análisis de conexión y comportamiento") y, cuando sea posible, muestra números agregados (cuántas cuentas, qué evento) para reforzar la transparencia sin exponer el método.

Errores comunes y soluciones

Lista de verificación de investigación de multicuentas

• Consulta de correlación por IP ejecutada en los últimos 30 días.
• Consulta de correlación por HWID cruzada con la de IP.
• Logs de comercio/subasta revisados en busca de self-trade entre cuentas sospechosas.
• Logs de participación en eventos revisados para detectar simultaneidad imposible.
• Contexto de cibercafé/familia descartado antes de concluir abuso.
• Política de sanción escalonada documentada y aplicada de forma consistente.
• Límites técnicos por IP/HWID configurados en los eventos de mayor riesgo.

Después de estabilizar la detección de multicuentas, el siguiente paso natural es revisar la configuración general de anti-cheat y de los eventos del servidor para reducir la superficie de abuso desde la raíz; consulta el tutorial de creación de servidor de MU Online para revisar la base de configuración de tu entorno.

Preguntas frecuentes