Skip to content
Todos los artículos
This article is available in English
Publicado el6 min de lectura

Mod menus de RedM: cómo se cargan y cómo detectarlos sin saber su nombre

Qué hace de verdad un mod menu en un servidor RedM, las tres señales que lo delatan sin lista negra ni nombre conocido, y lo que ningún anticheat verá.

mod menuRedMdeteccióninyeccióndump

También disponible enEnglishFrançaisРусскийRomână

Un mod menu de RedM no se anuncia. No aparece en ninguna lista de recursos, no lanza ningún error al arrancar y el jugador que lo usa se comporta con normalidad durante tres cuartos de su sesión. Cuando por fin te das cuenta, suele ser porque otro jugador ha grabado algo imposible. Este artículo explica por dónde entra el menú, qué le da a quien lo paga y qué señales lo identifican, sin necesidad de saber cómo se llama.

Por dónde entra el menú

La primera etapa es un programa externo. Se lanza antes o durante el juego, abre el proceso y escribe su propio código en el espacio de memoria del juego. Desde ese instante el menú ya no es un software al lado del juego: está dentro, con los mismos derechos sobre el juego que el juego tiene sobre sí mismo. Puede llamar a funciones del motor, leer tu Lua de cliente una vez que ha llegado a la máquina y devolver el control sin que nada se haya detenido visiblemente. Los loaders serios están protegidos (binarios empaquetados, funciones del juego resueltas mediante sus símbolos de depuración) justamente para que este paso no deje ningún rastro legible.

La segunda etapa es la interesante para nosotros, porque toca tu servidor. Para ejecutar Lua con los derechos de un recurso (y así poder disparar tus eventos de red, llamar a tus exports, pasar por tu propio código), el menú secuestra un recurso que ya está en marcha. Mete sus propios valores en el espacio global de ese recurso y luego su código se despierta ahí dentro como si siempre hubiera pertenecido. Un caso real que observamos: el menú suelta cuatro variables (un id de usuario, un token, una clave) en la tabla global de un recurso legítimo, antes incluso de que arranque su propia capa de ofuscación. Esas cuatro variables son el pomo de su puerta, y también son su firma de comportamiento.

Hay una tercera vía, mucho más ruidosa: arrancar un recurso propio. Eso requiere acceso al servidor, no al cliente. Si un menú corre como un recurso declarado, tu problema no es un tramposo, es un miembro del staff.

Una vez dentro, esto es lo que obtiene el comprador:

  • Estado del personaje: invencibilidad, munición infinita, atravesar paredes, velocidad. Son llamadas a funciones del motor, gratis una vez estás dentro.

  • Spawn: peds, caballos, vehículos, objetos, en ráfagas. Es la molestia visible, la que tu comunidad te reclama.

  • Tus eventos de red: el menú lee tus scripts de cliente, extrae los nombres de los eventos de servidor y los repite con los argumentos que quiera. Es, con diferencia, lo más caro para ti (dinero, ítems, roles) y en los logs no parece una trampa, parece tu propia economía.

  • Dump: leer y exfiltrar tus recursos. El menú no solo intenta hacer trampa, intenta copiar tu servidor.

Por qué una lista negra de nombres no vale nada

La reacción natural es llevar una lista: nombres de menús conocidos, nombres de recursos sospechosos, nombres de eventos, hashes de archivos. Atrapa la primera versión, durante una semana. Luego el autor renombra cosas. Algunos menús anuncian explícitamente un botón de "cambiar el nombre", otros sortean un nombre aleatorio en cada arranque, y los valores soltados en el espacio global se generan al vuelo. Una lista negra no describe una capacidad, describe una ortografía, y la ortografía es lo más barato del mundo de cambiar.

Tres señales que no dependen del nombre

1. El llamante anónimo. En RedM toda llamada a una función del motor procede de un contexto. Cuando el código que llama pertenece a un recurso en marcha, el motor sabe cuál. Cuando es código inyectado, no hay ningún recurso al que nombrar: el llamante es desconocido. El principio cabe en una frase: lo sospechoso no es la función a la que se llama, es el hecho de que ningún recurso la reclame. Crear un caballo, activar la invencibilidad, volverse invisible: un servidor de rol hace las tres cosas todo el día, pero siempre desde un script identificable.

Esa señal sola ya haría daño, así que la templamos: exigimos observaciones separadas antes de que salga una alerta, ignoramos una ventana de tolerancia mientras el jugador está cargando (donde el propio motor llama sin contexto) y la pantalla negra de un viaje rápido desarma temporalmente la familia "estado". Los valores se quedan en casa: publicados, se convertirían en el margen en el que el menú se esconde.

No publicado/Los umbrales de detección nunca se publican: un valor conocido es un valor por debajo del cual se ajusta un cheat.

2. Escribir en el espacio global de otro recurso. Es el gesto de carga en sí. Un recurso no escribe en la tabla global de otro: no es así como hablan los recursos entre sí, y ningún framework de rol tiene motivo para hacerlo. Así que vigilamos esa escritura. De nuestro lado se la traga: el valor se acepta en apariencia y luego se devuelve corrompido conservando la misma forma, de modo que el loader cree haber tenido éxito y se desploma más adelante, y el token original sube al expediente. Ese token no es anónimo: es la cuenta que pagó el menú.

3. Lectura masiva de archivos de recursos. Un dump no se esconde muy bien: lee mucho, rápido, y lee cosas que ningún script abre en juego. Medimos la ráfaga más que el archivo, y plantamos archivos que no tienen motivo para ser leídos: un script legítimo los ignora, un dumper se los traga con el resto y se delata. El límite es claro y lo decimos: esta protección vive dentro del juego, así que ve los dumps que pasan por el juego. Una herramienta que copia tu caché desde el disco, fuera del proceso, no se topará nunca con ella. La única respuesta real a eso es contractual, no técnica.

Lo que esta familia de detección no ve

Todo lo anterior supone que el cheat habla con el motor. Un cheat totalmente externo no lo hace: lee la memoria del juego desde otro proceso, a veces desde una segunda máquina, no llama a ninguna función, no escribe en ningún estado de Lua y se limita a dibujar sobre tu pantalla o a mover tu ratón. Ninguna de nuestras tres señales salta, y ningún anticheat que corra dentro del juego puede afirmar lo contrario. Un ESP de solo lectura está en la misma situación: no cambia nada, así que no se contradice en ninguna parte.

Lo que queda entonces es el efecto: un disparo que sigue una trayectoria que ningún humano produce, una puntería que salta y se congela, conocimiento de posiciones que el jugador no debería tener. Ya no detectas el programa, detectas su rastro: es el tema de nuestro artículo sobre silent aim. Y como la pregunta siempre vuelve: sí, la decisión final debe tomarse en otro sitio que no sea la máquina del jugador, que es todo el debate cliente contra servidor.

Si quieres ver cómo es un expediente de carga de menú (el llamante desconocido, el token recuperado, la marca de tiempo), el panel de demostración está abierto sin registro, nuestro anticheat RedM muestra dónde encaja esta familia entre las demás, y los principios generales están expuestos en cómo funciona un anticheat RedM.

Seguir leyendo

Juzgue con pruebas, no con promesas

El panel de demostración está abierto en solo lectura con datos reales, sin registro.

Everything on one page: RedM anticheat, detections, evidence and panel.