Comment puis-je empêcher les rapports de faux scores dans les tables des meilleurs scores globaux?

Les jeux sur navigateur et sur mobile ont généralement des tables de scores globales. Il est également courant que ces tableaux contiennent des scores de 2 147 483 647 - les internautes ayant compris l'appel du service Web qui rapporte les scores et s'en sont servi pour enregistrer un score fictif.

Pour les jeux de casse-tête simples, nous pouvons nous défendre contre cela en incluant un enregistrement de chaque mouvement effectué par le joueur (et de toute graine aléatoire utilisée pour générer le niveau) avec l'appel de compte rendu de score. L'ensemble du jeu peut alors être reproduit et vérifié sur le serveur.

Cependant, cela devient rapidement irréalisable pour tout ce qui est plus grand que Pac-man.

Sinon, comment éviter ce genre de triche?

Le système interne utilisé pour Moblox (remplacé plus tard par OpenFeint) fonctionnait comme suit:

• Envoyez un message JSON sur HTTP pur (pas HTTPS). Incluez un hachage MD5 de tous les champs plus une chaîne magique.
• Sur le serveur, vérifiez l'intégrité du message avec la même opération.

Pour casser le système, il faudrait trouver cette chaîne magique. C'est possible avec l'ingénierie inverse, mais douloureux.

OpenFeint, ScoreLoop et CocosLive utilisent tous la même astuce, mais avec HTTPS. Très facile à mettre en œuvre.

Bien que vous ayez raison de dire qu’il n’est pas toujours possible d’envoyer des répliques complètes au serveur pour des jeux complexes, vous pouvez utiliser un système similaire en demandant régulièrement au serveur de demander au client une partie de son état, le jeu est en cours d'exécution.

Par exemple, dans une FPS, à chaque minute, vous pouvez demander "Combien de tues tues?", "Où sont tous les ennemis?", Etc. Si le client ne revient pas avec une réponse raisonnable à un défi quantité raisonnable de temps, ils trichent.

Bien sûr, cela ne fonctionne que si le jeu est en ligne pendant toute la session. Étant donné que l'objectif ici est de pouvoir publier dans un classement en ligne, je pense que c'est raisonnable: ne jettez pas le joueur hors du jeu s'il répond mal, ne le laissez pas simplement sur la liste des scores.

Je vous encourage cependant à reconsidérer l’envoi de répliques. Tout ce dont vous avez vraiment besoin est la graine aléatoire initiale et l’entrée horodatée. Cela devrait vraiment être quelques centaines de Ko au plus. Beaucoup de jeux d'arcade le font déjà pour sauvegarder des rediffusions à des fins d'examen par les joueurs; demander à votre serveur de les valider n’est peut-être pas anodin, mais cela évite tout type de tricherie, à l'exception du botting.

Vous pouvez limiter les abus les plus flagrants en surveillant les résultats les plus élevés dans le tableau des meilleurs scores. Selon votre jeu, vous pouvez avoir un "score parfait", au-dessus duquel tout score doit être frauduleux. Sinon, vous pouvez calculer le "score impossible" le plus bas; le joueur peut-il tirer 10 coups par seconde, la partie dure 1 minute et chaque ennemi tué vaut 100 points? Alors tout score supérieur à 60 000 doit être frauduleux.

Vous pouvez également contribuer à atténuer le problème en envoyant des métadonnées. pas l'historique complet du jeu, comme vous le décrivez, mais simplement les composants qui composent le score. Dites: 60000 ennemis, 500 tués et un objet bonus saisi. Vous pouvez ensuite effectuer des vérifications simples. C'est "la sécurité par l'obscurité" et donc pas du tout sécurisé, mais cela permet d'éliminer les attaquants les plus naïfs.

En fin de compte, vous ne pouvez exclure que des scores incroyablement élevés, car les autres sont (par définition) simplement invraisemblables et pourraient donc constituer un joueur légitime (et génial).

Sinon, vous devez vous appuyer sur des techniques d’obscurcissement (telles que le cryptage et l’envoi d’autres statistiques au-delà du score).

Vous pouvez également envoyer le score périodiquement au cours de la partie, ce qui ajoute un niveau de complexité supplémentaire à la triche: le serveur peut décider si la partie a été jouée suffisamment longtemps pour justifier un score en particulier, et pour garantir un nombre suffisant de rapports intermédiaires. ont été reçus pendant le temps de jeu (mais ne le faites pas à 100% sinon le train qui passe dans un tunnel sur le chemin du retour me fera jeter le téléphone par la fenêtre).

En fin de compte, quelqu'un trouvera le moyen de le résoudre, alors ne vous tuez pas en essayant de les en empêcher.

J'ai ajouté un tableau des meilleurs scores rapide / sale à un de mes projets il y a quelque temps et ne connaissant pas du tout la sécurité Internet, etc. Étonnamment, avec près de 1 200 000 scores enregistrés, je n'ai eu que 5 ou 6 occasions de lots de scores manifestement incorrects atteignant le sommet du tableau. La plupart des scores ressemblaient même plus à un problème dans le jeu qu’à un véritable "piratage".

Donc, je suppose qu’un point important est le suivant: assurez-vous que le système de notation de votre jeu est hermétique , ou au moins effectuez une très bonne vérification de la faisabilité du score; maintenant, ce jeu dont je parle était une entrée de Ludum Dare 48h, donc ce n’était pas la chose la plus stable qui soit. mais dans l’ensemble, je pense qu’il est souvent plus probable que le joueur occasionnel découvre / exploite un problème technique, avoir quelqu'un directement "pirater" le classement.

Cela dit, je travaille actuellement sur une réécriture de ce projet, et je vais tout faire avec l’obscurcissement. Je n’entrerai pas dans les détails, mais en gros, tous les scores soumettront une valeur de clé basée sur un ensemble de valeurs aléatoires et de hachage, ainsi que sur une chaîne magique, puis tous les scores qui réussissent cette vérification et sont suffisamment élevés pour rendre le résultat réel " Le classement "Top X" doit passer par un autre cycle de validation (cette fois avec une valeur de clé expirante générée sur le serveur et des contrôles de faisabilité plus approfondis).

Je vous conseillerais également d'utiliser un traceur de paquets pour tester les éléments visibles (au départ, je procédais à une vérification beaucoup plus simple: quelqu'un pouvait utiliser un traceur de paquets pour rechercher et dupliquer la requête http d'une partition téléchargée, sans le savoir la chaîne magique ou quoi que ce soit (cela signifiait que vous deviez d'abord obtenir un score légitime, mais vous pouviez envoyer des copies de ce score autant que vous le souhaitiez ..)). J'ai utilisé Wireshark pour tester cela.

Euh, cela s'est avéré un peu long, mais j'espère que cela aide ...

Je ne suis pas un expert dans ce domaine mais si j'étais vous, je vais essayer de chiffrer le score avec une clé intégrée dans le code. Ces personnes devront appliquer l'ingénierie inverse sur votre code au lieu du texte brut utilisé pour les services Web.

Les Speedruns enregistrent essentiellement toutes les frappes au clavier, et ils enregistrent un jeu ENTIER. Donc, oui, vous pouvez enregistrer le jeu entier, ce n'est pas infaisable. Toute autre manière de le faire est fissurable par le biais de la rétroingénierie (je ne saurais trop le souligner: vous n’ajoutez pas de sécurité, vous ajoutez de l’obscurité).

Pourtant, même si vous le faites de cette manière, ils pourraient en réalité soumettre un speedrun. Vous ne pouvez rien faire pour empêcher cela.

Pendant que vous y êtes, il faut se demander si un score élevé est simplement un joueur qui a trouvé un exploit (par exemple, si certaines choses dans le jeu donnent lieu à une pénalité de score et qu'un bogue provoque le "bouclage" d'un score négatif devenir très positif ... ou simplement un joueur qui trouve une certaine condition de jeu, comme un endroit sûr sur le tableau où il peut rester assis sans avoir à s'inquiéter de perdre indéfiniment).

Afin de faire la différence entre un exploit et un exploit, il serait bon de télécharger au moins quelques données de jeu. Cela vous aidera à réparer les exploits, au moins.

Pour certains jeux (en particulier ceux au tour par tour), vous pouvez jouer au jeu via le serveur, où toute la logique de jeu existe côté serveur et où le client n'est qu'une interface. Cela rend non seulement le piratage de score beaucoup plus difficile, mais vous permet également de consigner de manière triviale toutes les actions des joueurs sur le serveur, et ainsi de rejouer n'importe quel jeu à tout moment. Je réalise que pour quelque chose comme un jeu de tir à l’assaut, cela pourrait ne pas être pratique.

Créez toutes les origines aléatoires d'une graine et stockez l'entrée pour chaque image. Chaque fois que vous revendiquez un score élevé (par exemple 50 premiers), envoyez la graine et l'entrée complète au serveur. Rejouez le jeu sur le serveur et mettez à jour le classement si vous obtenez un score élevé.

Si vous considérez que cela est impossible pour des jeux plus sophistiqués en raison de la taille de la demande, regardez cet exemple.

Disons que le jeu dispose de 8 boutons (1 pad et 4 boutons) et tourne à 60 images par seconde. Une entrée de jeu d'une heure peut être transmise avec 3,6 Ko sans compression. Votre session durera probablement moins d'une heure et la compression devrait en être considérablement réduite, car la contribution de l'utilisateur est très redondante.

Le défi consiste à rendre le jeu déterministe, jouable à partir d’une entrée enregistrée et exécutable sur le serveur.

Jamais implémenté cela auparavant mais ...

Envoyer les scores progressivement avec les horodatages. Cela vous donne un journal pour voir combien de fois le score s'est amélioré ainsi qu'un moyen de suivre le "momentum" du meilleur score.

Vous définirez ensuite les jalons / critères pour vos scores.

Par exemple: Un score supérieur à 20 000 ne peut pas arriver dans les 20 premières secondes d'un match. Un score supérieur à 250 000 ne peut pas arriver sans une entrée supérieure à 200 000.

Ce n’est pas exactement la même chose que d’envoyer un état de jeu, mais presque.

Avantage secondaire: Pensez à toutes les statistiques utiles que vous obtiendrez de cette manière. Quelqu'un pèserait bien pour ça.