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