Interdire les faux clients

Version imprimable

15/02/2011, 02h44
Davidlouiz

Interdire les faux clients

Bonjour,

Je développe un FPS jouable en réseau. Le protocole de communication est très simple. J'aimerais savoir comment s'assurer qu'un joueur ne s'est pas recodé un client utilisant le même protocole de communication mais avec une interface différente : suppression du brouillard, visibilité des joueurs...

Ceci constituerait une triche indétectable par le serveur.

Pour bloquer le faux client, j'avais pensé à un protocole de questionnement : le serveur pause des questions au client que seul un vrai client est capable de répondre.

Voici un exemple :
Le serveur envoie une série de nombres aléatoires au client : "12 45 81 35 56". Le client utilise une règle de calcule relativement complexe pour produire un nombre à partir de ces nombres et les retourne au serveur. Le serveur effectue les mêmes opérations de son côté et au retour de la réponse, il compare les deux résultats. S'ils sont identique, le client est authentique.

Cette méthode fonctionnerait sans doute jusqu'à ce qu'un crackeur réussisse à produire un générateur de clé en réutilisant le binaire de mon client. Donc la solution n'est pas suffisante et j'ai l'impression de tourner en rond.

Avez-vous une solution pour détecter ce genre de triche ?

Merci.
15/02/2011, 08h13
nouknouk

Bonjour,

D'une façon générale, il est effectivement impossible de garantir à 100% que le client qui se connecte au serveur de jeu est bien le client original, non modifié. Tout ce qu'on peut faire c'est complexifier suffisamment le rétro-engineering pour essayer de convaincre le hacker que "le jeu n'en vaille pas là chandelle".

C'est d'ailleurs aussi pour ça (ie. l'absence de garantie) que le serveur lui-même ne doit jamais faire confiance à ce que peut lui envoyer un client et vérifier systématiquement tout donnée reçue, à la fois au niveau de la forme, mais aussi au niveau du contenu lui-même.

Ceci dit, il y a effectivement dès choses qui restent invérifiables par le serveur. Le bon affichage d'un brouillard est un bon exemple. Dans ce cas, il faut effectivement trouver un moyen de tester l'intégrité du client. Mais autant la méthode de questions/réponses serait efficace pour détecter des clients entièrement réécrits, autant elle sera inefficace pour des clients patchés.

Je pense que pour ce cas là, il faut ajouter des questions réponses qui vont utiliser quelque chose comme le fichier exécutable du client pour produire une empreinte (genre un md5) qui permettra de détecter tout 'patch' du client originel.

À noter qu'afin de durcir le rétro-engineering, toute cette partie de communication doit être un minimum chiffrée pour ne pas trop 'faciliter' là tâche aux hackers.
15/02/2011, 11h39
Hydrargyrum

Le meilleur moyen pour limiter la triche est de partir du principe que le tricheur connait toutes tes techniques (elles finiront toujours par être percées, quelque soit leur complexité) et possède les outils nécessaires pour trafiquer toutes les données qu'il t'envoie / reçoit.

Toutes les techniques à bases de "je demande au client de me renvoyer un truc pour vérifier qu'il a pas fait de bidouille" sont craquées en 5 minutes chrono (il y a des utilitaires spécialement dédiés à ça pour la triche sur WoW ... utilisables par un gamin sans compétences particulières en informatique).

C'est la conception des relations client/serveurs qu'il faut modifier si tu veux limiter la triche, en gardant en tête que le client doit pouvoir corrompre 100% des informations qu'il envoie / reçoit sans que cela puisse lui offrir un avantage :
-> En réception : vérifier qu'un client peut bien exécuter une commande.
Si le joueur dit "je lance une grenade en vers la position 12 / 42", vérifier qu'il a bien une grenade ...
Si le joueur dit "j'ouvre la porte rouge", vérifier qu'il est bien à une distance raisonnablement proche de la porte en question, etc ...
-> En émission : le serveur ne doit envoyer que les données strictement nécessaires au client.
Dans le cas de la position des autres joueurs, le serveur calcul grossièrement ceux visibles par le client, et ne lui envoie que ces informations là.
Dans le cas du brouillard de guerre, tu n'envoie que la liste des unités qui ne sont pas sous le brouillard du client : comme ça même si le tricheur enlève le brouillard, il n'y aura rien d'intéressant dessous. etc ...

Évidemment, ca augmente pas mal les calculs du serveur. Après c'est à toi de choisir entre vitesse et sécurité.
15/02/2011, 12h43
nouknouk

Citation:

Envoyé par Hydrargyrum

Toutes les techniques à bases de "je demande au client de me renvoyer un truc pour vérifier qu'il a pas fait de bidouille" sont craquées en 5 minutes chrono (il y a des utilitaires spécialement dédiés à ça pour la triche sur WoW ... utilisables par un gamin sans compétences particulières en informatique).

Oui et non: les utilitaires en question on mis bien plus que 5 minutes à être programmés et sont spécifiques à un jeu en particulier (WoW dans ton exemple).

Ceci dit, il faut relativiser: l'intérêt de craquer un jeu dépend directement de sa notoriété: un jeu ultra connu et répandu comme WoW peut être certain que des centaines de hackeurs seront prêt à passer jour et nuit sur le programme pour trouver la faille ; un jeu amateur qui a une diffusion plus ou moins confidentielle n'intéressera probablement pas les hackeurs.

Citation:

C'est la conception des relations client/serveurs qu'il faut modifier si tu veux limiter la triche, en gardant en tête que le client doit pouvoir corrompre 100% des informations qu'il envoie / reçoit sans que cela puisse lui offrir un avantage

Oui, c'est nécessaire. Mais comme dit précédemment, tout n'est pas vérifiable côté serveur (par exemple le wallHack, notamment dans Counter Strike). D'où l'intérêt de mettre en place des outils pour détecter quand un client a été patché.
15/02/2011, 21h41
Davidlouiz

Citation:

(...) il faut ajouter des questions réponses qui vont utiliser quelque chose comme le fichier exécutable du client pour produire une empreinte (genre un md5) qui permettra de détecter tout 'patch' du client originel.

L'empreinte de l'exécutable originale peut être inscrite en dur dans le client patché. Et celle-ci se retrouve assez facilement avec un analyseur de tram.

Un autre problème se pose : mon jeu sera OpenSource et son développement sera expliqué de A à Z. Il sera alors très facile pour un programmeur de reprendre les sources, de supprimer le brouillard (une ligne à supprimer) et entrer la signature en dur avant de le recompiler.

Citation:

À noter qu'afin de durcir le rétro-engineering, toute cette partie de communication doit être un minimum chiffrée pour ne pas trop 'faciliter' là tâche aux hackers.

Effectivement. Mais je tiens absolument à ce que le protocole reste très simple et très lisible car il est destiné à être épluché par des programmeurs qui souhaiterait s'initier au développement de jeu vidéo.

Je te remercie nouknouk pour ta solutions qui, en soit, reste relativement simple à mettre en œuvre.

Hydrargyrum, pour ce qui est des actions à effectuer, le client n'envoi que des demande au serveur. C'est ce dernier qui exécute les actions et envoi régulièrement aux client l'état de la partie.

En revanche, je n'avais pas pensé à ne pas envoyer la position des personnages sensés être invisible par le joueur. Et je pense que c'est ça la solution. N'ayant pas toutes les informations sur l'état de la partie, le joueur ne pourras pas se placer dans une situation qui lui serait plus favorable.

Cette solution n'empêche pas les joueurs de se recoder leur propre client tout en restant efficace face à la triche.

En revanche, cela est plus difficile à mettre en œuvre. Plutôt que d'envoyer à tout les clients la même situation de la scène, je devrais envoyer une situation personnalisée à chacun des clients.

Je pense que je vais mettre en œuvre un mécanisme qui consiste à n'envoyer au client que la position des personnages qui se situe avant la limite du brouillard.

Pour ce qui est du Wallhack, il me semble difficile de déterminer si un personnage se cache derrière un mur avant d'envoyer sa position, je ne ferais donc pas ce test. Par contre, il serait possible de faire un mécanisme (dans le cas d'un jeu non-OpenSource) qui vérifie si le joueur à tendance à suivre du viseur les déplacements des joueurs cachés par les murs et réagir en conséquence, notamment dans le cas des jeux nécessitant un compte.

Je pense qu'on a fait le tour de la question et je vous remercie.

A bientôt.