Analyse par rétro-ingénierie de l’anti-triche de Call of Duty

 (ssno.cc)
1 points par GN⁺ 2025-01-21 | 1 commentaires | Partager sur WhatsApp
  • Le TAC (Treyarch Anti-Cheat) de Black Ops Cold War est un anti-triche en mode utilisateur, sans pilote noyau Ricochet, mais avec une structure de code en grande partie similaire à celle des titres Call of Duty récents
  • La couche de protection combine le chiffrement d’exécutable, les checksums, l’obfuscation par jmp, l’obfuscation du point d’entrée d’Arxan, ainsi que le chiffrement de pointeurs propre aux branches Treyarch/IW
  • TAC effectue plusieurs détections en mode utilisateur : résolution d’API par hachage à l’exécution, vérification de patterns de hooks d’API, contrôle des registres de debug, détection des signatures de test Windows, détection de l’allocation de console, détection de DirectX/overlays, etc.
  • Les overlays externes sont collectés via le style de fenêtre, la position, l’affinité d’affichage et la liste des modules du processus, puis envoyés au serveur ; les scanners mémoire de type Cheat Engine peuvent être détectés via un pot de miel de mémoire virtuelle
  • La technique la plus singulière est un stub syscall personnalisé chiffré, qui contourne les hooks ntdll et fait passer l’origine du syscall pour une autre fonction ntdll, rendant la surveillance plus difficile

Objet de l’analyse et périmètre

  • L’objet de l’analyse est l’anti-triche en mode utilisateur intégré à Black Ops Cold War, désigné sous le nom de TAC (Treyarch Anti-Cheat)
  • Black Ops Cold War ne contient pas le composant en mode noyau de Ricochet présent dans Modern Warfare 2019 et les titres suivants
  • La grande différence avec les Call of Duty récents est le pilote en mode noyau ; la majeure partie du code anti-triche reste en mode utilisateur et très proche de TAC
  • Le pseudocode des fonctions est reconstruit, car les résultats réels de décompilation sont compliqués par l’obfuscation et le code de résolution
  • Certains éléments ont été retirés afin d’éviter de faire la promotion de la triche ou des contournements

Arxan et la protection de l’exécutable

  • Arxan est un outil d’obfuscation et de protection utilisé dans de nombreux jeux Call of Duty depuis Black Ops 3
  • Déchiffrement de l’exécutable à l’exécution
    • L’exécutable du jeu est packé et chiffré
    • Arxan injecte du code au démarrage pour dépacker et déchiffrer le véritable exécutable du jeu
  • Checksum de l’exécutable
    • Arxan surveille en continu les patchs appliqués à l’exécutable du jeu
    • Si un débogueur ou une divergence de checksum est détecté, le processus est terminé
  • Obfuscation par jmp
    • De nombreux jmp sont insérés entre les instructions des fonctions pour compliquer l’analyse statique
    • Lorsque des centaines de sauts sont insérés dans une grosse fonction, l’analyse IDA se casse et des outils externes deviennent nécessaires
  • Obfuscation du point d’entrée
    • Le code Arxan protégé dépacke puis exécute le véritable point d’entrée
    • Cette zone peut elle aussi contenir une obfuscation par jmp, ce qui complique le suivi du flux

Chiffrement des pointeurs

  • Les pointeurs importants sont chiffrés et déchiffrés juste avant usage
    • objet global courant du jeu
    • tableau d’entités
    • pointeurs d’objets, etc.
  • Ce schéma de chiffrement comprend 16 variantes, et l’adresse PEB courante détermine laquelle est utilisée
  • Cette méthode gêne le pointer scan de Cheat Engine
    • seules les valeurs chiffrées sont stockées dans les variables globales
    • les valeurs déchiffrées n’existent que sur la pile
  • Pour obtenir des pointeurs déchiffrés, il faut soit un outil de traçage des instructions de déchiffrement, soit poser un hook au point où le jeu les a déjà déchiffrés

Résolution d’API à l’exécution et détection de hooks

  • TAC utilise une fonction inline de résolution d’API à l’exécution
    • elle reçoit le hash du module et le hash du nom d’API
    • elle parcourt la liste des modules chargés et hache leurs noms
    • elle parcourt ensuite les fonctions exportées du module et les compare aux hash calculés à la compilation
  • L’identification des hash se fait à partir de la liste des modules chargés dans le processus du jeu et de la fonction de hachage du jeu
    • calcul du hash du nom de module et des noms d’export
    • récupération manuelle du base hash et du function hash dans la décompilation pour faire correspondre l’API appelée
  • Les hash ne sont pas identiques d’une version du jeu à l’autre
  • Comme les pointeurs de fonctions sont stockés dans des variables globales, on peut aussi les identifier en comparant les adresses virtuelles aux fonctions exportées des DLL chargées
  • La détection de hooks d’API de TAC ne vérifie actuellement que 7 patterns
    • stubs de type push/movabs/xchg/ret
    • push imm puis ret
    • call
    • jmp [rip+x]
  • TAC ne vérifie pas toutes les API importantes, mais les hooks des API qu’il utilise lui-même

Registres de debug et détection des signatures de test des pilotes

  • Les registres de debug peuvent servir à des hooks sans patch de code pour contourner la surveillance des patchs .text d’Arxan
  • TAC vérifie les valeurs de DR0 à DR3 dans le contexte du thread
    • si une valeur est présente, un callback est invoqué avec un message différent selon qu’il s’agit du processus courant ou non
    • le flux est ensuite redirigé vers une fonction de terminaison
  • DR0 à DR3 sont des registres privilégiés : ils ne peuvent pas être lus directement en assembleur classique et doivent être récupérés via le noyau Windows ou via la livraison d’exception
  • Le mode test de Windows permet d’exécuter des pilotes en mode noyau sans signature valide
  • TAC vérifie via NtQuerySystemInformation si la signature de test est activée
    • cette détection ne provoque pas directement un ban, mais le compte est signalé

Méthodes de terminaison du processus

  • TAC termine le processus de deux façons
  • La première consiste à effacer les registres puis appeler NtTerminateProcess
    • RCX est mis à -1
    • si NtTerminateProcess est détecté comme hooké, cette méthode n’est pas utilisée
  • La seconde consiste à effacer les registres puis à sauter vers 0x0 pour faire crasher le processus
  • Dans les deux cas, les registres importants étant effacés, la récupération est difficile

Détection de console, visualisation et overlays

  • Les cheats internes peuvent utiliser AllocConsole pour afficher des logs ou implémenter un menu
  • TAC détecte l’allocation d’une console en vérifiant la fenêtre de console ou ConsoleHandle dans le PEB
  • Les visualisations internes sont généralement dessinées à l’écran via des hooks d’API graphique
    • les Call of Duty récents utilisent DirectX 12
    • une cible de hook courante est IDXGISwapChain::Present
    • avec DirectX 12, une command queue est nécessaire, et ID3D12CommandQueue::ExecuteCommandLists est un point d’obtention fréquent
  • OBS Studio, Streamlabs OBS, l’overlay de jeu Discord et l’overlay de jeu Steam peuvent fonctionner à des endroits similaires
    • Steam et Discord effectuent du rendu
    • les outils de la famille OBS capturent l’image rendue lorsqu’ils utilisent la capture de jeu
  • TAC ne scanne pas actuellement la fonction DXGI present elle-même, mais vérifie le pointeur present dans la vtable

Cheats externes et détection basée sur les fenêtres

  • Les cheats externes ont de fortes chances de créer une overlapped window au-dessus de la fenêtre du jeu
  • TAC parcourt toutes les fenêtres et vérifie le style WS_EX_LAYERED avec GetWindowLongA
  • Il compare ensuite via GetWindowRect si elles chevauchent la fenêtre du jeu
    • si le ratio de chevauchement est supérieur ou égal à 0.5 et que le cache contient moins de 8 entrées, le hwnd concerné est stocké
    • des valeurs correspondant à une résolution d’exemple 1920x1080 apparaissent
  • Les fenêtres mises en cache sont examinées plus en détail dans une autre fonction
    • vérification du texte de la fenêtre avec GetWindowTextW
    • vérification du nom de classe avec GetClassNameA
    • vérification de l’affinité d’affichage avec GetWindowDisplayAffinity
  • TAC vérifie aussi les cas où SetWindowDisplayAffinity et WDA_EXCLUDEFROMCAPTURE sont utilisés pour se cacher des outils d’enregistrement ou de capture d’écran
  • Les informations sur les fenêtres sont stockées dans un buffer chiffré puis envoyées au serveur
    • texte de la fenêtre
    • nom de classe
    • position et style de la fenêtre
    • display affinity
    • liste des modules et nom de l’exe du processus de la fenêtre en chevauchement
  • Le processus de la fenêtre en chevauchement est ouvert avec OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION), puis les noms des modules sont collectés via K32EnumProcessModules et K32GetModuleFileNameExW

Détection des scanners mémoire de type Cheat Engine

  • Cheat Engine est facile à détecter à cause du fonctionnement de la mémoire virtuelle sous Windows
  • Même si un programme alloue de la mémoire virtuelle avec VirtualAlloc, elle n’est pas backed par de la mémoire physique avant le premier accès
  • Le jeu peut allouer de la mémoire puis ne pas l’utiliser
  • Si Cheat Engine ou l’onglet mémoire de Process Hacker scanne cette zone, un accès se produit et la mémoire passe à l’état valide
  • Un pot de miel à la TAC permet de détecter les scanners mémoire en vérifiant avec K32QueryWorkingSetEx si cette adresse virtuelle a réellement été touchée

Perturbation du signature scanning

  • Les hackeurs de jeux utilisent souvent le signature scanning pour que leurs cheats continuent à fonctionner automatiquement après les mises à jour
  • L’idée de Treyarch consiste à protéger en PAGE_NOACCESS la zone autour de l’adresse de retour dans une fonction qui ne sera plus rappelée
  • Un signature scanner lit les octets de l’exécutable du début à la fin pour trouver un pattern
  • Vérifier l’accessibilité de chaque octet serait trop lent ; ainsi, atteindre une zone PAGE_NOACCESS peut faire crasher le processus
  • Cette méthode n’est pas une protection absolue, mais elle peut compliquer la tâche de nombreux analystes

Anti-debug

  • Les vérifications anti-debug de TAC lui-même sont simples, mais Arxan fournit aussi ses propres techniques anti-debug
  • TAC parcourt tous les threads du processus courant
    • avec CreateToolhelp32Snapshot et un snapshot des threads
    • il vérifie DbgSsReserved dans le TEB de chaque thread pour détecter la présence d’un DebugObject
  • Il existe aussi une technique qui écrit dans une mémoire invalide afin de provoquer une access violation
    • si le code atteint le point situé après l’exception, il considère que le débogueur a traité ou contourné l’exception
  • CheckRemoteDebuggerPresent est également utilisé
  • ThreadHideFromDebugger force l’envoi des exceptions au processus plutôt qu’au débogueur
    • lorsqu’un débogueur tente de stopper le processus, une exception STATUS_BREAKPOINT peut se produire et entraîner sa terminaison
    • en mode utilisateur, ce flag ne peut pas être retiré
    • cette tactique est exécutée dans un callback TLS avant le point d’entrée de l’exécutable

Surveillance du trafic réseau

  • TAC n’enregistre pas toutes les connexions actives, il recherche seulement certaines conditions
  • La cible est une méthode consistant à créer un serveur réseau local dans le processus du jeu
    • le tricheur écrit un shellcode dans le processus du jeu
    • il démarre un serveur réseau à l’intérieur du processus du jeu
    • une application externe échange ensuite des informations avec ce serveur local
  • TAC récupère la table TCP via GetTcpTable2 et détecte la condition en comparant les connexions créées par le processus courant avec les relations de ports d’autres processus

Stub syscall personnalisé chiffré

  • De nombreuses API exportées par ntdll effectuent un syscall en interne
  • L’usage d’un stub syscall personnalisé permet de contourner les hooks de fonctions ntdll mis en place par des cheats en mode utilisateur
  • Le syscall peut être visible via l’instrumentation callback
    • l’instrumentation callback est appelée après le syscall
    • l’adresse de retour devient celle située juste après l’instruction syscall
  • TAC utilise un stub syscall chiffré pour compliquer l’analyse statique
  • Le stub est construit dans une grande zone allouée dans la section .text, protégée en écriture/exécution
  • Il cherche l’instruction syscall dans NtReadFile et déplace sa position en utilisant une valeur de temps CPU comme élément aléatoire
  • Pour l’outil de surveillance, le syscall peut sembler provenir d’une fonction ntdll arbitraire
    • le syscall réel peut ne pas être NtReadFile
    • sans vérifier l’index syscall dans eax, il est difficile de savoir de quel syscall il s’agit
  • Il existe des exemples où la position de l’instruction syscall change à chaque réexécution

Détection des contournements de masquage anti-debug

  • Pour définir ThreadHideFromDebugger, il faut appeler NtSetInformationThread
  • Un tricheur peut hooker cette API pour lui faire renvoyer un succès
    • l’anti-triche croit alors que le masquage a réussi, alors qu’en réalité rien ne s’est passé
  • TAC détecte les hooks mal conçus en vérifiant le résultat d’appels avec des arguments invalides
    • un appel qui devrait échouer à cause d’un argument de longueur incorrecte est détecté s’il réussit
    • il existe des exemples de valeurs de retour différentes sous débogueur et dans un environnement ScyllaHide
    • un hook renvoyant toujours le succès pour une requête ThreadHideFromDebugger avec un faux handle a aussi été observé

Blocage de la création de threads distants

  • TAC installe un gestionnaire d’exception qui appelle TerminateThread sur le thread courant lors d’une exception STATUS_PRIVILEGED_INSTRUCTION
  • Une DLL chargée par manual mapping a besoin d’un moyen d’exécuter du shellcode dans le processus distant, et CreateRemoteThread est une méthode courante
  • Dans les PE Windows, un callback TLS peut être appelé lors de la création d’un thread avant son point d’entrée
  • TAC vérifie l’adresse de départ dans le contexte du nouveau thread
    • il récupère l’adresse de départ Win32 via NtQueryInformationThread
    • il parcourt la liste des modules chargés pour vérifier si cette adresse se trouve dans la plage d’un module légitime
  • Si l’adresse de départ n’appartient à aucun module chargé, la détection est enregistrée, puis une exception privileged instruction est déclenchée pour terminer ce thread

Vérifications diverses et conclusion

  • Il existe une vérification inconnue où AllocationGranularity de NtQuerySystemInformation doit valoir 0x10000
    • cela semble servir à signaler une machine virtuelle ou une version personnalisée de Windows
  • TAC dépend fortement de la liste des modules liés, et vérifie donc si InMemoryOrderModuleList du PEB est vide
    • le rendre vide risque de casser le processus lui-même
  • En conclusion, TAC est un anti-triche en mode utilisateur offrant les fonctions suivantes
    • résolution d’API à l’exécution
    • détection de hooks mal conçus
    • détection d’overlays externes
    • détection de hooks DirectX internes
    • vérification des hooks sur les API utilisées
    • vérification des débogueurs et des traces de débogage
    • détection de AllocConsole
    • détection de CreateRemoteThread
    • stubs syscall usurpés et chiffrés
  • Arxan complète TAC avec une forte obfuscation, des techniques de perturbation de l’analyse statique, des méthodes qui cassent IDA Pro, une surveillance des modifications de .text et ses propres fonctions anti-debug
  • Un code similaire à TAC est également utilisé dans les jeux Call of Duty modernes

À lire aussi

1 commentaires

 
GN⁺ 2025-01-21
Avis de Hacker News

  • En 2021, mon compte CS:GO sous Linux a eu un problème avec l’indice de confiance : il est passé au jaune, puis au rouge. Ce n’était pas un bannissement officiel, mais en pratique cela fonctionnait comme une sanction.
    Résultat : j’étais constamment mis en relation avec des tricheurs, et il était difficile de trouver des coéquipiers.
    Plus tard, j’ai découvert que d’autres utilisateurs Linux avec des GPU Radeon et 16 Go de VRAM ou plus rencontraient des problèmes similaires, et j’ai créé une issue GitHub pour suivre le problème : https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
    En enquêtant, il semblait que Valve sanctionnait les utilisateurs Linux ayant certaines configurations matérielles, en particulier des cartes Radeon avec 16 Go de VRAM ou plus, assez récentes à l’époque.
    Finalement, après qu’un utilisateur a contacté directement gaben, le problème a été corrigé : https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
    Je suppose que c’était peut-être lié au fait que Valve se préoccupait de l’expérience utilisateur Linux en vue du lancement du Steam Deck.

    • Ou peut-être que Gabe Newell est simplement quelqu’un de bien ?
    • Je ne vois pas très bien en quoi sanctionner des utilisateurs Linux améliore l’expérience utilisateur Linux.
      Mais c’est intéressant malgré tout.
    • Je me demande comment on pouvait savoir que l’indice de confiance était passé au jaune puis au rouge.
      Était-ce déduit de la dégradation de la qualité des parties, ou existait-il un moyen de le vérifier ?
      Si j’ai bien compris, l’indice de confiance est caché pour éviter les abus.

  • La triche est, au fond, un problème humain.
    Les garde-fous et heuristiques décrits dans l’article peuvent filtrer 90 % des tricheurs flagrants, et je pense que ce type d’anti-cheat va globalement dans le bon sens.
    Mais un anti-cheat doit rester conservateur, et au final ce sont les joueurs et les administrateurs qui doivent régler le problème.
    Les jeux multijoueurs en ligne doivent impérativement tourner sur des serveurs administrés par des humains, avec un administrateur présent pendant la majeure partie du temps où les joueurs sont connectés.
    Idéalement, ce devrait être un administrateur que les joueurs reconnaissent ; et quand il n’y en a pas, il devrait au moins exister des formes de modération allégées comme le vote pour expulser ou bannir.
    Il n’y a pas de différence fondamentale entre expulser un tricheur et expulser quelqu’un qui abuse du chat.
    En fin de compte, les seules formes de serveurs réellement viables pour les jeux multijoueurs en ligne sont, selon moi, les serveurs privés ou communautaires.
    Le contrôle des tricheurs et des abuseurs ne devrait pas passer par un système de signalement traité de manière asynchrone ; un administrateur de jeu doit pouvoir expulser ou bannir rapidement.
    Si le jeu en ligne n’est possible que via les serveurs de matchmaking de l’éditeur, et si le traitement des tricheurs ou des abus de chat se limite à un formulaire de signalement web, il ne faut pas acheter ni jouer à ce jeu : votez avec votre portefeuille.

    • Exiger que les jeux multijoueurs en ligne tournent impérativement sur des serveurs administrés par des humains est assez délirant si l’on pense à l’échelle.
    • On dirait plutôt qu’il faudrait mettre un arbitre visible de tous dans chaque partie, et recourir à la vidéo à chaque infraction.
      On pourrait même créer une organisation séparée pour surveiller uniquement les arbitres, mais autant simplement jouer au jeu.
    • Je ne comprends pas pourquoi l’administration humaine serait la seule solution possible.
      Apex Legends fonctionne bien avec un système solide de signalement et d’anti-cheat, et dans Rocket League aussi, une modération largement automatisée fonctionne efficacement.
    • Je suis globalement d’accord, mais il existe d’autres méthodes.
      On peut imaginer un numéro de téléphone, une vérification manuelle par photo, l’obligation de jouer 10 heures avant le mode compétitif, des recommandations d’autres joueurs, ou encore, par-dessus ces conditions, un pass de jeu à paiement unique de 5 dollars.
      Si vous ne l’avez pas encore vue, je recommande la présentation de Valve sur l’anti-cheat par IA.
      Leur travail est assez intéressant, et ils affirment attraper 99 % des tricheurs.
      Bien sûr, il existe toujours des méthodes de triche très subtiles.

  • Il a fallu deux ans de bataille judiciaire pour faire annuler un bannissement permanent mensonger d’Activision, et Activision a perdu faute d’avoir produit la moindre preuve de triche : https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

    • J’ai vécu exactement la même chose avec League of Legends.
      Je n’ai jamais triché, mais j’ai été banni sans explication ; je jouais régulièrement sur trois comptes, et les deux autres n’ont pas été bannis.
      Le support client se contentait de répéter : « après examen, le bannissement est justifié », sans me donner la moindre information qui m’aurait permis de comprendre ce que j’avais fait de mal et de le corriger.
      J’avais certains des skins les plus rares du jeu, des milliers d’heures de jeu depuis 2009, et je ne jouais qu’en ARAM : l’idée que j’aurais triché en risquant un compte à forte valeur sentimentale dans le mode le plus casual n’a aucun sens.
      Je n’ai jamais vécu quelque chose d’aussi stressant lié à un jeu, et le bannissement a finalement été levé sans explication grâce à une connaissance dans l’industrie qui a pu faire vérifier le dossier en interne.
      Je joue encore, mais presque à chaque fois je repense à ce faux bannissement, et je pense que League sera le dernier jeu multijoueur compétitif auquel je consacrerai du temps.
      Une partie de moi n’a plus envie d’y jouer, de peur que cela se reproduise.
    • Moi aussi, j’ai subi un faux bannissement permanent.
      Sur console, tricher est quasiment impossible ; il m’a fallu beaucoup trop de temps pour atteindre péniblement un banal Gold 1 en ranked, et je n’avais jamais reçu le moindre avertissement ni signalement pour quoi que ce soit, mais j’ai été banni définitivement sans explication.
      Au lieu de me battre comme l’auteur, j’ai décidé de ne plus jamais dépenser d’argent dans un produit Activision, et je pense que tout le monde devrait faire de même.
    • Le passage où, quand on joue bien, quelqu’un consulte votre profil pour vérifier votre temps de jeu et voit immédiatement une étiquette rouge disant « je suis un tricheur » me fait me demander si cette étiquette pourrait être considérée comme de la diffamation.
      Aux États-Unis, ce serait probablement plus difficile, mais au Royaume-Uni ou en Angleterre, si je comprends bien, c’est au défendeur de prouver que c’est vrai.
    • C’est horrible d’avoir dû mener un tel combat.
      Heureusement que je joue très peu aux FPS multijoueurs ; je détesterais vraiment risquer de perdre ma vaste bibliothèque Steam.
    • Cet article mériterait à lui seul une soumission séparée, et il est très intéressant.

  • Je suis très curieux de l’obfuscation par sauts
    Ce serait bien si quelqu’un ayant fait davantage de rétro-ingénierie pouvait répondre
    Je me demande si les sauts inconditionnels sont assez courants pour être difficiles à filtrer via certaines conditions préalables ; la fin d’une fonction a un retour, donc elle semble facile à trouver, mais est-ce qu’une méthode consistant à analyser la pile pour savoir où la fonction retourne, puis à trouver l’appel juste avant l’adresse de retour, serait possible ?
    Comme je n’ai pas beaucoup pratiqué la programmation en assembleur x86, il est possible que je comprenne mal le fonctionnement

    • Il existe des techniques élégantes qui utilisent l’exécution symbolique avec des émulateurs comme angr ou https://github.com/cea-sec/miasm pour défaire l’aplatissement du graphe de flot de contrôle
      Le framework PIN d’Intel permet aussi de faire des analyses intéressantes
      Voici des articles qui peuvent aider : https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
    • Les sauts inconditionnels sont très courants, et l’assembleur x86 après optimisation est globalement très désordonné
      Beaucoup de fonctions ne se terminent pas par ret
    • Cette vidéo qui rétro-ingénie une partie de Guitar Hero 3 pourrait être intéressante, car elle aborde des techniques similaires utilisées pour obfusquer fortement le code du jeu : https://www.youtube.com/watch?v=A9U5wK_boYM
    • Il y a quelques problèmes fréquents
      Certains sauts sont faux, et certains sauts entrent au milieu d’instructions
      Les décompilateurs ne savent pas gérer le cas où deux instructions existent au même emplacement
      Par exemple, dans jmp 0x1234, cela revient à sauter l’opcode jmp et à supposer que 0x1234 est une instruction valide
      Dans certaines branches, la pile est corrompue, mais cela peut être intentionnel pour déclencher volontairement une exception
      On peut donc remplacer une instruction comme lea RAX, [rsp + 0x99999999999] par un nop pour corriger la décompilation, mais on risque aussi de manquer une exception intentionnelle
      IDA gère mal ce genre de choses, donc j’utilise une licence Binary Ninja, et il est facile d’écrire des scripts pour inliner des fonctions à destination du décompilateur
      À mon avis, IDA ne gère pas correctement les cas où des sauts réutilisent entre eux des blocs de code, parce qu’un bloc de code entre des sauts ne peut appartenir qu’à une seule fonction
      Les gens semblent moins utiliser Binary Ninja parce qu’il avait un bug sur des jeux Blizzard, mais il a été corrigé il y a environ un an à la suite d’un rapport de bug
    • Ces sauts précis semblent pouvoir être filtrés assez facilement
      C’est une obfuscation destinée à embêter les utilisateurs d’outils courants du commerce, surtout IDA Pro
      La plupart des obfuscations visent simplement à être assez pénibles pour pousser les gens à passer à un autre projet

  • Retirer des fonctionnalités d’un produit après sa vente devrait être interdit par la loi, même si c’est prévu dans le contrat ou l’EULA
    Un bannissement ne devrait pas priver quelqu’un de la propriété du jeu lui-même, et si c’est le cas, il faudrait rembourser
    S’il faut aller jusqu’à un jugement pour obtenir un remboursement, il devrait y avoir, en plus du coût de la licence, des frais d’avocat et de justice, des dommages-intérêts triples
    Par exemple, une situation où l’on est banni de Steam et où tous les achats sont annulés devrait être juridiquement impossible
    Même si la connexion au compte est bloquée, les objets et l’inventaire devraient rester échangeables, car ce sont des choses obtenues par un client payant qui y a consacré du temps réel
    Si l’on veut faire respecter un code de conduite dans un jeu multijoueur, on ne devrait pas pouvoir faire payer le jeu, ou bien les utilisateurs payants devraient avoir des droits en cas de bannissement
    Les bannissements devraient respecter le principe de proportionnalité, avec une procédure et un historique d’appel examinés par un humain, dont le coût serait plafonné au prix de la licence et ne serait dû qu’en cas de rejet

    • Même si l’on triche, on n’est pas banni de Steam
      Au pire, un marqueur public de honte est ajouté au compte pour les jeux VAC
      Les gens jouent à des jeux multijoueurs pour s’amuser et interagir avec d’autres personnes ; donc si cela affecte les autres, qu’il s’agisse de triche ou d’un autre mauvais comportement, l’accès au service multijoueur devrait être bloqué
    • Je ne vois pas en quoi c’est différent d’un excès de vitesse au volant
      Quand on cause des nuisances à la société, en payer le prix est un principe assez universel
    • Je trouve normal qu’un tricheur en subisse réellement les conséquences
      Je pense qu’il peut même perdre de l’argent réel
      En revanche, être banni par erreur est un autre problème
      Et ce qui est banni, ce n’est pas tout le compte Steam, mais le jeu auquel on ne peut plus jouer, non ?
    • Autant leur coller l’étiquette de tricheur et les faire jouer uniquement avec d’autres tricheurs
    • Si vous trichez ou gâchez la partie des autres joueurs, vous méritez de perdre l’accès
      Les autres joueurs ont aussi payé

  • Dans COD, il n’y a même pas besoin de tricher
    Il y a tellement de bugs que le jeu le fait à votre place
    En mode classé, il peut charger une arme à feu au lieu d’un couteau, et cela semble possible parce qu’il y a manifestement un case ou un if-else incorrect dans la vérification de l’équipement des armes en classé ; si l’arme affichée dans le sélecteur d’équipement n’est pas autorisée, il semble revenir par défaut au XM4
    C’est presque le seul jeu que je connaisse dont la version classée soit plus cassée que la version casual

  • Je me demande où on apprend ce genre de choses
    J’aimerais en apprendre davantage, au moins assez pour comprendre ne serait-ce que la moitié de l’article, mais je ne sais pas par où commencer

    • Il y a environ 15 ans, j’ai beaucoup appris en lisant Reversing: Secrets of Reverse Engineering d’Eldad Eilam
      C’est un vieux livre, mais il est excellent, et il fait suivre différentes techniques et exercices pratiques
      Les outils modernes ont un peu changé depuis, mais le jeu d’instructions x86 et l’assembleur en général n’ont pas beaucoup évolué
      L’un des plus grands apports a été de découvrir les crackme
      Ce sont de petits binaires de défi conçus pour apprendre le reverse engineering, un peu comme les cadenas d’entraînement dans la communauté du crochetage
      De mémoire, le livre en contenait plusieurs sur CD-ROM, et on en trouve aussi beaucoup en ligne
      C’est en pratiquant directement ce genre d’exercices qu’on apprend
      Il ne faut pas essayer de faire du reverse engineering sur COD dès le départ, mais construire ses compétences étape par étape
    • À l’époque, j’avais commencé avec les tutoriels Lena151 : https://github.com/kosmokato/Lena151
    • Autrefois, je t’aurais dit d’aller traîner sur Gamedeception, mais il semble que le site ait disparu il y a quelques années
      Salut à ceux qui fréquentaient UnknownCheats, cs.rin.ru, etc.
    • UnknownCheats est l’un des meilleurs endroits pour ce type de ressources
      J’y suis moi-même actif, avec un intérêt particulier pour les anticheats en espace utilisateur sous Linux, surtout le fonctionnement de VAC
    • https://pwn.college est une excellente ressource pédagogique

  • J’ai fait un peu de reverse engineering sur un MMO populaire basé sur Horde/Alliance, et il suivait presque les mêmes étapes, avec aussi des hachages d’exports FNV32
    En voyant des astuces très similaires, ça ressemble presque à la même approche
    Je me demande s’il a été packé avec la même technologie de protection

    • Le moteur Source 2 utilise aussi fnv pour hacher les schémas, c’est-à-dire les propriétés des entités
    • Si Warden a été réutilisé sur la propriété intellectuelle d’Activision après la fusion, ça aurait du sens

  • Le scan de signatures est vraiment puissant
    C’est aussi l’un des aspects du reverse engineering qui me rend le plus accro
    Créer une liste de signatures, puis écrire des bindings pour un langage de script afin de pouvoir appeler ces pointeurs de fonction, c’est amusant
    C’est aussi la base de nombreuses plateformes de mods tierces, parce qu’elles doivent fournir aux moddeurs des API utiles que le studio d’origine n’a pas exposées

    • Je ne sais pas ce qu’est le scan de signatures, mais j’ai trouvé une ressource pour ceux que ça intéresse : https://www.unknowncheats.me/forum/general-programming-and-r...
    • Oui
      Je sais que certains plugins du moteur Source utilisent aussi cette méthode quand c’est nécessaire
      Cela dit, la plupart semblent plutôt utiliser l’offset du pointeur de table de fonctions virtuelles

  • Je me demande s’il serait possible, ou utile, de signer électroniquement l’état du jeu à intervalles réguliers, ou d’ajouter une forme de preuve de travail pour empêcher la triche
    Je commence à penser que la triche est un problème extrêmement difficile à empêcher
    Je développe un petit FPS en ligne peu coûteux, et plutôt que d’y mettre un logiciel anticheat, j’envisage de laisser les utilisateurs se faire confiance entre eux et repérer eux-mêmes les tricheurs, ou bien d’utiliser l’IA comme Valve
    Je pense laisser les joueurs gérer et administrer eux-mêmes les serveurs
    On pourrait imposer des conditions comme associer un numéro de téléphone, des scores de réputation donnés par d’autres joueurs, une pièce d’identité ou un autre moyen d’authentification fort, une vérification manuelle par photo comme dans les apps de rencontre, ou encore 10 heures de jeu avant les matchs compétitifs
    Je pense que les joueurs hardcore accepteraient volontiers ce genre de procédures pour réduire le nombre de tricheurs

    • Si tu as un peu joué à des jeux en ligne, tu sais que les joueurs lancent constamment des accusations de triche avec très peu de preuves
      Il existe aussi des abus sociaux consistant à signaler des joueurs qu’on n’aime pas pour les faire bannir
      Dans un tel système, il y aurait bien plus de faux positifs qu’avec n’importe quel anticheat
    • À haut niveau, il suffirait de simuler une partie sans triche, de la signer, et de traiter les cheats séparément