Comment fonctionnent les anti-triches au niveau du noyau

• Les systèmes d’anti-triche modernes basés sur le noyau comptent parmi les logiciels de sécurité les plus complexes de l’environnement Windows, et surveillent la mémoire et les événements système au niveau du noyau même pendant l’exécution du jeu
• Pour dépasser les limites des protections en mode utilisateur, ils s’appuient sur des pilotes noyau et surveillent en temps réel la création de processus et de threads, le chargement d’images, les modifications du registre, etc.
• Les principaux systèmes comme BattlEye, EasyAntiCheat, Vanguard, FACEIT AC fonctionnent selon une architecture à trois couches composée d’un pilote noyau, d’un service et d’une DLL du jeu ; Vanguard, chargé au démarrage, dispose du contrôle le plus fort
• Ils bloquent la triche en combinant des défenses multicouches comme l’analyse mémoire, la détection de hooks, la vérification de l’intégrité des pilotes, la réponse aux attaques DMA et la détection comportementale
• En fin de compte, l’attestation à distance fondée sur le TPM et la vérification de la confiance matérielle s’imposent comme les fondations clés de la sécurité des jeux

---

1. Limites des protections en mode utilisateur et passage au noyau

• Les processus en mode utilisateur disposent de privilèges inférieurs à ceux du noyau, et sont donc facilement contournés par des triches au niveau des pilotes noyau ou de l’hyperviseur
  • Exemple : un appel ReadProcessMemory peut être falsifié via un hook noyau
• Les triches en mode noyau peuvent manipuler directement la mémoire du jeu et éviter les détections en mode utilisateur
• Pour y répondre, les anti-triches sont passés au niveau du noyau afin d’effectuer leur surveillance avec le même niveau de privilèges

2. La « course aux armements » entre triche et anti-triche

• Une course à l’élévation de privilèges se poursuit : mode utilisateur → noyau → hyperviseur → DMA
• Les anti-triches répliquent avec le blocage de pilotes, la détection d’hyperviseurs et des défenses DMA fondées sur l’IOMMU
• Ce processus augmente le coût et la difficulté de développement des triches, avec pour effet de bloquer l’accès des utilisateurs ordinaires

3. Principaux systèmes d’anti-triche au niveau du noyau

• BattlEye : centré sur le pilote noyau BEDaisy.sys, avec enregistrement de callbacks pour les processus, les threads et le chargement d’images
• EasyAntiCheat (EAC) : propriété d’Epic Games, avec une architecture à trois couches similaire
• Vanguard : charge vgk.sys au démarrage et exerce un contrôle fort grâce à un modèle de liste blanche de pilotes
• FACEIT AC : obtient un haut niveau de confiance grâce à une surveillance au niveau du noyau
• L’article ARES 2024 précise que ces systèmes présentent une structure technique proche de celle des rootkits, mais avec un objectif défensif

4. Architecture à trois couches des anti-triches noyau

• Pilote noyau : hook des appels système, scan mémoire et contrôle d’accès
• Service en mode utilisateur : communications réseau, gestion des bans et envoi de télémétrie
• DLL du jeu : vérifications à l’intérieur du processus du jeu et IPC avec le service
• La communication mutuelle passe par IOCTL, Named Pipe et Shared Memory

5. Différence entre chargement au démarrage et chargement à l’exécution

• BattlEye/EAC : chargent le pilote au lancement du jeu et le déchargent à la fermeture
• Vanguard : se charge au démarrage et surveille ensuite tous les pilotes chargés par la suite
  • Cela nécessite un redémarrage du système et permet une protection dès la phase de boot

6. Surveillance fondée sur les callbacks noyau

• ObRegisterCallbacks : contrôle d’accès aux handles de processus, blocage des accès mémoire depuis des processus externes
• PsSetCreateProcessNotifyRoutineEx : blocage de la création de processus de triche
• PsSetCreateThreadNotifyRoutine : détection de threads anormaux dans le processus du jeu
• PsSetLoadImageNotifyRoutine : détection du chargement de DLL non autorisées
• CmRegisterCallbackEx : surveillance des modifications du registre
• Pilotes minifiltres : blocage, au niveau du système de fichiers, de l’accès aux fichiers de triche

7. Protection de la mémoire et scanning

• Restriction de l’accès aux handles pour bloquer les lectures/écritures mémoire externes
• Vérification par hash des sections de code afin de détecter les patchs de code
• Parcours de l’arbre VAD pour détecter la mémoire exécutable mappée manuellement
• Identification heuristique de la mémoire exécutable anonyme, des DLL mappées manuellement et du shellcode

8. Détection d’injection

• Détection de diverses techniques d’injection comme CreateRemoteThread, APC, NtMapViewOfSection, Reflective DLL
• Analyse des stack frames (RtlWalkFrameChain) pour vérifier l’exécution de code anormale

9. Détection des hooks

• Hook IAT : détection de la modification de la table des adresses d’importation
• Hook inline : vérification d’un patch via comparaison des instructions JMP au début des fonctions
• Contrôle d’intégrité de la SSDT, de l’IDT et de la GDT pour empêcher les hooks au niveau du noyau
• Détection de l’usage direct de syscall afin de bloquer les tentatives de contournement de ntdll

10. Protection au niveau des pilotes

• Détection des pilotes non signés et du mode de signature de test
• Maintien de blocklists pour bloquer les attaques BYOVD (Bring Your Own Vulnerable Driver)
• Surveillance de structures internes du noyau comme PiDDBCacheTable, MmUnloadedDrivers, BigPool pour détecter les pilotes mappés manuellement

11. Anti-debugging et prévention de l’analyse

• Vérification de la présence d’un débogueur avec NtQueryInformationProcess
• Détection d’un débogueur noyau via la variable KdDebuggerEnabled
• Détection de threads cachés grâce au flag ThreadHideFromDebugger
• Blocage des environnements d’analyse via des vérifications temporelles fondées sur RDTSC, des points d’arrêt matériels et la présence d’un hyperviseur

12. Triches fondées sur DMA et contre-mesures

• Les périphériques DMA PCIe peuvent lire la mémoire sans intervention du CPU
• L’IOMMU limite les accès DMA, mais peut être neutralisée si elle est désactivée ou mal configurée
• Le déguisement de périphériques FPGA en périphériques légitimes rend la détection difficile
• Une partie du risque peut être atténuée par la vérification de l’intégrité du démarrage via Secure Boot et TPM 2.0

13. Détection comportementale et machine learning

• Analyse des entrées souris pour distinguer les mouvements humains d’un aimbot
• Détection de triggerbots et d’aimbots à l’aide de modèles CNN et Transformer
• Détection de fraudes en équipe (wallhack, collusion) via des graph neural networks
• Pipeline de télémétrie : capture des entrées au niveau du noyau → transmission chiffrée → analyse ML côté serveur → décision de ban

14. Environnements virtuels et évasion de l’analyse

• Détection des VM via le bit hyperviseur de CPUID et les chaînes de fournisseur
• Vérification des traces dans le registre et des périphériques de VMware, VirtualBox et Hyper-V
• Les environnements de virtualisation imbriquée peuvent être identifiés par le retard d’exécution des commandes

15. Identification matérielle et application des bans

• Génération d’un HWID à partir de SMBIOS, disque, GPU, MAC, MachineGuid, etc.
• Le spoofing de HWID est tenté via le registre, les pilotes ou des manipulations physiques,
  mais peut être détecté grâce à des incohérences d’identifiants ou des formats anormaux

16. Tendances futures et transition technique

• Après le DMA, l’étape suivante est celle des triches fondées sur le firmware, avec une difficulté de détection extrême
• Les aimbots matériels fondés sur l’IA sont difficiles à distinguer des entrées humaines
• L’attestation à distance fondée sur le TPM et le cloud gaming émergent comme alternatives de long terme
• Les anti-triches noyau restent la ligne de front la plus concrète,
  mais la vérification de la confiance matérielle et la validation côté serveur sont présentées comme la direction ultime

[GN⁺]

Réactions sur Hacker News

• En résumé, les cheats modernes contournent l’anti-cheat via des hyperviseurs, des patchs BIOS, des périphériques DMA, etc.
  Plus la protection se renforce au niveau matériel, plus les créateurs de cheats évoluent eux aussi.
  Mais avec l’arrivée de l’analyse de jeu basée sur l’IA, les méthodes qui détectent directement les cheaters commencent à montrer leur efficacité.
  Au final, l’avenir semble appartenir non pas au mode kernel, mais aux anti-cheats en mode utilisateur et à l’analyse du gameplay.

  • Dire que le patching du BIOS est « très populaire » semble exagéré.
    J’y vois plutôt la preuve que les anti-cheats fonctionnent bien.
    Avant, il suffisait de télécharger un programme pour tricher immédiatement, alors qu’aujourd’hui la barrière à l’entrée est plus élevée, au point que beaucoup ne s’y essaient même pas.
    Cela dit, le début de l’article expliquait aussi que ces défenses peuvent être neutralisées, ce qui laisse douter de leur fiabilité.
  • Je joue à WoW, et il y a eu beaucoup de plaintes disant que Blizzard avait banni des utilisateurs innocents.
    Deux de mes comptes ont été bannis, puis rétablis via le support client.
    Mais comme on dirait que l’IA est utilisée dans le support, j’ai l’impression qu’il doit y avoir beaucoup de bans injustifiés.
    Ces systèmes de bannissement basés sur le comportement risquent aussi de sanctionner à tort des joueurs très investis, ce qui les rend difficiles à croire fiables.
  • Les techniques que tu mentionnes ont pour effet d’augmenter le coût de l’attaque.
    Autrement dit, tout le monde ne peut plus fabriquer un cheat, donc l’anti-cheat obtient un certain succès.
    En revanche, l’analyse du gameplay risque de n’attraper que les cheaters les plus flagrants et de laisser passer les simples outils de type ESP.
  • L’analyse comportementale ne détecte pas les « cheaters discrets ».
    Ils sont encore plus dangereux, car ils détruisent lentement la communauté.
  • ActiBlizz est quasiment la seule entreprise à mener régulièrement des actions en justice contre des développeurs de cheats payants comme Bossland ou EngineOwning.

• Toucher au kernel revient à ignorer tout le modèle de sécurité de l’OS.
  Il y a eu en pratique des cas où des anti-cheats bogués ont permis une élévation en root.
  La bonne approche consiste à exploiter les fonctions de sandbox de l’OS et la chaîne de confiance au démarrage.

  • L’écosystème PC ne traite pas la sécurité de la chaîne de boot avec autant de sérieux que les téléphones.
    Il est donc difficile de ne s’appuyer que sur les fonctions de l’OS, et l’attestation a en pratique une portée limitée.
    Même si ce n’est pas parfait, si cela permet de réduire statistiquement le nombre de cheaters, cela a tout de même de la valeur.
  • La vraie sécurité ne consiste pas à verrouiller le client, mais à vérifier côté serveur uniquement les actions autorisées.
  • On peut aussi se demander si cela revient à dire « vendons des PC verrouillés où seuls des logiciels approuvés peuvent être installés ».
  • L’affirmation selon laquelle « réduire les dégâts après l’intrusion d’un attaquant ne sert à rien » n’est pas vraie pour la cybersécurité en général.
  • Vouloir empêcher la triche au prix de la liberté de chacun d’exécuter les logiciels de son choix est excessif.

• J’aimerais voir un jeu avec un système de matchmaking anti-cheat optionnel.
  Ceux qui activent l’anti-cheat seraient appariés entre eux, et ceux qui le désactivent évolueraient dans un cadre régi par l’autorégulation de la communauté.
  Un tel test ne semble possible que pour une entreprise de la taille de Valve.

  • Le CS2 de Valve utilise apparemment une approche proche, mais on entend dire que le taux de triche y est plus élevé que dans Valorant.
  • FACEIT joue déjà ce rôle.
    Mais l’autorégulation communautaire n’est jamais vraiment efficace à grande échelle.
  • Certains ont aussi réagi par « ce n’est pas justement PlaySafe ID ? ».
  • Je suis moi aussi favorable à cette idée.
    Personnellement, quand il y a un cheater, je préfère simplement quitter la partie et aller prendre l’air dehors.
    Plutôt que d’installer un anti-cheat au niveau kernel qui ressemble à du malware, je préfère encore jouer sur console.

• Les cheaters présentent par nature des schémas de comportement anormaux, donc on peut les repérer en enregistrant toutes les entrées côté serveur et en appliquant une détection d’anomalies basée sur le machine learning.
  On peut aussi créer des objets « honeypot » conçus pour ne provoquer une réaction que chez les cheaters.

  • Mais on ne peut pas conclure qu’une personne triche uniquement à partir d’anomalies statistiques.
    Comme avec le p-hacking, on peut prendre une variation due au hasard pour un signal significatif.
  • Je défends depuis longtemps l’idée d’un modèle statistique de honeypot.
    D’ailleurs, Dota 2 a effectivement banni tous les comptes ayant lu une zone de données anormale à l’intérieur du client.
    Annonce de patch liée
  • Pourtant, Valve utilise aussi des modèles de ML depuis longtemps, et malgré cela Counter-Strike compte toujours beaucoup de cheaters.
    Ce n’est pas un problème qu’on résout en jetant simplement du ML dessus.
  • Les honeypots sont utiles, mais insuffisants.
    L’analyse comportementale a du mal à suivre le rythme des évolutions de la communauté.
  • Dans CS2, les statistiques de « time-to-damage » suffisent déjà à distinguer de nombreux cheaters.
    Les cheaters réagissent souvent environ 100 ms plus vite que les pros.

• Je ne suis pas gamer, mais je trouve que le problème anti-triche dans les jeux en ligne est un défi technique fascinant.
  Le conseil simpliste qui consiste à dire « faites tout côté serveur » n’est pas réaliste.

  • Empêcher totalement la triche est pratiquement impossible.
    Un jeu, ce n’est pas les Jeux olympiques mais plutôt une ligue de quartier : le plaisir compte plus que l’équité parfaite.
    Si les cheaters étaient appariés entre eux, l’impact sur les joueurs ordinaires serait moindre.
  • La méthode la plus efficace reste qu’un administrateur serveur actif observe directement et bannisse.
    Mais les grands éditeurs n’emploient pas ce type de personnel.
  • Techniquement, les cheaters gardent toujours l’avantage parce qu’ils contrôlent la machine sur laquelle tourne le jeu.
    L’anti-cheat ne fait qu’élever la barrière à l’entrée.
  • On pourrait aussi imaginer une architecture distribuée avec des serveurs placés près des FAI, comme Netflix.
  • La solution fondamentale est un changement de perception culturelle.
    Il faudrait une ambiance où tricher en ligne est vu comme un comportement de loser.

• Les anti-cheats au niveau kernel cherchent à verrouiller au maximum le client, mais les cheaters existent quand même.
  Cela signifie au final que le serveur ne peut jamais faire une confiance totale au client.

  • Ce n’est pas seulement une question de coût, mais aussi de latence et de décalage temporel.
    Même le code réseau ne peut pas le résoudre complètement.
  • Un cheater vraiment motivé peut aussi automatiser les entrées avec une caméra et un ordinateur séparé.

• La culture compétitive des jeux actuels repose sur une structure où les entreprises poussent les utilisateurs à affronter des inconnus plutôt que des amis.
  Mais on peut se demander s’il est vraiment nécessaire d’aller aussi loin.

  • Malgré tout, beaucoup de gens aiment la compétition en elle-même.
    Comme dans le sport ou aux échecs, mesurer son niveau à celui des autres répond à un désir humain fondamental.

• Dire que l’anti-cheat kernel serait « le logiciel le plus sophistiqué » semble exagéré.
  Intercepter des appels système n’a rien de particulièrement extraordinaire.

  • La phrase selon laquelle il « scanne des structures mémoire que la plupart des programmeurs ne toucheront jamais de leur vie » est un peu ridicule.

• On dirait que beaucoup ici n’ont jamais joué à des jeux compétitifs.
  Le Kernel-level anti-cheat (KLAC) est réellement efficace.
  Par rapport aux solutions basées sur VAC/VACNet, les systèmes kernel comme FACEIT ou Vanguard affichent un taux de triche bien plus faible.
  Bien sûr, ce n’est pas parfait, mais cela augmente fortement la barrière à l’entrée.
  Rien que les périphériques DMA coûtent plusieurs centaines de dollars, et les cheats avancés sont chers car vendus par abonnement.
  Jouer est un choix, donc si l’on n’aime pas le KLAC, on peut simplement ne pas y jouer.
  Mais le refuser, c’est aussi accepter un environnement infesté de cheaters.

• J’avais entendu dire que les mesures de démarrage basées sur le TPM et UEFI Secure Boot permettaient une attestation distante, donc c’est surprenant d’apprendre qu’un attaquant peut aussi manipuler cela.

  • Par exemple, tee.fail montre comment neutraliser l’attestation distante.
    Nous devrions avoir la liberté de garantir pleinement la propriété de nos appareils sans être discriminés.
  • La communication entre la carte mère et la puce TPM n’est pas chiffrée, ce qui permet de modifier les valeurs via une attaque MITM.