Grim Anticheat — plugin anticheat para Minecraft
Grim Anticheat es un plugin anticheat de código abierto para Minecraft que previene ventajas injustas mediante simulación de movimiento en…
Grim Anticheat es un plugin anticheat de código abierto para Minecraft que previene ventajas injustas mediante simulación de movimiento en lugar de patrones.
Grim Anticheat — plugin anticheat para Minecraft
Java: 17 o más reciente
Versiones de Minecraft compatibles: 1.8 – 26.1.2
Versión del plugin: 2.3.74
Grim Anticheat (GrimAC) es un anticheat de servidor de código abierto para Minecraft bajo la licencia GPL-3.0. El plugin funciona simulando los movimientos del jugador en lugar de compararlos con patrones de comportamiento fijos, lo que lo distingue de la mayoría de alternativas gratuitas.
Su tarea principal es detectar modificaciones de cliente no permitidas que proporcionan ventajas injustas en combate, movimiento o interacciones con bloques. El plugin en sí no banea a los jugadores — registra la violación y pasa la ejecución del castigo a otro plugin (LiteBans, AdvancedBan o cualquier comando personalizado a través de la configuración).
Enfoque: predicción de movimiento en lugar de patrones
Los anticheats gratuitos clásicos se basan en patrones de comportamiento pregrabados. Este método tiene una limitación obvia — cada actualización de una modificación puede evadir la detección hasta que se añada un nuevo patrón a la base de datos.
GrimAC, por otro lado, incluye un Movement Simulation Engine. El servidor calcula exactamente dónde podría estar un jugador en un tick de juego específico, teniendo en cuenta los bloques circundantes, efectos de pociones, telarañas, columnas de burbujas, barcos, cerdos, lavagantes, élitros y docenas de otras situaciones. Si el cliente envía coordenadas que superan lo físicamente posible, se activa la comprobación Simulation y calcula el desplazamiento en bloques.
Además, el plugin mantiene una copia personal del mundo para cada jugador. Los chunks se comprimen a 16–64 KB utilizando paletas, lo que hace que la caché sea bastante ligera incluso con más de 200 jugadores en línea. Esta arquitectura procesa de forma segura bloques falsos colocados por otros plugins mediante paquetes.

Salida del comando /grim help en el chat
Comprobaciones
Las comprobaciones se dividen en grupos funcionales. Los nombres provienen del código fuente — los administradores los ven en /grim verbose y en mensajes de webhook. Los nombres en sí no son los nombres de las modificaciones prohibidas — es la clasificación interna del plugin.
Movimiento
Simulation — la comprobación principal. Detecta cualquier cambio en la posición del jugador que no corresponda a una trayectoria físicamente posible: aceleración no permitida, moverse sin soporte, moverse a través de bloques.
Timer, TimerLimit, NegativeTimer, VehicleTimer — detectan la aceleración del tiempo interno del cliente. Esta es la base de las modificaciones que aceleran el consumo de objetos y disparos con arco. El umbral de detección es de alrededor de 1.005× de la velocidad normal del tiempo — mucho más preciso que la mayoría de alternativas gratuitas.
NoFall — falsificación del estado de caída. La modificación envía un onGround=true falso para anular el daño por caída; la comprobación lo detecta.
Phase — moverse a través de un bloque sólido. El comportamiento básico de las modificaciones que permiten atravesar paredes o entrar en zonas protegidas.
Combate
Reach — atacar más allá de la distancia máxima permitida.
Hitboxes — atacar fuera de la hitbox real del objetivo.
Knockback, Explosion — el cliente ignora el impulso de los golpes o explosiones.
Aim, Interact — rotación incorrecta de la cabeza antes de un golpe, interacciones físicamente imposibles.
Paquetes y colocación de bloques
BadPackets, PacketOrder, Crash — orden incorrecto de los paquetes, intentos de bloquear el servidor con paquetes intencionalmente malformados.
NoSlow — el jugador no se ralentiza al comer, disparar un arco, usar un escudo o arrastrarse a través de telarañas.
Grupo de comprobaciones de colocación de bloques — detecta la colocación de un bloque cuando es físicamente imposible hacerlo: demasiado lejos, en una dirección inalcanzable, en el aire sin soporte.
Baritone — el patrón de movimiento de los bots asistentes automatizados.
Exploit — exploits individuales, como el abuso de Sprint-Jump con élitros.
Comandos principales de administrador
Comando | Propósito |
| Lista de comandos con descripciones cortas |
| Activar o desactivar las alertas en el chat |
| Mostrar cada flag sin búfer ni umbrales |
| Versión del cliente, marca (Vanilla/Fabric/Lunar/Forge), sensibilidad del ratón, estado de FastMath |
| Historial paginado de sesiones y violaciones de la base de datos |
| Entrar en modo espectador y teletransportarse a un jugador |
| Volver a la posición anterior |
| Descargar el registro de depuración para un ID de flag específico |
| Recargar todas las configuraciones, restablecer las violaciones activas |
| Modo desarrollador: predicción vs movimiento real con desplazamiento |
| Probar el webhook de Discord sin esperar a una violación real |

Salida del comando /grim profile en el chat — versión del cliente, marca, sensibilidad del ratón y estado de FastMath del jugador
Alertas y castigos
Cada comprobación tiene su propio contador de violaciones, que disminuye gradualmente con el tiempo. Esto es crucial: un pequeño lag o un fallo aleatorio no se acumula en un ban permanente, la reacción se activa solo en violaciones consistentes. La reacción en sí la define el administrador — para cada grupo de comprobaciones, se especifica en qué violación y con qué frecuencia ejecutar un comando.
La lógica es la siguiente: especifique el número de violación que activa la reacción, y el intervalo — con qué frecuencia se repetirá después. La entrada 100:0 kick %player% significa que el jugador será expulsado (kick) exactamente en la violación 100, y el comando no se ejecutará de nuevo. La entrada 5:3 [alert] se activará en la quinta violación, luego en la octava, undécima y así sucesivamente — la alerta se enviará al chat del juego para los jugadores con permiso.
El comando puede ser reemplazado por la etiqueta de servicio del propio Grim ([alert] — mensaje en el chat, [log] — registro en consola y base de datos, [webhook] — mensaje de Discord, [proxy] — pasar a otros servidores backend), o cualquier comando de consola del servidor. Entre los reemplazos están disponibles el apodo del jugador, el nombre de la comprobación y el número de violaciones, como marcadores de posición estándar. Gracias a esto, Grim se conecta a un plugin de baneos externo sin puentes adicionales.
Webhooks de Discord
GrimAC cuenta con una integración incorporada para enviar notificaciones a Discord. La apariencia del mensaje es completamente personalizable — desde el color del embed hasta los campos exactos que se van a mostrar. En un mensaje ya listo, se puede ver el apodo del jugador, el nombre de la comprobación, el número de violaciones, la versión y marca del cliente, el ping actual y los tps del servidor en el momento del evento. Se soportan tanto canales normales como canales de foros en Discord. Se recomienda encarecidamente verificar la configuración con antelación — el comando /grim testwebhook envía un mensaje de prueba sin tener que esperar a una violación real.
Mods de cliente incompatibles
La wiki oficial mantiene una lista separada de mods que rompen las mecánicas de la versión vanilla o bien provocan falsos positivos. Dicha lista no es exhaustiva y se va actualizando en la página "Known incompatible client mods" en la wiki de GitHub del plugin. Si un jugador llega a activar flags de manera masiva a pesar de tener un ping estable y sin otras señales de haber violado normas, la hipótesis primordial es el uso de un mod de cliente perteneciente a este listado.
Almacenamiento del historial de violaciones
GrimAC mantiene una base de datos del historial vinculada a las sesiones. Una sesión consiste en la conexión única de un jugador hacia el servidor. El comando /grim history <jugador> muestra: cuándo se unió el jugador, la duración de la sesión, la cantidad de violaciones que sucedieron, desde cuál cliente, desglosado por el tipo de comprobaciones.
Backends soportados: SQLite (por defecto, archivo local data/history.v1.db), MySQL, PostgreSQL, MongoDB, Redis. Con SQLite es suficiente si se tiene un solo servidor. En el caso de tener una red que incorpore múltiples instancias de Grim, se necesitará de un backend de red junto a una base de datos compartida — usualmente se usa MySQL o Postgres.
Por otro lado, se incluye una retención — eliminación automática para registros muy viejos. Por defecto, las sesiones viven hasta por 90 días, mientras que las violaciones durante 365 días. Todo esto se puede configurar o, de igual forma, desactivar.

Salida del comando /grim history en el chat
Configuración
Los ajustes se distribuyen a través de distintos archivos YAML ubicados en la carpeta plugins/Grim/
Los parámetros a los que más vale la pena ponerle atención durante una configuración inicial son:
Parámetro | Archivo | Qué hace |
| config.yml | Límite de desplazamiento de bloques desde el cual una comprobación Simulation ya es considerada como violación. Valores más bajos — mucha mayor severidad, por ende más falsos positivos debido a lag. |
| config.yml | Aumento de las áreas de colisión (hitbox) fuera del rango base en la versión vanilla. Un 0.0005 se encarga de detectar el superado al límite de los 3.0005 bloques. |
| config.yml | Un paquete adicional en el fin de la comprobación (tick) para una mejor detección de los alcances (Reach). Sumamente útil para los servidores PvP 1.8; por el contrario provocará tráfico de sobra sin motivo aparente en los demás ámbitos. |
| config.yml | Activa los diversos test de comprobación. Si no se necesita realmente es preferible dejarlos inactivos. |
| config.yml | Lapso de tiempo, medido por medio de segundos en inactividad, que debe pasar para aplicar automáticamente una expulsión (kick). |
| config.yml | Expulsar (Kick) aquellos clientes usando las versiones defectuosas de Forge 1.18.2–1.19.3. |
| config.yml | Transmitir de forma interna las alertas entre el listado de servidores backend vinculados a un proxy. Esta característica requiere indispensablemente el bungee-plugin-message-channel activado desde Velocity. |
| database.yml | Interruptor principal con control total frente al almacenamiento del historial de la base de datos. |
| database.yml | Ubicación exacta hacia la que van destinadas las faltas escritas del sistema: sqlite, mysql, postgres, mongo, redis, none. |
El resto de todos los demás parámetros establecidos por defecto dentro del documento config.yml (entre ellos el multiplicador de desgaste decay, los puntos máximos o techos y limitaciones respecto al ping sobre mecánicas clave, tal como puede referirse en un firework boost) gradúan finamente el margen que va más allá de la estricta vigilancia en su detección así como del confort otorgado a jugadores lidiando contra las adversidades vinculadas con la velocidad de un ping con mala estabilidad. De manera usual todo administrador elige abstenerse de modificar los estándares asignados originalmente por la propia autoría de creación detrás del plugin — al haberse medido mediante un punto medio equitativo que garantiza una óptima y muy atinada mezcla entre precisión a prueba de fallos tolerante en vista a escenarios de muy elevado ping.
Conclusión
Grim Anticheat registra todas las contravenciones de naturaleza general como por ejemplo los desplazamientos alterados, confrontamientos y filtración del procesador en materia de paquetes malintencionados. Este anticheat efectúa estos registros haciendo uso de simulacros basados en movimiento que suponen de la predicción misma y no recurre en su caso, a patrones convencionales para su análisis. Por consecuencia lógica gracias a esto a diferencia del mercado usual el actual mecanismo resalta dotado de resistencia apta a versiones novedosas desarrolladas hacia el uso continuo desde los mismos scripts hackeados por las modificaciones trampa con intenciones poco sanas. La sola principal falla se aprecia notoria en su indisponibilidad frente al heurístico tipo de comprobación hacia toda asistencia en forma de auto apuntados provenientes por manipulaciones de software vía mouses así como sus derivantes en temas referidos hacia todo autolimitante originario por el abuso indiscriminado sobre su ratio frecuencial dentro de los clicks empleados — adiciones muy prometidas a desarrollarse en el marco referencial hacia su rama orientada en el apartado de carácter Premium sin fechas en su calendario relativas a una divulgación anticipada y sin ser lanzada al plano real hasta los presentes días del ciclo contemporáneo. GrimAC funciona indudablemente a gusto por encima de todo ambiente para la gestión de todo modo de servidor a gran escala incitando severamente al rechazo del uso o propagación masiva sobre los medios desequilibrados originarios y derivados hacia todo modelo prohibido en cuanto a estas modificaciones se respecten — ideal hacia dominios tipo escenarios de confrontación entre jugadores mediante PvP, en conjunto con sistemas a nivel interno sobre mini-juegos interconectados por su propio apartado interno para cada una de las sub-unidades a un marco logístico referencial en línea por ende perfecto dentro el círculo destinado a toda sobrevivencia junto con dominios sobre anarquías y posesiones valoradas altamente con bienes primarios indispensables sobre este. Respecto de pequeños foros vinculados íntimamente bajo la creación constructiva del orden amistoso (grupos formados limitadamente para la sola interacción de 10 usuarios interconectados estrechamente entre ellos), el requerimiento general derivado para este sistema se perfila bastante desbalanceado ya que desbordará del objetivo trazado e inclusive ante los niveles bajos referenciales en relación a un mal funcionamiento del servidor consumirá todo medio valioso disponible con el que opere ese mismo ordenador principal.
Instalación
Una instalación típica lleva unos 5 minutos. El proceso es el mismo; solo cambian el loader y el build correspondiente.
- 1Stop your Minecraft server.
- 2Drop the plugin .jar into the server /plugins folder.
- 3Start the server once so the plugin generates its config files.
- 4Edit /plugins/<name>/config.yml as needed, then run /reload confirm or restart.











