Cómo configurar anti-speed hack en MU Online

El speed hack es una de las trampas más destructivas en servidores de MU Online porque ataca el corazón de la jugabilidad: la velocidad. Un jugador con speed hack ataca dos o tres veces más rápido de lo que debería, anda como si se teletransportara por el mapa y limpia spots de XP a un ritmo imposible para quien juega limpio. En PvP es prácticamente imbatible; en farmeo, rompe la economía. El agravante es que muchos administradores confían solo en la protección del lado del cliente — y esa protección es justamente la parte que el tramposo controla y modifica. La defensa que de verdad funciona vive en el servidor: medir el intervalo entre las acciones que el cliente envía y rechazar todo lo que venga por encima de lo físicamente posible. Esta guía muestra cómo configurar y calibrar esa protección. Todos los valores de velocidad, nombres de parámetro y rutas son ejemplos que varían por season/emulador — tú vas a medir tus propios límites.

Requisitos previos

• Acceso administrativo al directorio del GameServer (ej.: C:\MuServer\GameServer\).
• Conocimiento de qué emulador/season corre el servidor (IGCN, MuEMU, X-Files, etc.).
• Un personaje de prueba bien equipado por clase para medir velocidades reales.
• Acceso a los logs del GameServer para observar violaciones.
• SSMS conectado a la base de datos MuOnline, en caso de que quieras registrar violaciones y automatizar castigos.
• Copia de seguridad completa de los archivos de configuración antes de editar.
• Idealmente, un segundo administrador con ping alto para probar falsos positivos.

> Nunca actives el castigo automático de speed hack sin antes correr en modo de log. Los jugadores con ping alto, picos de latencia y reenvío de paquetes pueden disparar violaciones puntuales. Calibrar antes de castigar es lo que impide que la protección se convierta en un generador de quejas.

Cómo funciona el speed hack (y cómo funciona la defensa)

En MU Online, cada acción del jugador — un golpe, un paso, el uso de una habilidad — se envía del cliente al servidor como un paquete. Entre una acción y la siguiente existe un intervalo mínimo natural, determinado por la velocidad de ataque (attack speed) y de movimiento (move speed) de ese personaje. El speed hack acorta artificialmente ese intervalo, haciendo que el cliente dispare paquetes a una frecuencia más alta de la que el juego permite.

La defensa del lado del servidor es conceptualmente simple: para cada tipo de acción, el servidor registra el momento del último paquete y calcula el intervalo hasta el siguiente. Si el intervalo es menor que el mínimo permitido para esa clase y equipamiento, es una violación. Una violación aislada puede ser lag; violaciones repetidas en una ventana corta son trampa. La tabla siguiente resume los vectores comunes.

Paso 1 — Localizar los parámetros de velocidad en el GameServer

La mayoría de los emuladores expone los límites de velocidad en un archivo de configuración del GameServer, comúnmente en GameServer\Data\ o en un .ini en la raíz del GameServer. Los nombres varían bastante entre builds, pero el bloque suele parecerse a esto:

[SpeedHack]
Enable                = 1
AttackSpeedCheck      = 1
MoveSpeedCheck        = 1
Tolerance             = 15      ; margen porcentual para absorber lag
ViolationLimit        = 5       ; violaciones en la ventana antes de actuar
ViolationWindowSec    = 10      ; ventana de conteo (segundos)
Punishment            = 0       ; 0=log, 1=kick, 2=ban temporal
LogEnable             = 1
LogPath               = Logs\SpeedHack\

> Si tu build no tiene una sección dedicada, busca parámetros con nombres como CheckSpeedHack, AttackSpeedLimit, MoveSpeedLimit o MaxAttackSpeed repartidos por la configuración. La nomenclatura varía por season/emulador — consulta la documentación de tu compilado o el foro del emulador.

Empieza siempre con Punishment = 0 (solo log). Vas a activar el castigo solo después de la calibración.

Paso 2 — Medir las velocidades reales por clase

Aquí está el paso que la mayoría de los administradores se salta y que causa la mayor parte de los falsos positivos: necesitas los números reales de tu servidor. El attack speed y el move speed dependen de la clase, del nivel, del equipamiento y de la season. Copiar valores de otro servidor es receta para el desastre.

Para cada clase (DK, DW, Elf, MG, DL, etc.), haz lo siguiente:

1. Crea o usa un personaje de prueba de la clase, bien equipado, en el nivel típico de endgame.
2. Anota el attack speed mostrado (muchos builds lo muestran en la pantalla de estado o vía comando de GM).
3. Registra en el log, con el hack apagado, el intervalo mínimo real entre golpes durante un combate intenso.
4. Repite con equipamiento de attack speed máximo (ítems Excellent con opción de velocidad, buffs de swell/greater).
5. Anota el move speed en carrera continua por el mapa.

Arma una tabla de referencia por clase. Un ejemplo ilustrativo (los números varían por season/emulador y solo sirven de formato):

Guarda esa referencia. Es la base de todo lo que viene después.

Paso 3 — Definir el techo con margen de tolerancia

Con los números reales en mano, define el límite del servidor por encima del máximo legítimo, añadiendo un margen para absorber lag y picos de red. Si el intervalo mínimo real de golpe de una clase es X ms, el servidor debe rechazar solo intervalos bastante por debajo de X — nunca igual o justo por debajo, o pillarás al jugador legítimo en un pico de latencia.

El margen se aplica de dos formas, combinadas:

• Tolerancia porcentual (Tolerance): qué tan por debajo del mínimo ignora el servidor antes de contar como violación. Un margen inicial generoso evita falso positivo mientras calibras.
• Conteo de violaciones en ventana (ViolationLimit / ViolationWindowSec): en lugar de castigar en la primera anomalía, solo actúa cuando varias violaciones se acumulan en un período corto. Esto es lo que distingue el lag ocasional del hack sostenido.

[SpeedHack]
Enable             = 1
Tolerance          = 20     ; empieza generoso, aprieta tras calibrar
ViolationLimit     = 6      ; 6 violaciones...
ViolationWindowSec = 8      ; ...en 8 segundos = patron sostenido
Punishment         = 0      ; todavia en log

La lógica es clara: un speed hacker genera decenas de violaciones por segundo de forma continua. Un jugador con mal ping genera una o dos esporádicas. La ventana de conteo separa a los dos.

Paso 4 — Registrar violaciones en la base de datos para análisis

El log en archivo es útil, pero centralizar las violaciones en la base de datos facilita la calibración y la auditoría. Crea una tabla y, si el emulador ofrece hook, dirige las violaciones hacia ella; de lo contrario, impórtalas periódicamente del log.

USE MuOnline;
GO

CREATE TABLE dbo.SpeedHack_Log (
    LogID        INT IDENTITY(1,1) PRIMARY KEY,
    AccountID    VARCHAR(10)  NULL,
    CharName     VARCHAR(10)  NOT NULL,
    ViolationType VARCHAR(20) NOT NULL,   -- ATTACK, MOVE, SKILL
    MeasuredMs   INT          NULL,       -- intervalo medido
    AllowedMs    INT          NULL,       -- minimo permitido
    ViolCount    INT          NULL,       -- violaciones en la ventana
    ClientIP     VARCHAR(45)  NULL,
    DetectedAt   DATETIME     DEFAULT GETDATE()
);
GO

Después de algunos días en modo log, esta query revela quiénes son los sospechosos reales y ayuda a apretar los thresholds:

SELECT CharName, ViolationType,
       COUNT(*)          AS TotalViolacoes,
       AVG(MeasuredMs)   AS MediaIntervalo,
       MIN(MeasuredMs)   AS MenorIntervalo,
       MAX(ViolCount)    AS PicoNaJanela
FROM dbo.SpeedHack_Log
WHERE DetectedAt >= DATEADD(DAY, -3, GETDATE())
GROUP BY CharName, ViolationType
HAVING COUNT(*) > 50
ORDER BY TotalViolacoes DESC;

Las cuentas con centenas de violaciones e intervalos absurdamente bajos son hackers. Las cuentas con pocas violaciones e intervalos cercanos al límite son jugadores con mala red — no los castigues.

Paso 5 — Activar el castigo gradual

Después de la calibración (mínimo 48 a 72 horas en log), activa el castigo de forma escalonada. Empieza por kick, que es reversible y reeducativo, antes de partir hacia el ban.

[SpeedHack]
Enable             = 1
Tolerance          = 12     ; apretado tras calibrar
ViolationLimit     = 5
ViolationWindowSec = 8
Punishment         = 1      ; kick al violar
LogEnable          = 1

Observa por algunos días más. Si los kicks están pillando solo a hackers reales y no hay quejas de jugadores legítimos, puedes subir a ban temporal para reincidentes. La reacción a un ban de speed hack forma parte de la misma disciplina de moderación de cualquier castigo — registra el motivo y la evidencia siempre. Si todavía no tienes la base de moderación montada, vale la pena empezar por lo esencial en cómo crear un servidor de MU Online antes de endurecer el anti-cheat.

Paso 6 — Automatizar el ban de reincidentes

Para transformar violaciones graves y repetidas en ban temporal automático, programa un procedure que actúe sobre quien cruce un umbral alto de violaciones confirmadas:

USE MuOnline;
GO

CREATE PROCEDURE dbo.SP_SpeedHack_Enforce
AS
BEGIN
    SET NOCOUNT ON;

    -- Banear cuentas con patron sostenido de speed hack en las ultimas 2h
    UPDATE m
    SET m.bloc_code = 1
    FROM MEMB_INFO m
    INNER JOIN (
        SELECT AccountID
        FROM dbo.SpeedHack_Log
        WHERE DetectedAt >= DATEADD(HOUR, -2, GETDATE())
          AND MeasuredMs < AllowedMs * 0.5   -- mitad del minimo = inequivoco
        GROUP BY AccountID
        HAVING COUNT(*) > 200
    ) s ON m.memb___id = s.AccountID
    WHERE m.bloc_code = 0;

    PRINT 'SpeedHack enforce concluido: ' + CAST(GETDATE() AS VARCHAR);
END;
GO

El criterio MeasuredMs < AllowedMs * 0.5 es deliberadamente severo: solo banear automáticamente cuando la velocidad es claramente imposible (la mitad del intervalo mínimo). Los casos límite quedan para revisión humana. Prográmalo en el SQL Server Agent con intervalo de 30 minutos.

Paso 7 — Combinar con protección del lado del cliente

El anti-speed hack del servidor es la autoridad final, pero dificultar la trampa en el cliente reduce el volumen de intentos. Si tu build soporta GameGuard, HackShield o un módulo anti-cheat equivalente, mantenlo activo en paralelo. Intenta bloquear la inyección y la modificación de memoria que originan el speed hack, mientras la validación en el servidor garantiza que lo que pase aun así sea rechazado. Las dos capas juntas cubren tanto la prevención como la detección.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Sección de anti-speed hack localizada en el GameServer
• Velocidades reales medidas por clase con personaje de prueba
• Tabla de referencia de attack/move speed documentada
• Techo definido por encima del máximo legítimo, con margen
• Tolerancia y ventana de violación configuradas
• Punishment = 0 (log) activo por 48-72h de calibración
• Tabla SpeedHack_Log recibiendo violaciones
• Query de análisis revisada; thresholds apretados con base en los datos
• Prueba con cuenta de ping alto para descartar falso positivo
• Castigo escalonado: kick antes de ban
• SP_SpeedHack_Enforce con criterio severo y revisión de la cola
• Protección del lado del cliente (GameGuard/anti-cheat) activa en paralelo
• Copia de seguridad de los archivos de config hecha antes de editar

Un anti-speed hack bien hecho no se trata de encontrar el número mágico — se trata de medir, calibrar y escalar con cuidado. Al validar la velocidad en el servidor, medir los límites reales de tu build, absorber el lag con tolerancia y ventana, y solo endurecer el castigo después de ver los datos, eliminas a los tramposos que rompen el PvP y la economía sin convertir a cada jugador de ping alto en sospechoso. Es esa disciplina la que mantiene la competencia justa y el servidor confiable. </parameter>

Preguntas frecuentes