Dupe d’argent RedM : comment il arrive et comment l’attraper avant que votre économie ne s’effondre

Un dupe d’argent RedM ne s’annonce presque jamais. Personne ne poste de capture d’écran, personne n’est banni pour cela. Un soir, une poignée de joueurs sont riches, les boutiques paraissent bon marché, et deux semaines plus tard les nouveaux arrivants n’ont pas de quoi s’offrir un cheval parce que chaque prix a été discrètement gonflé pour compenser. Quand le staff s’en rend compte, l’économie que vous aviez construite est déjà une autre économie.

Cet article parle de cette lente défaillance : d’où vient un exploit de dupe sur RedM, à quoi il ressemble dans vos données, quoi faire le jour où vous en trouvez un, et ce qu’un anticheat peut et ne peut pas y faire. Nous gardons les causes volontairement générales. Le but est de vous aider à corriger et à repérer les problèmes, pas de remettre une recette à qui que ce soit.

#Un dupe d’argent RedM est le plus souvent un bug de logique, pas un cheat

Le mot « dupe » recouvre deux choses très différentes, et les confondre vous envoie vers la mauvaise correction.

• Un tricheur crée de la valeur à partir de rien. Un menu de triche déclenche un événement serveur caché, ou abuse d’un événement que votre script expose, et se donne de l’argent ou des objets. C’est un problème d’anticheat.

• Un joueur légitime trouve une faille dans votre logique. Aucun logiciel de triche : juste une séquence malchanceuse d’actions ordinaires que vos scripts gèrent mal. C’est un problème de développement, et aucun anticheat ne l’arrêtera en surveillant le joueur.

La plupart des vrais incidents sont du second type, ou un mélange : un joueur découvre une faille de logique, la partage, et une douzaine d’autres la répètent. C’est pourquoi un exploit d’économie RedM doit être traité d’abord comme un bug de votre serveur, ensuite comme un problème de comportement.

#Les causes habituelles d’un dupe VORP ou RSG

Le framework compte moins qu’on ne le croit. Un dupe VORP et un dupe sur un serveur RSG ou RedEM viennent en général de la même courte liste d’erreurs dans les scripts, qu’ils soient les vôtres ou ceux d’une ressource tierce.

Le serveur croit ce que dit le client

Un événement serveur est un message que n’importe qui peut envoyer, et le client choisit ses arguments. Si votre gestionnaire prend un montant, un prix ou une quantité dans les arguments et l’applique, c’est le joueur qui décide du résultat. Le serveur doit calculer le montant lui-même. Le schéma complet, et pourquoi source est la seule chose à laquelle vous pouvez vous fier, est expliqué dans comment sécuriser les événements serveur RedM.

RegisterNetEvent('shop:sell', function(itemName)
  local src = source
  -- Le client ne fait que nommer l'objet. Quantité, prix et
  -- possession sont tous décidés ici, à partir de l'état du serveur.
  local owned = GetOwnedCount(src, itemName)
  local price = GetServerPrice(itemName)
  if owned < 1 or not price then return end

  -- Retirer d'abord, payer ensuite, et une seule fois.
  if RemoveItem(src, itemName, 1) then
    AddMoney(src, price)
  end
end)

Écritures d’inventaire et de base de données en course

Donner un objet et sauvegarder le personnage sont souvent des étapes séparées. Si deux actions se chevauchent, par exemple deux requêtes traitées presque simultanément, toutes deux peuvent lire le même état de départ et toutes deux réussir. Le résultat est de la valeur créée par le seul timing. Le remède est banal : vérifiez et modifiez l’état en une seule étape, et ne laissez jamais un gestionnaire payer avant que le retrait ait réellement eu lieu.

Timing de déconnexion et de reconnexion

Un joueur qui part pendant qu’une transaction ou une sauvegarde est en cours peut se retrouver avec l’ancien état restauré alors que le résultat de l’action survit ailleurs. Pensez à un échange, une vente ou un déplacement de coffre interrompu au mauvais moment. Chaque script qui déplace de la valeur entre deux endroits devrait définir ce qui se passe si le joueur tombe à mi-chemin.

Synchronisation des coffres et des conteneurs

Les coffres, sacoches, chariots et stockages partagés sont le foyer le plus courant des dupes d’objets, parce que plusieurs joueurs et plusieurs scripts peuvent toucher le même conteneur. Une synchronisation faible entre ce que le client affiche et ce que le serveur stocke est l’endroit où les objets apparaissent en double.

Les comptes mules déplacent le butin

Celui qui trouve une faille garde rarement le butin sur le compte qui l’a produit. Il voyage vers un personnage propre, souvent créé pour l’occasion et lié au premier par la même machine ou le même réseau. Ce détour est aussi votre opportunité : l’origine est difficile à voir, mais la destination est un schéma. Nous expliquons comment les comptes liés se font attraper dans l’article sur les bans HWID.

#À quoi ressemble un dupe d’argent RedM depuis le fauteuil du propriétaire

Vous ne verrez pas l’événement. Vous verrez son empreinte dans les données :

• La masse monétaire bondit. Le total d’espèces et de banque sur l’ensemble des personnages croît plus vite que vos heures de jeu ne l’expliquent, ou d’un coup qui correspond à une soirée.

• Un nouveau joueur est plus riche que vos vétérans. La richesse suit normalement le temps de jeu. Un personnage tout neuf avec une fortune et peu de temps en ligne est le signe isolé le plus net.

• Des soldes bougent alors que le propriétaire n’est pas connecté. De l’argent qui change sur un compte dont le joueur était hors ligne est rarement innocent.

• Des piles impossibles. Une quantité très supérieure à ce que le jeu autorise, ou un compte négatif, est l’empreinte classique d’un dupe d’objets ou d’un dépassement inférieur cassé.

• Beaucoup de comptes alimentent un seul. Plusieurs personnages, souvent liés, envoient tous de la valeur au même destinataire.

#Le jour où vous trouvez un exploit de dupe sur RedM

L’ordre compte. Les équipes qui se précipitent pour bannir ne réparent généralement rien et aggravent parfois les choses.

1. 1

   Bouchez la fuite. Désactivez dès maintenant la fonctionnalité ou la ressource suspecte, même si vous n’êtes pas sûr qu’elle soit la cause. Une boutique fermée une heure coûte moins qu’une nuit de duplication de plus.

2. 2

   Prenez un instantané. Sauvegardez la base de données avant de toucher à quoi que ce soit, pour pouvoir comparer avant et après et annuler vos propres erreurs.

3. 3

   Remontez à l’origine. Trouvez le premier compte qui a gagné de façon anormale, puis suivez la valeur vers les destinataires. Rapprochez le timing des journaux de vos scripts pour trouver le gestionnaire.

4. 4

   Revenez en arrière avec soin. Retirez uniquement ce qui est prouvablement illégitime, compte par compte, plutôt que de restaurer une sauvegarde globale qui efface la progression des joueurs honnêtes. Documentez ce que vous avez retiré et pourquoi.

5. 5

   Corrigez le gestionnaire avant de débannir ou de rouvrir quoi que ce soit. Si la faille est encore ouverte, un joueur qui revient s’en servira de nouveau. Décidez ensuite des sanctions, preuves à l’appui, pour ceux qui en ont sciemment profité.

6. 6

   Informez votre communauté. Un message court et factuel vaut mieux que des rumeurs, et une politique claire fera réfléchir le suivant.

#Ce que fait Baobab AC contre un exploit d’économie RedM

Baobab AC l’aborde sous deux angles : empêcher que de la valeur soit injectée, et retrouver ce qui est passé.

À la porte : Anti Economy Trigger Exploit

Anti Economy Trigger Exploit empêche les tricheurs d’injecter des commandes cachées pour se donner de l’argent, de l’or ou des objets de valeur à partir de rien. Il vise la voie du menu de triche. Il ne remplace pas un gestionnaire sûr : si l’un de vos propres scripts paie sur un nombre envoyé par le client par un chemin légitime, la logique est à vous de la corriger, et un détecteur qui surveille le joueur ne peut pas savoir que le nombre était faux.

Anti Multi-Account Exploit couvre l’étape de la mule. Il détecte les transferts d’argent et d’objets entre comptes alternatifs liés, en recoupant IP, HWID et identité Discord partagés, et signale aussi les retours après un ban.

Après coup : Economy Forensics

Economy Forensics est l’audit de ce que la première couche n’a pas pu voir. C’est un audit en lecture seule de la base de données de votre jeu, recoupé avec le temps de jeu que seul l’anticheat connaît. Il examine :

• la masse monétaire dans le temps, pour repérer un palier qui ne correspond pas à votre activité ;

• les fortunes atypiques, c’est-à-dire une richesse disproportionnée par rapport au temps joué ;

• les réseaux de mules, où plusieurs comptes en alimentent un seul ;

• les dupes d’objets et les piles impossibles, y compris les comptes négatifs.

Le recoupement avec le temps de jeu est la partie qu’un outil de base de données ne peut pas faire seul. Votre base connaît un solde. Seul l’anticheat sait si ce joueur était seulement connecté quand il a changé, et depuis combien de temps il joue au total.

Il s’exécute selon un planning et peut aussi être lancé à la main depuis le panel.

Votre schéma, pas une supposition

L’audit dispose de lecteurs pour VORP, la famille QB (qui couvre RSG et QBR) et RedEM. Les serveurs font rarement tourner ces schémas intacts, il existe donc aussi un assistant de correspondance pour les bases personnalisées ou modifiées : une monnaie en plus, une table d’inventaire renommée, une banque tenue dans sa propre table, un inventaire stocké en JSON, ou un framework maison. Vous choisissez les tables et colonnes dans des listes lues sur votre vraie base au lieu de taper des noms, et chaque partie associée doit passer un test avant de pouvoir être enregistrée. Si une correspondance cesse de coller à la base, l’audit retombe sur la détection automatique et en donne la raison dans son rapport de couverture.

Cela compte parce qu’une mauvaise correspondance échoue en silence : elle renvoie des inventaires vides et des soldes à zéro, pas une erreur. Si vous utilisez spécifiquement VORP, le guide de l’anticheat VORP couvre le reste de la configuration.

#Ce que « lecture seule » veut vraiment dire, et ce que cela ne fait pas

Être direct là-dessus vous évite une surprise plus tard.

• Il ne fait que lire. L’audit envoie des requêtes SELECT sur des identifiants qu’il a vérifiés par rapport à votre vrai schéma. Il ne modifie jamais un solde, ne retire jamais un objet et ne touche jamais un compte.

• Il ne sanctionne jamais. Chaque résultat est une piste à relire par un humain. Rien n’est banni, expulsé ni annulé automatiquement à cause d’un constat de l’audit.

• Il passe par votre serveur de jeu. Les requêtes transitent par la ressource de votre serveur et sa connexion à la base, une à la fois, donc une grosse base veut dire un audit plus lent. Il est conçu pour être doux, pas instantané.

• Il trouve des symptômes, pas des causes. L’audit vous dit qui est anormal et quand. Trouver le gestionnaire qui a fui reste votre travail, avec vos propres journaux.

• Ce n’est pas une couche de prévention. Il ne peut pas arrêter un dupe pendant qu’il se produit. Il raccourcit le délai entre le premier abus et le jour où vous l’apprenez.

• Les limites de l’offre s’appliquent. Economy Forensics est inclus dans les offres Pro et Network, pas dans Starter. Voir les tarifs.

Une piste a besoin d’une personne capable de distinguer un braquage d’un dupe, et la même discipline s’applique à toute détection : voyez comment nous traitons les faux positifs sur le reste du produit.

#Une courte checklist pour votre propre serveur

• Passez en revue chaque événement serveur qui touche à l’argent, aux objets ou aux métiers : le client nomme l’action, jamais le montant.

• Faites de « retirer, puis payer » la règle de chaque transaction.

• Décidez de ce qui arrive à un échange ou à une vente si un joueur se déconnecte à mi-chemin.

• Regardez régulièrement votre masse monétaire totale, pas seulement après une plainte.

• Gardez des sauvegardes de base de données dont vous avez réellement testé la restauration.

• Traitez un nouveau compte riche comme une question à élucider, pas comme une victoire à ignorer.

Une économie RedM dure aussi longtemps que les joueurs la croient équitable. Des dupes se produiront, parce que les scripts ont des bugs. Ce que vous contrôlez, c’est combien de temps l’un d’eux passe inaperçu. Si vous voulez le tableau d’ensemble de la façon dont la détection s’articule, commencez par comment fonctionne un anticheat RedM, et regardez ce que fait chaque fonctionnalité avant de choisir une offre.