Pourquoi une seule couche ne suffit pas
La plupart des anti-cheats FiveM reposent sur une seule couche de détection : soit une pile côté client qui guette les DLL injectées, les API hookées et les signatures de menus connus, soit une pile côté serveur qui valide les événements et rejette les transitions d'état de jeu impossibles. Chaque couche a un mode de défaillance connu. Un AC uniquement client échoue dès qu'un cheat cache son loader aux contrôles de signature. Un AC uniquement serveur échoue dès qu'un cheat respecte la surface d'événements légale mais utilise des hacks côté client (silent aim, ESP, wallhacks) qui ne déclenchent jamais d'événement serveur. La détection à deux couches fait que la couche qui voit le cheat l'attrape, et que celle qui ne le voit pas produit tout de même un signal comportemental que les admins peuvent examiner.
Ce que surveille la couche client
Côté client, Raven surveille les modules injectés, les fonctions moteur hookées, l'état des DevTools NUI, l'intégrité de ses propres fichiers de ressource et la présence à l'exécution de loaders de cheat connus. Les signatures des familles de mod menus les plus actives (Eulen, Redengine, HamMafia, Susano, TZ, TZX, Skript, Phaze, Lumia) sont maintenues à jour selon un rythme de livraison de 1 à 7 jours (voir /changelog). Quand une signature connue se déclenche, les preuves sont capturées (capture d'écran + trace de détection) et envoyées au panel cloud. Quand la signature ne se déclenche pas mais que des anomalies apparaissent, le score de confiance du joueur baisse et il remonte sur la carte en direct pour examen par un admin.
Ce que surveille la couche serveur
Côté serveur, Raven exécute une passe de validation sur chaque événement serveur déclenché par le joueur. Les noms d'événements qui ne devraient jamais venir d'un client sont bloqués d'office. Les charges utiles hors des bornes plausibles (quantités d'objets, variations d'argent, spawns de véhicules par minute) sont rejetées et journalisées. Les séquences d'événements qui correspondent à des schémas d'exploit connus, comme l'enchaînement utilisé par les variantes de Redengine, sont bloquées au niveau du schéma. La détection côté serveur tourne même si tous les contrôles client sont contournés : c'est pour cela que la couverture côté serveur n'est pas négociable.
Comment les deux couches coopèrent
Une boucle heartbeat relie les couches. Le client transmet régulièrement au serveur un hash signé de son état d'exécution critique. Si le heartbeat s'arrête, le serveur considère le client comme manipulé et applique la réponse configurée (avertissement, kick ou ban automatique). Si le heartbeat continue mais que sa charge utile ne correspond plus aux valeurs attendues, le serveur journalise la divergence et l'injecte dans le modèle de score de confiance. Dans les deux cas, le serveur sait en continu si la couche client fonctionne encore, donc un cheat qui désactive la couche client devient immédiatement visible depuis le serveur.
Pourquoi cela compte pour la « résistance au bypass »
Aucun anti-cheat n'est infaillible. Contourner un AC à une seule couche demande de vaincre une pile. Contourner Raven à deux couches demande de vaincre deux piles en même temps, plus le heartbeat, plus le modèle de score de confiance qui fait remonter les anomalies comportementales. Le coût d'un bypass réussi et non détecté est nettement plus élevé, et le délai de livraison d'un correctif est plus court, parce que la couche qui a bien vu le cheat transmet ses données de capture à l'équipe qui prépare la prochaine mise à jour de signature.