Bin oui pourquoi ? Et puis pourquoi "idiot" après tout c'est une bonne idée : ça augmente le challenge entre les gens, entre amis, bref ça donne envie de jouer pour donner à tout plein d'entreprises aux bonnes intentions ses coordonnées, qui elles ont le droit à un jeu où le score compte : celui qui aura la plus grosse base CRM gagne.
Et après tout on en a vu des jeux qui se basent sur le score ou le classement, et ça fonctionne très bien, comme Tower Bloxx sur facebook, ou encore La Brute[*] des excellents et prolifiques Motion Twin.
Peut-être, vous rétorquerais-je vaillamment, mais remarquez qu'aucun des deux n'offre de lots pour appâter plus de joueurs encore.
Alors pourquoi ?
Mais parce que ça se pirate trop facilement ma bonne dame !!
Vous allez me dire - si si, je vous ai vu pouffer - qu'on s'en fout parce que ce sont de grosses boites qui ont les moyens d'offrir des lots. Et c'est vrai, et en prime l'essentiel est que les gens s'inscrivent pas que ce soient les vrais gagnants qui gagnent.
Mais tout de même,ça la fout mal pour l'image d'une boite d'être à l'origine d'une injustice flagrante, contrairement à l'image d'un gouvernement si j'en crois les sondages.
Ah ah ah, moi je les ai eu, j'ai fait mon jeu en flash, comme ça y'a plein d'animations et puis c'est un fichier SWF qu'on peut pas lire et modifier avec notepad.[**]
Bravo ! Bien joué... vous avez réussi à trouver un dev' Flash en cette période de disette je vous félicite. Mais concernant vos certitudes je me vois dans l'obigation d'y mettre un frein.
Non, notepad n'aidera effectivement pas mais certains outils [1 - 2] vont permettre au pékin moyen doté de deux sous de jugeote et trois de technique de lire votre SWF comme dans un livre ouvert. Un livre de développeur ActionScript mais un livre tout de même.
Il existe quand même ce qu'on appelle des obfuscateurs de code qui permettent de foutre un bordel monstrueux dans le code source. C'est un ralentisseur efficace pour les intrus mais le code est encore valide et un peu de patience permet de le remettre en place. De plus, ce qu'un programme a pu faire, il est possible qu'un autre programme le défasse. Cela peut marcher un temps donc.
Pour plus d'info sur le sujet voici un article technique intéressant (mais pas spécialisé ActionScript).
Bon allez, je vous l'accorde, vous avez réussi à produire un code difficile à lire - peut-être même que votre dev AS ne l'a même pas fait exprès ^_^. Vous pensez être sorti d'affaire ? Mais votre jeu il tourne sur l'ordinateur de votre client. Il utilise donc son processeur... sa RAM... et s'il voulait les modifier ?
Oh mais c'est des trucs compliqués tout ça et puis j'ai même pas compris tous les termes. Ma cible n'a pas ce niveau et n'en pannera pas plus que moi de ce charabia.
C'est compliqué ? Oui, comme tout en informatique, mais il y a toujours des petites feignasses qui se créent des outils pour automatiser les trucs chiants. Et à la fin tout le monde peut les utiliser, c'est magique. La preuve en vidéo et en langue anglaise avec un outil au nom si équivoque : Cheat Engine.
Oh allez, je vous l'accorde avec du temps et plusieurs techniques vous pouvez commencer à rendre le code plus dur à trafiquer, en copiant plusieurs version en mémoire avec des codages différents, et des vérifications.
ex. je place à dans plusieurs variables le score : l'une normale, pour être lue rapidement, l'autre hashée avec un md5 et une troisième avec un sha1, et mélangez le tout et vous vérifiez de temps en temps. Vous obtenez, en utilisation conjointe avec un obfuscateur, un truc peut être pas impossible à pirater mais au moins assez chiant pour que ce soit rédhibitoire.
J'ai précisé un peu plus haut "avec du temps"... et oui mettre en place tout ça prend du temps et parfois l'achat d'autres logiciels. Votre projet, si c'est une opération évènementielle, peut prendre au moins 20% d'augmentation sur le développement du front et tout ça sans aucune garantie d'infaillibilité.
Oui mais moi je m'en fiche parce que mes score sont récupérés et stockés sur le serveur et que là y'a personne qui peut voir le code et la base. Ah ah T'es bien niqué là !
Puisque tu veux me filsdeputiser, je vais ramener mon pote Charles, qui est vachement fort parce que tout ce que mon ordinateur va envoyer sur ton serveur, bah il va tout me dire. TOUT ! L'extension HttpFox sur Firefox fait de même. Et j'ai même appris, pour mes recherche sur cet article, qu'un autre extension, TamperData de modifier ces informations en léger différé à l'aise.
Autant vous le dire, votre serveur on peut lui dire ce qu'on veut et il n'aura quasi aucun moyen de vérifier quoi que ce soit. Je peux me faire passer pour qui je veux, faire passer les informations que je veux. La principale règle de sécurité que devrait suivre tout développeur serveur c'est de ne jamais croire sur parole ce qu'il reçoit de l'extérieur. (cf. cet excellent document sur la sécurité que j'oblige les stagiaires dev' à lire avant de dev du PHP ave moi)
Ah, je sais ! On va crypter les données en MD5 avec flash qu'on décryptera sur le serveur. (l'idée est de @mathomate, qui n'est pas dev' mais possède tout de même un cerveau, sur un de nos projets commun, et la citation n'est pas ultra précise :))
Là il y a de l'idée ! Bon par contre le MD5 ne se décrypte pas.
Il existe de nombreuses façon pour découvrir ce qui se cache derrière un code md5 mais il n'est pas fait pour ça, de même que SHA1. Ces des méthodes font ce qu'on appelle un hashage, qui sert à calculer un vérificateur. Par exemple, je stocke dans une base mon mot de passe en hashé en MD5, et puis quand on m'envoie un mot de passe, je le code à son tour en MD5 et je vérifie la concordance. Cette opération n'est donc pas réversible sinon il suffirait d'accéder à la base pour connaitre tous les mots de passe.[***]
Mais gardons l'idée avec le cryptage RSA. Pour résumer, sinon je vous invite à aller voir sa page Wikipedia, il permet de coder une chaine de caractères que seul le destinataire sera capable de décoder. Pour cela le destinataire envoie des codes, des clés publiques, qui vont permettre à l'émetteur de coder son contenu. Mais il garde de son coté, et ne le prête à personne comme un sale gamin avec sa pelle toute neuve, une clé privé lui permettant le décodage. Parfait ?
Bah non justement, notre problème n'est pas l'écouteur - le serveur - mais l'émetteur - joueur ou pirate. Si la clé publique est envoyée alors mon pote Charles va le savoir, et alors plus de soucis pour encoder les données comme le serveur les attend avec impatience et lui envoyer.
Seul inconvénient pour le tricheur : encore faut-il savoir ce qu'il faut envoyer et sous quelle forme. Et là c'est le code inclut dans le SWF qui devrait donner la réponse.
Mais si on utilise toutes ces méthodes à la fois, ça va être hyper chiant pour le pirate, juste pour gagner une machine à café, j'veux dire c'est pas un peu disproportionné ?
Pour une machine à café oui, mais pour un voyage, une voiture[****], ou d'autres choses qu'on peut avoir en incentive. Et puis pour un no-life spécialisé là dedans les outils automatisés existent et accélèrent le processus.
Toutefois Il est vrai que tous ces procédés mis bout à bout rendent le piratage assez fastidieux. Mais pas impossible !! C'est là où je voulais en venir !
Et puis je le rappelle, pour des opérations évènementielles dont le budget est souvent limité pour le dev' justement, en imputer autant sur la sécurité c'est en prendre au développement du jeu et donc risquer d'être moins efficace sur sa ludicité et donc sur son coté viral. Même si l'incentive est là, un mauvais jeu aura moins de succès qu'un bon.
Bon d'accord, je ne vais pas faire de jeu mais un blog avec des vidéos virales.
Mais non faut pas dramatiser comme ça. Et puis vous déformez mes propos. Je n'ai aucunement dit qu'il ne fallait pas organiser de jeux à lots...mais qu'il ne fallait pas baser la distribution des gains sur le score.
Faites donc un bon tirage au sort des familles parmi tous les participants ! Un huissier c'est tout de suite beaucoup plus dur à pirater.
L'autre solution, évoquée plus haut, est celle de La Brute, où tout est basé sur le serveur. Les actions de l'utilisateur sont envoyées au serveur et c'est lui qui calcule le résultat. C'est moins pratique voire improbable pour les jeux d'action, de vitesse ou de réflexes mais cela permet un système de scores plus sain.
À vous de voir maintenant mais vous serez prévenu.
[*] Pour la petite histoire, je tenais farouchement contre vents et coups de tatannes mon classement de 500e, sur le nombre de joueurs total c'est pas mal, en allant jouer tous les jours lorsque qu'un jour un célèbre opérateur de câble français décida de me priver de mon droit fondamental à l'information pendant une semaine. J'ai abandonné le jeu après ça.
[**] Je n'ai pas vraiment d'interlocuteur réel, et mes autres personnalités sont bien plus malignes que ça, c'est pour le coté didactique que j'ai inventé un dialogue voyons !
[***] La vérité, en plus d'être ailleurs, est beaucoup plus subtile que ça, et ces codes restent piratable et de toute manière quelqu'un qui accèderait à la base serait maitre des données qui s'y trouvent.
[****] J'ai pas eu de voiture à faire gagner encore. ;)
2 réponses sur « Pourquoi est-ce idiot d’organiser un jeu concours à lots basé sur le score ? »
Nous on se contente d’enregistrer la totalité des actions réalisées côté client en BDD. Le moindre clic est enregistré en BDD en ajax. À la fin nous sommes capable de rejouer toute la partie originale ce qui nous permet de voir comment a fait l’heureux gagnant. Qu’en pensez-vous ?
Ce que j’en pense c’est qu’à la fois c’est une autre bonne idée pour brouiller les pistes, et qu’en plus j’imagine que vous l’avez assez testé pour en être contents – et je n’imagine même pas vous donner des leçons de développement de jeux. :)
Toutefois j’y vois quelques limites d’après mon expérience :
– j’ai peur de mettre à genoux mon serveur – n’y vois aucune allusion sexuelle hein ! – avec un trop grand nombre de requêtes. J’ai beau conseiller de passer par Lixium ou Galacsys pour l’hébergement – je n’en fais pas ce n’est pas mon métier et j’y connais que le strict minimum – on me répond souvent qu’un OVH suffira… et là c’est souvent le drame surtout si le jeu a du succès.
– Ça ne se prête pas à tous les jeux : d’une part à cause du soucis ci-dessus (j’imagine sur un shoot’em’up, de logguer toutes les frappes de touches) et d’autre part car cela réduit l’utilisation d’IA avec actions aléatoires, ou alors il faudrait envoyer leurs décisions au serveur, ça fait encore beaucoup d’infos à envoyer.
– C’est faisable pour LE gagnant mais récemment on m’a demandé un jeu avec un tirage au sort parmi les 100 meilleurs scores. *sic*
– Sauf à lire les informations de log comme les techniciens dans Matrix, j’imagine qu’il faut prévoir un simulateur ou alors il existe un outil dont je n’ai pas connaissance permettant de simuler les touches via un script ? Mais même avec un simulateur, vérifier les parties pour les valider prendra surement un peu de temps. (d’un stagiaire sous-payé, soit ^_^ )
– Enfin, les informations de clics sont bien envoyées à votre serveur, et ça il est possible de le reproduire. Il est donc possible à un individu farouchement motivé – oui parce que là j’avoue quand même qu’avec toutes les solutions évoquées on est un peu comme dans le sketch de la chauve-souris enragée de Bigard – de préparer un nombre d’actions vraisemblables simulant un clic, des temps de lancement, puis d’envoyer toutes ces informations au rythme voulu via un script maison. C’est techniquement imaginable, donc faisable, donc le système n’est malheureusement pas totalement infaillible.
Donc j’ai quand même l’impression que ça demande du temps, pour un résultat pas entièrement certain. Non ?
Mais bon, je dois quand même avouer qu’on commence à s’approcher d’une limite où le rapport temps de piratage/gains s’étiole un peu.