Un essai pour éviter la triche pour les jeux en javascript

[Sephi-Chan]

Bien sûr, Javascript sert alors (comme il se doit, à mon sens) à rendre le rendu plus agréable.


Sephi-Chan

[Talus]

je met ma petite graine ici (désoler du déterrage ^^)

Il existe l'APE, Ajax Push Engine (http://www.ape-project.org/)
qui permet d'avoir du JS coter server, ce framework permet entre autre de faire du Data Streaming, du bon vieux temps réel a l'affichage


il y a la fois du JS cotee client, pr l'affichage et les requête server,mais il y a du JS cotée server pour tout ce gui est gestion des requête


après si tu veux empêcher le joueur de tricher tu a plusieurs petite astuce
par exemple le score tu le stock en plusieurs valeur :
le modulo du score et le reste du modulo

ou bien tu associe le score avec son MD5 comme sa tu vérifie l'integritee des data a la réception serveur

ou bien tu applique un petit algo d'encodage (Xor, Décalage de bit) a tes data pour empêcher le joueur de savoir réellement a quoi correspondent les valeur


je suis en stage dans une boite qui dev des jeux web et ce sont des solution qu'ils utilisent fréquemment

[Sephi-Chan]

je met ma petite graine ici (désoler du déterrage ^^)

Il existe l'APE, Ajax Push Engine (http://www.ape-project.org/)
qui permet d'avoir du JS coter server, ce framework permet entre autre de faire du Data Streaming, du bon vieux temps réel a l'affichage


il y a la fois du JS cotee client, pr l'affichage et les requête server,mais il y a du JS cotée server pour tout ce gui est gestion des requête


après si tu veux empêcher le joueur de tricher tu a plusieurs petite astuce
par exemple le score tu le stock en plusieurs valeur :
le modulo du score et le reste du modulo

ou bien tu associe le score avec son MD5 comme sa tu vérifie l'integritee des data a la réception serveur

ou bien tu applique un petit algo d'encodage (Xor, Décalage de bit) a tes data pour empêcher le joueur de savoir réellement a quoi correspondent les valeur


je suis en stage dans une boite qui dev des jeux web et ce sont des solution qu'ils utilisent fréquemment

Hélas, il n'y a pas de solution à ces problèmes : dès lors qu'il y a un transfert de données du client vers le serveur, ces données peuvent être falsifiée. Même si tu génères une empreinte pour ces données, le tricheur n'aura qu'à générer l'empreinte des données falsifiées.

Tu peux mettre des bâtons dans les roues de tes tricheurs, mais rien de simple pour empêcher les triches côté client. Ainsi, sans un contrôle draconien côté serveur (qui aurait un coût monstrueux en terme de ressources), tu ne peux pas déceler les triches discrètes.

Imagine que tu fasses un tower defense multijoueurs, il est difficile de mettre en place des contrôles de triches (vérifier pour chaque tir de tourelle si la tourelle avait bien la portée pour toucher tel monstre et si les dégâts correspondent). Le seul moyen fiable est de jouer la partie côté serveur et de produire l'affichage côté client, mais la latence que ça induit peut rendre ça pénible pour le joueur.


Pour ce qui est du serveur de push, je n'ai jamais aimé leur API et encore moins leur documentation : j'utilise donc Juggernaut (et il y en a d'autres très bons). Il est bâti sur NodeJS (en Javascript aussi, donc) et fonctionne avec Redis pour le messaging : deux logiciels libres éprouvés, donc robustes. De plus, Redis sert à bien d'autres choses quand on développe un jeu !

[Maks]

Je suis surement naïf, mais je me pose une question : pour tricher côté client, comment vous-y prendreriez-vous ?
Executer du code javascript depuis la console ? Ce qui nécessite d'avoir accès au nom des variables, pas évident une fois minifié non ?

[Sephi-Chan]

C'est sûr que ce n'est pas facile, et c'est encore plus difficile si le développeur utilise des variables locales dans des closures (donc qu'il limite l'utilisation de globales) rend ça encore plus difficile (puisqu'on n'arrive pas à y accéder depuis la console). Mais ça reste néanmoins possible.

L'autre approche est de ne pas modifier le jeu mais seulement ce qu'il envoie au serveur. Pour ça, on peut charger un script de notre cru qui va qui va surcharger les méthodes d'envoi de requêtes asynchrones pour en altérer les données.

[Talus]

il y aussi le "Cheat Engine"
qui permet de modifier la memoir cotée client, ca permet de tricher dans tout type de jeux (executable)
et même avec des jeux flash

je pense que ca peut aussi s’appliquer au jeux web hors flash

[Angelblade]

Tu peux minifier le code sur une seule ligne, certains compresseurs vont même renommer tes variables en a,b,c,d...
En supplément certain proposent même un base64_encode sur tes noms de variables pour être bien relou.

Tout ça rend ton code très obscur mais on pourras toujours réussir à en extraire un sens et le manipuler. Moi je ferais un peu comme sephi: je me concentrerais sur la partie qui communique avec le serveur (composé en fait de peu de ligne de code).
Il est donc assez rapide de trouver ce qui est important, et, si ce n'est pas sécurisé, d'en profiter.

Cependant si t'a multiplié les barrières c'est une grosse prise de tête et faudrait vraiment que ça en vaille la peine.

De toute façon comme on a aucun contrôle sur ce qui se passe coté client il faut considérer que tout peut être faux.
Pour moi les actions du client doivent être listés et les conditions de ces actions revérifié en permanence.

[niahoo]

J'utilise require.js ce qui fait que pratiquement la totalité de mon code se passe dans des closures, il ne reste que 3 globales : $, _ et Backbone

[Angelblade]

Les closures ça rendras juste l'exploitation moins évidente.

[niahoo]

Et bien tu parlais justement de multiplier les barrières non ?