Anticheat FiveM et joueurs fictifs : guide de compatibilité

La compatibilité anticheat est la question la plus techniquement chargée que les opérateurs posent sur notre service de faux joueurs FiveM. Ce contenu fournit une explication détaillée de ce que signifie la compatibilité pour chaque système anticheat, quelles surfaces de détection chaque système utilise, et à quoi ressemblent, pour chaque scanner, les connexions de joueurs fictifs qui complètent la population de votre serveur.

Nous couvrons quatre systèmes anticheat que vous êtes susceptibles d'utiliser sur votre serveur FiveM : FiveGuard, Electron, Waveshield et Reaper. Pour chaque système, nous décrivons ce qu'il analyse au niveau de la connexion sur la base d'un comportement publicly observable, comment les connexions de joueurs fictifs apparaissent à chaque scanner, et quels ajustements de configuration empêchent les faux positifs. Nous serons explicites sur ce que nous avons testé et où nos connaissances s'arrêtent.

Cette documentation compte parce que les enjeux sont réels. Une session de joueurs fictifs mal configurée qui déclenche de faux bannissements de votre anticheat provoque des chutes visibles du nombre de joueurs dans le navigateur, crée du bruit dans vos journaux anticheat, et gaspille le budget que vous dépensez en joueurs fictifs. Une configuration correcte dès le départ évite tout cela.

Comment les connexions de joueurs fictifs diffèrent des connexions de joueurs réels

Avant de couvrir chaque système anticheat, il est utile de comprendre à quoi ressemble une connexion de joueur fictif au niveau réseau par rapport à une connexion de client de jeu réel. Comprendre cette distinction est la base pour comprendre pourquoi certaines surfaces de détection s'appliquent et d'autres non.

Un vrai client FiveM établit une connexion via le logiciel client de jeu FiveM fonctionnant sur la machine du joueur. Le client présente une licence CFX valide, télécharge et charge le manifeste des ressources du serveur, initialise l'état du jeu et génère des modèles de trafic associés au protocole réseau du jeu, notamment les mises à jour de mouvement, les paquets d'état d'entité et autres communications en session. Un vrai client a également une présence au niveau des processus sur la machine du joueur : un exécutable en cours d'exécution, des DLL chargées, des allocations mémoire actives.

Une connexion de joueur fictif est une connexion réseau légère qui satisfait le protocole de handshake de connexion du serveur sans faire fonctionner le client de jeu complet. La connexion maintient une présence dans la liste des joueurs du serveur, contribue au nombre de joueurs que l'API CFX rapporte, et apparaît dans le journal de connexion de txAdmin comme un joueur connecté. Il n'y a pas de processus de client de jeu en cours d'exécution sur une machine. Il n'y a pas de DLL chargées. Il n'y a pas d'état de jeu traité.

Cette distinction est directement pertinente pour la compatibilité anticheat. Les systèmes anticheat qui analysent les processus côté client, les DLL et la mémoire ne peuvent pas voir les joueurs fictifs au sens d'une analyse, car il n'y a pas de processus client à analyser. Les systèmes anticheat qui opèrent au niveau du handshake de connexion ou du modèle de trafic peuvent observer les connexions de joueurs fictifs et peuvent avoir une logique de détection qui s'applique. La question est de savoir si cette logique est ajustée pour signaler les modèles que produisent les connexions de joueurs fictifs.

FiveGuard : le système le plus répandu du marché

FiveGuard est le système anticheat le plus largement déployé dans l'écosystème des serveurs FiveM au mai 2026. C'est le système le plus souvent cité dans les questions des opérateurs sur la compatibilité des joueurs fictifs, en partie parce qu'il est si répandu et en partie parce que les opérateurs veulent confirmer que les connexions de joueurs fictifs apparaissent correctement dans le panneau opérateur FiveGuard.

FiveGuard opère sur des surfaces de détection côté client et côté serveur. Comprendre laquelle de ces surfaces s'applique aux connexions de joueurs fictifs est au cœur de la question de compatibilité.

Côté client, FiveGuard analyse les DLL modifiées, les processus injectés et les modèles de manipulation mémoire qui indiquent qu'un client de triche est en cours d'exécution. Les joueurs fictifs n'ont pas de processus côté client. Il n'y a rien à analyser pour le module client de FiveGuard du côté des joueurs fictifs car aucun client de jeu ne fonctionne sur une machine pour cette connexion. L'analyse côté client n'est simplement pas une surface pertinente pour l'analyse de compatibilité des joueurs fictifs.

Côté serveur et connexion, FiveGuard peut observer les métadonnées de connexion, les modèles de trafic et le comportement des joueurs pendant une session. C'est là que le travail de compatibilité est pertinent. Notre implémentation de joueurs fictifs produit des modèles de trafic cohérents avec un joueur connecté mais inactif plutôt que les modèles associés aux bots automatisés, aux outils d'inondation de connexions ou autres modèles de connexions adversariales que FiveGuard est conçu pour détecter.

• Analyse DLL côté client : non applicable, pas de processus client pour la connexion de joueur fictif
• Détection d'injection de processus : non applicable, pas de processus client sur aucune machine
• Vérifications des métadonnées de connexion : notre implémentation passe la validation standard du handshake
• Analyse des modèles de trafic : nos connexions produisent des modèles cohérents avec un joueur inactif
• Visibilité dans le panneau opérateur : les joueurs fictifs apparaissent dans la liste des joueurs FiveGuard comme prévu
• Détection comportementale pendant la session : aucun événement de mouvement ou d'action en jeu généré

Electron : identité matérielle et intégrité de session

Electron est un système anticheat FiveM avec un fort accent sur la vérification de l'identité matérielle et l'intégrité du client. Il est conçu pour associer les identités de session des joueurs aux empreintes matérielles, rendant la contournement de bannissement considérablement plus difficile pour les vrais tricheurs qui tentent de contourner les bannissements en créant de nouveaux comptes.

Pour la compatibilité des joueurs fictifs, la distinction côté client et côté serveur s'applique à nouveau. Le système d'empreinte matérielle d'Electron, l'application des bannissements HWID et la vérification de l'intégrité des processus clients opèrent tous sur la machine du client de jeu. Les joueurs fictifs n'ont pas de machine client au sens où l'assume l'analyse d'Electron. La surface d'empreinte matérielle ne s'applique pas.

Electron comprend également une surveillance des sessions côté serveur qui surveille les modèles de comportement de connexion qui semblent anormaux par rapport aux sessions de joueurs normales. C'est là que notre travail d'implémentation est important. Nos connexions de joueurs fictifs sont configurées pour produire un comportement au niveau de la session cohérent avec un joueur connecté mais inactif, et non les signatures comportementales associées aux modèles d'attaque que la détection d'anomalies d'Electron cible.

Une préoccupation de configuration spécifique avec Electron : certaines configurations de serveur incluent des règles de délai d'inactivité des joueurs qui bannissent les joueurs qui sont connectés sans générer d'événements de mouvement ou de gameplay pendant une période définie. Les joueurs fictifs ne génèrent pas d'événements de mouvement par défaut. Si votre configuration Electron a un délai d'inactivité strict, vous pourriez voir les joueurs fictifs être bannis après l'expiration de la fenêtre de délai plutôt que par la logique de détection.

Waveshield : analyse du trafic réseau et du taux de connexion

Waveshield opère principalement au niveau du réseau et du trafic. Il est conçu pour protéger les serveurs de jeu contre les attaques DDoS, les inondations de connexions et les anomalies de trafic. Contrairement à FiveGuard et Electron, la mission principale de Waveshield est la protection réseau plutôt que la détection de triche en session. Sa pertinence pour la compatibilité des joueurs fictifs découle de son analyse des modèles de connexion.

Parce que Waveshield analyse les modèles de connexion comme indicateur du trafic d'attaque, les connexions de joueurs fictifs doivent être indiscernables des connexions normales de joueurs au niveau du protocole réseau. Un ensemble de joueurs fictifs se connectant simultanément dans une courte fenêtre peut ressembler à une rafale de connexions ou à une tentative de soft-flood à la logique de limitation de débit de Waveshield, surtout si les connexions partagent des modèles d'adresses IP que Waveshield associe au trafic automatisé.

Nos tests confirment que les serveurs protégés par Waveshield peuvent utiliser des joueurs fictifs sans déclencher la détection d'inondation lorsque le taux de connexion est correctement géré. Le détail opérationnel clé est une montée en charge progressive des connexions plutôt que la connexion simultanée de tous les joueurs fictifs.

Notre infrastructure distribue les connexions de joueurs fictifs sur plusieurs adresses de sortie dans plusieurs régions. Cela empêche la source de connexion de ressembler à une rafale à source unique pour l'analyse des modèles de Waveshield. Une session de 30 joueurs se connectant progressivement depuis des adresses distribuées sur plusieurs minutes ressemble à 30 vrais joueurs rejoignant via la découverte normale du navigateur, ce qui est exactement ce qu'elle est censée simuler.

1. Démarrez les connexions de joueurs fictifs progressivement, pas toutes en même temps. Laissez les connexions s'étaler sur 5 à 10 minutes.
2. Laissez chaque groupe de connexions se stabiliser avant d'ajouter le groupe suivant.
3. Ne redémarrez pas la session de joueurs fictifs plusieurs fois à court intervalle durant la même fenêtre de fonctionnement.
4. Si Waveshield bannit des connexions, réduisez le taux de connexion par minute et retestez.
5. Vérifiez si votre configuration Waveshield inclut une limite de taux de connexion par IP ou par sous-réseau qui pourrait regrouper nos connexions malgré leur nature distribuée.
6. Contactez notre canal de support avec votre version Waveshield et les détails de configuration si les ajustements de base ne résolvent pas les bannissements.

Reaper : détection comportementale en session

Reaper adopte une approche de détection basée sur le comportement qui diffère significativement de l'analyse au niveau réseau de Waveshield et de l'accent sur l'identité matérielle d'Electron. Plutôt que de s'appuyer sur la correspondance de signatures ou l'analyse du taux de connexion, Reaper surveille le comportement des joueurs en session pour les modèles associés à la triche : mouvements dépassant les limites physiques, changements de position impossibles entre les tics, séquences d'actions scriptées qu'aucun humain ne pourrait exécuter, et empreintes comportementales similaires.

Les joueurs fictifs sont des connexions inactives sans comportement en jeu. Ils ne bougent pas. Ils ne tirent pas. Ils ne génèrent pas d'événements de collision ou n'interagissent pas avec les entités du monde du jeu. Cela les place entièrement hors du profil comportemental que la logique de détection de Reaper surveille. Un joueur fictif qui ne produit aucun événement comportemental en session ne produit pas les signatures qui déclenchent la détection de Reaper.

Nos tests sont cohérents avec le fonctionnement de l'anticheat basé sur le comportement dans ce contexte : les systèmes qui ciblent le comportement de triche actif en session ne signalent pas les joueurs connectés qui ne génèrent pas d'événements de gameplay. La surface de détection ne s'applique tout simplement pas au profil comportemental d'une connexion de joueur fictif.

Analyse native de txAdmin et visibilité dans le panneau opérateur

txAdmin lui-même comprend des outils de surveillance côté serveur et de gestion des joueurs. Les joueurs fictifs apparaissent dans la liste des joueurs connectés de txAdmin comme prévu. Ils s'affichent avec les noms que vous avez configurés, ils montrent la durée de connexion, et ils persistent dans la liste pendant toute la durée de la session. L'intégration native txAdmin signifie que les joueurs fictifs sont indiscernables des vrais joueurs dans le panneau de gestion des joueurs.

txAdmin n'a pas de mécanisme de détection dédié aux connexions de joueurs fictifs en tant que catégorie distincte des joueurs réels. Quand nous disons que notre service a une intégration native txAdmin, nous voulons dire que les connexions sont établies de manière à ce que le système de surveillance des joueurs de txAdmin les reconnaisse comme des sessions de joueurs valides plutôt que comme des connexions malformées ou des types de connexions inconnus.

Une note opérationnelle : les outils de bannissement et de bannissement de txAdmin opèrent sur les identifiants de joueurs que les connexions de joueurs fictifs présentent. Si un administrateur bannit accidentellement une connexion de joueur fictif via le panneau txAdmin, le comportement dépend de votre configuration de joueurs fictifs. La plupart des fournisseurs, y compris nous, reconnecteront automatiquement les joueurs fictifs bannis lors du prochain cycle de connexion. Si vous voyez des fluctuations dans le nombre de joueurs fictifs, vérifiez votre journal d'actions txAdmin pour des bannissements accidentels.

Étapes de configuration avant le déploiement avec un anticheat

Quel que soit l'anticheat que vous utilisez, les principes de configuration qui soutiennent la compatibilité sont cohérents dans tous les cas. Passer par ces étapes avant votre premier déploiement de joueurs fictifs avec une nouvelle version d'anticheat réduit la probabilité de bannissements inattendus et le temps de débogage qui s'ensuit.

1. Documentez le nom et la version de votre anticheat actuel avant de tester. La version compte quand vous devez signaler un problème de compatibilité.
2. Commencez avec le nombre minimum de joueurs, 15 joueurs, plutôt que votre nombre cible complet pour la session de test initiale.
3. Augmentez les connexions progressivement sur 5 à 10 minutes plutôt que de connecter tous les joueurs simultanément.
4. Surveillez votre panneau anticheat et votre journal de joueurs txAdmin pour les événements de bannissement dans les 30 premières minutes.
5. Vérifiez la liste des joueurs de txAdmin pour confirmer que les joueurs fictifs apparaissent comme des joueurs nommés et connectés.
6. Si des bannissements se produisent, notez le timing et la fréquence. Un timing constant suggère un délai d'inactivité. Un timing aléatoire suggère un problème de taux ou de modèle.
7. Si vous voyez un comportement inattendu avec une version spécifique d'anticheat, contactez notre canal de support avec le nom de l'anticheat, la version et le comportement spécifique que vous observez.

Ce que nous ne pouvons pas promettre sur la compatibilité anticheat

Nous ne prétendrons pas que notre implémentation de joueurs fictifs est définitivement compatible avec chaque version de chaque système anticheat de manière indéfinie. Les vendeurs d'anticheat mettent à jour leur logique de détection, changent leurs seuils comportementaux et ajoutent de nouvelles surfaces d'analyse sans notes de version publiques dans la plupart des cas. Une configuration qui passe FiveGuard version X sans incident peut se comporter différemment avec la version Y du même système si la version Y introduit une nouvelle heuristique de connexion inactive ou modifie sa base de référence des modèles de trafic.

L'attente correcte est une maintenance continue plutôt qu'une garantie statique. Nous surveillons l'écosystème anticheat, nous suivons les mises à jour de versions des principaux fournisseurs, et nous répondons aux rapports des opérateurs lorsque de nouveaux problèmes de compatibilité émergent. Quand une mise à jour anticheat modifie un comportement qui affecte notre implémentation, nous mettons à jour notre implémentation et documentons le changement.

Si vous mettez à jour votre anticheat vers une nouvelle version majeure et que vous remarquez ensuite que les connexions de joueurs fictifs sont abandonnées ou signalées, ne supposez pas que le service est définitivement cassé. Les mises à jour de versions majeures sont le déclencheur le plus commun pour les changements de compatibilité. Le processus de diagnostic standard consiste à vérifier le changelog de l'anticheat si disponible, à réduire le taux de connexion au minimum pour isoler s'il s'agit d'un problème de taux ou de détection, et à contacter notre canal de support avec les informations de version.

Prochaines étapes

Pour un examen plus approfondi de la façon dont fonctionne l'anti-détection au niveau de la connexion réseau, notamment les vecteurs de détection spécifiques que notre implémentation adresse et comment le fingerprinting de connexion fonctionne dans l'écosystème CFX, l'explicatif anti-détection couvre les fondements techniques plus en détail.