Java vs memory editing

Version imprimable

14/04/2007, 10h44
orelero

Java vs memory editing

Salut,

Je sais pas si l'intitulé est parlant mais vous allez comprendre de quoi je voulais parler à cette adresse :
http://www.softcows.com/memory_editor_faqs.htm

où l'on peut lire :

Citation:

Q: Is Quick Memory Editor able to cheat Java games on the internet?
A: Yes, just select Internet Explorer or whatever your browser is, as the game and search as you normally do, then cheat.

J'ai essayé et ça marche bien :roll: .

Y a t'il un moyen de prévenir ce genre de modification, par exemple déjà au niveau des accesseurs ?

Merci.
14/04/2007, 11h52
the-gtm

Manifestement ça accède directement la mémoire, donc à mon avis les accesseurs ou la visibilité des variables n'ont rien à voir là dedans.

De toute façon si quelqu'un veut tricher sur un jeu en Java, il peut le lancer en debug et il aura accès à toute la pile.
14/04/2007, 12h11
TabrisLeFol

De toute facon cela ne remet rien en cause.

La meilleure hypothèse pour un logiciel sécurisé est qu'il ne faut pas faire confiance au client, ainsi toutes les données critiques doivent etre stockée sur le serveur.

Une autre solution (je ne sais pas comment marche ce logiciel) serait de crypter les données de la meme facon que flash. Mais bon comme c'est pas fait à la base par java, si c'est possible cela doit etre tres lourd. Le mieux reste le serveur.

Apres cette facilitée à tricher et lier au fait que l'utilisateur arrive a determiner quelle memoire correspond a quoi. Selon le jeu, tricher est donc plus ou moins facile. Si le jeu repose sur des variables dont l'utilisateur n'a pas conscience cela sera plus dur pour lui de tricher.
Ex : Si l'or est affiché, il sera relativement facile pour l'utilisateur de retrouver la memoire associée.

Une solution assez efficace mais ralentissant le jeu est de creer des codes de verifications. Du genre MD5 et en cas de non conformité arréter le jeu. Cela est vraiment efficace pour tester si les fichiers de données ne sont pas corrompus/modifiés. L'application à la mémoire implique que ce code soit recalculé de nombreuses fois... (On pourrait envisager un code par objet. )
14/04/2007, 15h18
orelero

Citation:

La meilleure hypothèse pour un logiciel sécurisé est qu'il ne faut pas faire confiance au client, ainsi toutes les données critiques doivent etre stockée sur le serveur.

En fait c'est un jeu multijoueur en développement depuis 1 an et je vais faire une sorte de beta test d'ici à deux mois. Je commence à penser aux façons de tricher.
Pour les données critiques toutes les données critiques sont gérées par le serveur. Le seul problème c'est qu'il est toujours possible d'altérer certaines variables en mémoires qui servent à redessiner certains graphismes et en particulier la droite qui matérialise la ligne de visée du joueur. Pour un jeu similaire en flash, il m'avait suffit de changer la valeur d'une variable pour que cette ligne de visée soit infinie (pour trouver l'adresse de la variable il a juste fallu repérer son adresse dans le source).
Peut-etre que la création d'un objet encapsulant ces variables rendrait dynamique cet adressage ?

Citation:

Une solution assez efficace mais ralentissant le jeu est de creer des codes de verifications. Du genre MD5 et en cas de non conformité arréter le jeu.

oui ou alors vérifier la valeur du hashcode des objets critiques et là si non conformité je mets le joueur sur la liste noire.
14/04/2007, 16h50
the-gtm

A mon avis tu perds ton temps, si quelqu'un a envie de tricher en manipulant le client, tu n'as aucun moyen de l'en empêcher. Le coup de la mémoire cryptée, ça ne sert à rien puisqu'il faut que le client ait la clé pour fonctionner. Et s'il a la clé c'est comme si ce n'était pas crypté.

Si tu mets des contrôles d'intégrité, il va décompiler ton code, le lancer en debug et voir comment ça marche. Il n'aura aucun mal à désactiver la fonction censée le mettre sur liste noire.

Il faut trouver un compromis entre le temps que tu passes à prévenir la triche et le nombre de tricheur que acceptes de laisser passer.
14/04/2007, 17h02
orelero

Citation:

Si tu mets des contrôles d'intégrité, il va décompiler ton code, le lancer en debug et voir comment ça marche. Il n'aura aucun mal à désactiver la fonction censée le mettre sur liste noire.

justement pour les contrôles d'intégriter, je fais aussi exécuter au client du code distant dans certains cas. J'essaye donc de jouer sur le fait que le tricheur ne peux pas comprendre le code ainsi exécuté en un temps trés court. C'est sûr que ça mange de la bande passante mais si je le fais seulement en cas de suspicion ça devrait aller.
Si jamais le client repère la commande servant à ce genre de contrôle et stope la connection dés qu'il y a un contrôle, je le mets sur la liste noire.
16/04/2007, 12h59
Desboys

Bonjour,
s'il s'agit effectivement d'un jeu de type MMOG, ceci m'inquiète.

Citation:

Envoyé par orelero

Le seul problème c'est qu'il est toujours possible d'altérer certaines variables en mémoires qui servent à redessiner certains graphismes et en particulier la droite qui matérialise la ligne de visée du joueur. Pour un jeu similaire en flash, il m'avait suffit de changer la valeur d'une variable pour que cette ligne de visée soit infinie (pour trouver l'adresse de la variable il a juste fallu repérer son adresse dans le source).

Si j'ai parfaitement compris et déduit le fonctionnement de la "ligne de visée", cela correspond au champ de vision environnant le joueur? Mais ne doit-on pas calculer ceci dans le serveur en envoyant un message au client lui disant:" Tiens, voici ce que tu vois " ?

S. Desbois
17/04/2007, 17h23
orelero

non en fait c'est un jeu "semi temps réel" où l'on peut tirer sur ses adversaire. On est repésenté par un tank et lorsque l'on veut visée, il y a cette ligne de visée qui prolonge le canon de la tourelle (pour aider à viser).