Visite guidée des systèmes anti-cheat des jeux vidéo modernes

Alors que les jeux vidéo deviennent toujours plus sophistiqués, une bataille sans merci se joue dans l’ombre : celle des développeurs contre les tricheurs. Et c’est grâce à une analyse récente et particulièrement détaillée de ssno, que nous allons pouvoir plonger dans les entrailles des systèmes anti-triche modernes.

Commençons par le socle de de l’une de ces protections : Arxan. Ce système d’obfuscation fait office de première ligne de défense dans de nombreux jeux Call of Duty depuis Black Ops 3. Son rôle est de rendre la vie impossible aux ingénieurs en rétro-conception et aux développeurs de logiciels de triche.

À noter qu’Arxan ne se contente pas de brouiller le code : il surveille également l’environnement Windows, histoire de repérer par exemple si le système est en test mode (une fonctionnalité qui permet de charger des drivers non signés). Cette vérification passe notamment par NtQuerySystemInformation pour voir si la signature des pilotes est forcée ou non. Tout ça pour dire que, si Windows est démarré en mode test, vous vous exposez à un flag de la part des serveurs du jeu.

Pour cela, Arxan utilise différentes techniques de protection :

• Chiffrement dynamique : L’exécutable du jeu est chiffré et déchiffré à la volée pendant son exécution
• Vérifications d’intégrité : Des contrôles continus pour détecter toute modification du code
• Obfuscation des sauts : Les fonctions sont fragmentées et dispersées avec des instructions de saut
• Protection de l’entrée : Le point d’entrée du programme est masqué et protégé
• Chiffrement des pointeurs : Les adresses mémoire critiques sont chiffrées dynamiquement

Mais la véritable innovation réside dans le système baptisé TAC (Treyarch Anti-Cheat). Cette solution s’intègre directement dans l’exécutable du jeu et met en œuvre des techniques de détection particulièrement astucieuses.

TAC traque les tentatives d’analyse du jeu en surveillant les hooks d’API avec reconnaissance des signatures connues, les debuggers via divers mécanismes comme ThreadHideFromDebugger mais également tout ce qui est overlays qui pourraient servir à afficher des menus de triche ou encore consoles de debug non autorisées.

D’ailleurs, il a quelques ruses pour débusquer les hooks trop « grossiers » : TAC peut appeler volontairement NtSetInformationThread avec des paramètres bidon et vérifier que la fonction retourne l’erreur attendue. Si jamais ça répond OK alors que ça ne devrait pas, c’est qu’un hook mal fichu est passé par là !

Maintenant, pour contrer l’injection de code malveillant, TAC utilise plusieurs stratégies qui sont toutes détaillées ici dans la source. C’est assez technique mais, vous verrez, l’une des fonctionnalités les plus sophistiquées de TAC est son système d’appels système chiffrés. Au lieu d’emprunter les fonctions Windows classiques (via ntdll.dll par exemple), TAC va fouiller ailleurs dans la mémoire système pour y dénicher une instruction syscall et en construire un « stub » custom. Ce stub est ensuite masqué (XOR, crypté, etc.) et placé à un endroit aléatoire. Du coup, les tentatives pour surveiller les appels système sont bien plus difficiles, car on ne sait jamais quelle API est réellement invoquée et où se trouve l’instruction syscall !

En prime, TAC bloque aussi le signature scanning en créant des blocs de code rendus inaccessibles (PAGE_NOACCESS) au bon moment. Comme il s’agit de zones de code « mortes » qui ne devraient pas être parcourues, tout outil de scan qui passerait dessus se prendrait un bon vieux crash. Ça complique sérieusement la vie des tricheurs qui cherchent des patterns mémoire à patcher.

TAC surveille encore plus de choses : par exemple, il n’aime pas qu’un AllocConsole soit appelé dans le processus pour déboguer ou afficher des infos d’un cheat interne. Alors il check si un handle console est apparu dans les ProcessParameters du PEB ou si GetConsoleWindow() renvoie quelque chose. Résultat : la moindre console non prévue = suspicion de triche.

Côté scans de mémoire, il existe même un “honeypot” de pages allouées mais jamais utilisées par le jeu. Si un outil type Cheat Engine vient les lire, cette zone se retrouve alors subitement mappée physiquement, et TAC remarque direct que “quelque chose” a fouiné là. Bien vu pour repérer les scanners mémoire intempestifs.

Comme vous le voyez, c’est hyper pointu. Sans oublier que TAC surveille également les communications réseau locales qui pourraient trahir la présence d’outils de triche. Il analyse les connexions TCP locales, il détecte les serveurs de commande & contrôle et surveille les ports utilisés par les cheats connus. D’ailleurs, il compare le LocalPort du jeu avec d’autres connexions sur la même machine pour voir si un cheat ne ferait pas un « C&C » local, en transmettant des infos en interne. L’idée, c’est de repérer un port louche ouvert par le même processus (ou par un autre) qui causerait avec le jeu.

Maintenant pour comprendre ces protections, les chercheurs comme ssno doivent faire preuve d’ingéniosité. Il doivent développer des outils d’analyse personnalisés, reconstruire les algorithmes de chiffrement, tracer les flux d’exécution complexes et bien sûr comprendre les mécanismes de protection imbriqués. Ça fait beaucoup de boulot mais ça nous permet de voir que les développeurs innovent sans cesse pour protéger leurs créations. Au passage, TAC va aussi vérifier des petites choses plus “système” comme la AllocationGranularity ou la liste de modules Windows (ce qui se trouve dans InMemoryOrderModuleList) pour repérer un OS custom ou un sabotage de la structure PEB/LDR. Pas de détail laissé au hasard !

D’ailleurs on commence à voir un usage accru de l’IA pour la détection des comportements suspects mais également la mise en place de protection matérielle via les processeurs nouvelle génération. Et bien sûr tout ce qui est analyses comportementales plus poussées ou encore chiffrement homomorphe pour les données sensibles. C’est vraiment un domaine passionnant !

Bien sûr, toutes ces découvertes doivent être utilisées de manière éthique et responsable, parce que tricher, que ce soit aux jeux vidéos ou aux élections, ça reste nul.

Pour une analyse technique complète et détaillée, consultez la source originale de cette étude. Et un grand merci à Miguel pour le partage !