Dupe de dinero en RedM: cómo ocurre y cómo pillarlo antes de que tu economía se hunda

Un dupe de dinero en RedM casi nunca se anuncia. Nadie publica una captura, nadie es baneado por ello. Una noche un puñado de jugadores se hace rico, las tiendas se sienten baratas, y dos semanas después los recién llegados no pueden pagar un caballo porque todos los precios se han inflado en silencio para compensar. Cuando el staff se da cuenta, la economía que construiste ya es otra economía.

Este artículo trata de ese fallo lento: de dónde viene un exploit de dupe en RedM, qué aspecto tiene en tus datos, qué hacer el día que encuentras uno y qué puede y qué no puede hacer un anticheat al respecto. Mantenemos las causas deliberadamente generales. El objetivo es ayudarte a corregir y detectar problemas, no darle a nadie una receta.

#Un dupe de dinero en RedM suele ser un error de lógica, no una trampa

La palabra «dupe» cubre dos cosas muy distintas, y confundirlas te lleva a la solución equivocada.

• Un tramposo crea valor de la nada. Un menú de trampas lanza un evento de servidor oculto, o abusa de un evento que expone tu script, y se da dinero u objetos. Es un problema de anticheat.

• Un jugador legítimo encuentra un hueco en tu lógica. Sin software de trampas: solo una secuencia desafortunada de acciones normales que tus scripts gestionan mal. Es un problema de desarrollo, y ningún anticheat lo detendrá vigilando al jugador.

La mayoría de los incidentes reales son del segundo tipo, o una mezcla: un jugador descubre un hueco lógico, lo comparte y una docena más lo repite. Por eso un exploit de economía en RedM hay que tratarlo primero como un error de tu servidor y solo después como un problema de comportamiento.

#Las causas habituales de un dupe en VORP o en RSG

El framework importa menos de lo que podrías pensar. Un dupe en VORP y uno en un servidor RSG o RedEM suelen venir de la misma lista corta de errores en los scripts, sean tuyos o de un recurso de terceros.

El servidor se fía de lo que dice el cliente

Un evento de servidor es un mensaje que cualquiera puede enviar, y el cliente elige sus argumentos. Si tu manejador toma una cantidad, un precio o un número de objetos de los argumentos y lo aplica, el jugador decide el resultado. El servidor debe calcular la cantidad por sí mismo. El patrón completo, y por qué source es lo único en lo que puedes confiar, se explica en cómo proteger los eventos de servidor de RedM.

RegisterNetEvent('shop:sell', function(itemName)
  local src = source
  -- The client only names the item. Quantity, price and
  -- ownership are all decided here, from server state.
  local owned = GetOwnedCount(src, itemName)
  local price = GetServerPrice(itemName)
  if owned < 1 or not price then return end

  -- Take first, pay second, and only once.
  if RemoveItem(src, itemName, 1) then
    AddMoney(src, price)
  end
end)

Escrituras de inventario y base de datos que compiten entre sí

Dar un objeto y guardar el personaje suelen ser pasos separados. Si dos acciones se solapan, por ejemplo dos peticiones atendidas casi a la vez, ambas pueden leer el mismo estado inicial y ambas pueden tener éxito. El resultado es valor creado solo por el momento en que ocurre. La cura es aburrida: comprueba y cambia el estado en un solo paso, y nunca dejes que un manejador pague antes de que la retirada se haya hecho de verdad.

El momento de la desconexión y la reconexión

Un jugador que se va mientras una transacción o un guardado está en curso puede acabar con el estado antiguo restaurado mientras el resultado de la acción sobrevive en otro sitio. Piensa en un intercambio, una venta o un movimiento de alijo interrumpidos en el peor momento. Todo script que mueva valor entre dos lugares debería definir qué pasa si el jugador se cae a medias.

Sincronización de alijos y contenedores

Los alijos, las alforjas, los carromatos y el almacenamiento compartido son el hogar más común de los dupes de objetos, porque varios jugadores y varios scripts pueden tocar el mismo contenedor. Una sincronización débil entre lo que muestra el cliente y lo que guarda el servidor es donde los objetos aparecen dos veces.

Las cuentas mula mueven el botín

Quien encuentra un hueco rara vez se queda con el botín en la cuenta que lo produjo. Viaja hacia un personaje limpio, a menudo creado para ello y vinculado al primero por la misma máquina o la misma red. Ese rodeo es también tu oportunidad: el origen es difícil de ver, pero el destino es un patrón. Explicamos cómo se pillan las cuentas vinculadas en el artículo sobre los baneos por HWID.

#Qué aspecto tiene un dupe de dinero en RedM desde la silla del dueño

No verás el evento. Verás su huella en los datos:

• La masa monetaria da un salto. El total de efectivo y banco de todos los personajes crece más deprisa de lo que explican tus horas de juego, o en un escalón que coincide con una sola noche.

• Un jugador nuevo es más rico que tus veteranos. El patrimonio normalmente sigue al tiempo jugado. Un personaje recién creado con una fortuna y poco tiempo conectado es la señal individual más clara.

• Los saldos se mueven mientras el dueño no está conectado. El dinero que cambia en una cuenta cuyo jugador estaba desconectado rara vez es inocente.

• Stacks imposibles. Una cantidad muy por encima de lo que permite el juego, o un contador negativo, es la huella clásica de un dupe de objetos o de un desbordamiento roto.

• Muchas cuentas alimentando a una. Varios personajes, a menudo vinculados, enviando valor al mismo receptor.

#El día que encuentras un exploit de dupe en RedM

El orden importa. Los equipos que corren a banear suelen no arreglar nada y a veces lo empeoran.

1. 1

   Tapa la fuga. Desactiva ya la función o el recurso sospechoso, aunque no estés seguro de que sea la causa. Una tienda cerrada una hora cuesta menos que otra noche de duplicación.

2. 2

   Haz una instantánea. Haz una copia de la base de datos antes de tocar nada, para poder comparar antes y después y deshacer tus propios errores.

3. 3

   Rastrea el origen. Encuentra la primera cuenta que ganó de forma anormal y sigue el valor hacia delante hasta los receptores. Cruza los tiempos con los registros de tus scripts para dar con el manejador.

4. 4

   Revierte con cuidado. Retira solo lo que sea demostrablemente ilegítimo, cuenta por cuenta, en vez de restaurar una copia global que borra el progreso de los jugadores honestos. Documenta lo que retiraste y por qué.

5. 5

   Arregla el manejador antes de desbanear o reabrir nada. Si el hueco sigue abierto, un jugador que vuelva lo usará otra vez. Luego decide las sanciones, con pruebas, para quienes se beneficiaron a sabiendas.

6. 6

   Informa a tu comunidad. Un mensaje breve y factual vence a los rumores, y una política clara hace que la siguiente persona se lo piense dos veces.

#Qué hace Baobab AC ante un exploit de economía en RedM

Baobab AC lo aborda desde dos lados: impedir que se inyecte valor y encontrar lo que se coló.

En la puerta: Anti Exploit de Trigger de Economía

Anti Exploit de Trigger de Economía impide que los tramposos inyecten comandos ocultos para darse dinero, oro u objetos valiosos de la nada. Apunta a la vía del menú de trampas. No sustituye a un manejador seguro: si uno de tus propios scripts paga por un número enviado por el cliente a través de una vía legítima, la lógica es tuya de corregir, y un detector que vigila al jugador no puede saber que el número era erróneo.

Anti Exploit Multicuenta cubre el paso de la mula. Detecta transferencias de dinero y de objetos entre cuentas alternativas vinculadas, correlacionando IP, HWID e identidad de Discord compartidos, y marca también la reentrada tras un baneo.

Después: Análisis económico

El Análisis económico es la auditoría de lo que la primera capa no pudo ver. Es una auditoría de solo lectura de la base de datos de tu juego, cruzada con el tiempo de juego que solo conoce el anticheat. Examina:

• la masa monetaria a lo largo del tiempo, para detectar un escalón que no coincide con tu actividad;

• los valores atípicos de patrimonio, es decir, un patrimonio desproporcionado respecto al tiempo jugado;

• las redes de mulas, donde varias cuentas alimentan a una;

• los dupes de objetos y los stacks imposibles, incluidos los contadores negativos.

El cruce con el tiempo de juego es lo que una herramienta de base de datos no puede hacer sola. Tu base de datos conoce un saldo. Solo el anticheat sabe si ese jugador siquiera estaba conectado cuando cambió, y cuánto ha jugado en total.

Se ejecuta de forma programada y también se puede lanzar a mano desde el panel.

Tu esquema, no una suposición sobre él

La auditoría tiene lectores para VORP, la familia QB (que cubre RSG y QBR) y RedEM. Los servidores rara vez usan esos esquemas intactos, así que hay además un asistente de mapeo para bases de datos personalizadas o modificadas: una moneda extra, una tabla de inventario renombrada, un banco guardado en su propia tabla, un inventario almacenado como JSON o un framework casero. Eliges tablas y columnas de listas leídas en tu base de datos real en vez de escribir nombres, y cada parte mapeada debe superar una prueba antes de poder guardarse. Si un mapeo deja de coincidir con la base de datos, la auditoría vuelve a la detección automática y explica por qué en su informe de cobertura.

Eso importa porque un mapeo erróneo falla en silencio: devuelve inventarios vacíos y saldos a cero, no un error. Si usas VORP en concreto, la guía del anticheat VORP cubre el resto de la configuración.

#Qué significa realmente solo lectura, y lo que no hace

Ser claros en esto te ahorra una sorpresa más tarde.

• Solo lee. La auditoría envía consultas SELECT sobre identificadores que ha comprobado contra tu esquema real. Nunca edita un saldo, retira un objeto ni toca una cuenta.

• Nunca sanciona. Cada resultado es una pista para que la revise una persona. Nada se banea, se expulsa ni se revierte automáticamente por un hallazgo de la auditoría.

• Pasa por tu servidor de juego. Las consultas viajan por el recurso de tu servidor y su conexión a la base de datos, una a una, así que una base de datos grande implica una auditoría más lenta. Está diseñada para ser suave, no instantánea.

• Encuentra síntomas, no causas. La auditoría te dice quién es anormal y cuándo. Encontrar el manejador que filtró sigue siendo tu trabajo, con tus propios registros.

• No es una capa de prevención. No puede detener un dupe mientras ocurre. Acorta el tiempo entre el primer abuso y el día en que te enteras.

• Se aplican los límites del plan. El Análisis económico está incluido en los planes Pro y Network, no en Starter. Mira los precios.

Una pista necesita a una persona que sepa distinguir un atraco de un dupe, y la misma disciplina vale para cualquier detección: mira cómo tratamos los falsos positivos en el resto del producto.

#Una lista breve para tu propio servidor

• Revisa cada evento de servidor que toque dinero, objetos o trabajos: el cliente nombra la acción, nunca la cantidad.

• Haz de «retirar y luego pagar» la regla en cada transacción.

• Decide qué pasa con un intercambio o una venta si un jugador se desconecta a medias.

• Mira tu masa monetaria total con regularidad, no solo tras una queja.

• Conserva copias de la base de datos cuya restauración hayas probado de verdad.

• Trata una cuenta nueva y rica como una pregunta que responder, no como una victoria que ignorar.

Una economía de RedM dura mientras los jugadores crean que es justa. Los dupes ocurrirán, porque los scripts tienen errores. Lo que controlas es cuánto tiempo pasa uno sin que nadie lo note. Si quieres el panorama más amplio de cómo encaja la detección, empieza por cómo funciona un anticheat RedM, y consulta qué hace cada función antes de elegir un plan.