Discussion :

[Pecose]

Bonjour tout le monde,
Je voulais savoir si il y a un moyen de protégé son code de l'introspection.
J'ai glané moults notes sur les internets disant tout et l'opposé, mais surtout l'opposé.
Certains parles de SecurityManager et d'autres qu'il est simple de le désactivé.
J'aimerai bien savoir utiliser ce "SecurityManager" mais je ne sais pas par ou commencé.
Je n'ai pas trouvé de tutoriels suffisamment clair pour comprendre quand on a pas compris.
C'est quand-même fou qu'un outil destiné au gens qui n'on pas compris, soit écrit de manière que l'on ne comprenne pas,
sauf quand on à déjà compris... allez comprendre.
Si vous avez d'autres idées je suis preneur.
Merci de votre aide.

[wax78]

Une méthode peut être, (trouvée sur internet en 5 secondes mais je ne suis pas certains que ça soit une bonne idée de mettre cela ainsi en place.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import java.lang.reflect.Field;
 
public class ExtSecMan extends SecurityManager
{
	int value;
 
	public static void main(String[] args) throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException
	{
		// Disallow access to package java.lang.reflect
		System.setSecurityManager(new ExtSecMan());
 
		ExtSecMan a = new ExtSecMan ();
		a.value= 33;
 
		Field f = a.getClass().getDeclaredField("value");
 
		Object val = f.get(a);
		System.err.println("Val = "+val);
 
	}
 
	@Override
	public void checkPackageAccess(String pkg){
		// don't allow the use of the reflection package
		if("java.lang.reflect".equals(pkg))
			throw new SecurityException("Interdit!");
 
    }
}

[adiGuba]

Salut,


De quoi tu veux te protéger exactement ?

[Pecose]

Merci, mais qu'es ce que c'est que ce truc?
C'est quoi "antiref"?

adiGuba: Je veux me protéger de la modification par introspection mal intentionné de variables que j'aimerai voir privés.

[adiGuba]

Oui mais tu veux te protéger de quoi exactement ?
Qui utiliserait l'introspection et dans quel but ?

Sans contexte c'est difficile de t'aider...

[Pecose]

Imaginons que je veuille faire un jeu multijoueur.
Je construit mon jeu de manière à créé un équilibre délicat entre tout les joueurs de même niveau.
Cette équilibre repose sur des variables dont le joueur à accès uniquement par l'intermédiaire des règles établies.
Je met donc mes variable en "private" voir même "final" pour en garantir l'inviolabilité. FAUX!
Quand le monde entier te persécute, il y a forcément un gars qui va faire un plugin pour modifier cette foutu variable.
Répète après moi hu-hu-hu-hum: Hakuna Matata.

[adiGuba]

Donc tu veux te protéger des utilisateurs de ton application.

Alors le SecurityManager n'est pas forcement adapté.
C'est plus fait pour protéger l'utilisateur que l'inverse...
Ce serait plutôt utile pour un système de plugins que tu mettrais en place... Mais cela pourrait facilement être "contourner" par l'utilisateur.

Et il y a d'autre technique qui pourrait passer outre cela, comme l'accès direct à la mémoire...

Pour un jeu multijoueur je dirais de ne pas faire confiance aux données envoyées par les joueurs.
Si tu es en clients/serveur, alors ce dernier devrait être chargé des règles du jeu.
Si tu es en P2P, alors chaque client devra vérifier les données des autres clients...


Mais tu ne pourras pas proteger complètement ton application de l'utilisateur...

[Pecose]

C'est différent dans d'autres langages ou pas?

[wax78]

Merci, mais qu'es ce que c'est que ce truc?
C'est quoi "antiref"?

Autant pour moi j'ai oublier de renommer cette classe, j'ai corrigé l'erreur.

Pour le reste je rejoinds AdiGuba.

[adiGuba]

C'est différent dans d'autres langages ou pas?

Non pas vraiment...

Ce n'est pas un problème de langage.
L'utilisateur est maître de sa machine et pourra tenter de compromettre ton appli. A moins de maîtriser complètement l'administration de la machine, tu ne peux pas avoir confiance aux données envoyées par un client ...

[thelvin]

Reconnaissons quand même que la bonne construction solide de l'architecture Java, fait qu'il est facile d'étudier ses composants et ce qui a été produit avec/ce qui fonctionne avec. Cela en fait une cible particulièrement facile pour l'ingénierie inverse qui consiste à prendre un programme et à étudier/espionner son fonctionnement ou son contenu. Alors que cela est bien plus compliqué avec le bazar difforme produit pour être exécuté nativement par un processeur x64.

Du coup des langages comme le C/C++ produisent des programmes moins faciles à espionner.

Mais bon, sur le plan théorique, c'est pour tout le monde pareil. Le problème est que la donnée que tu veux cacher à ton utilisateur, se trouve sur un ordinateur qui appartient à ton utilisateur, pas à toi. Son ordinateur ne va pas te rendre de comptes, il va lui obéir à lui.

[adiGuba]

Du coup des langages comme le C/C++ produisent des programmes moins faciles à espionner.

Oui et non.

Au niveau du langage et du fonctionnement même de Java il y a des choses qui serait plus simple à faire, mais c'est largement faisable avec les autres langages et les bons outils...

=> L'introspection permet de modifier des valeurs private au sein du même programme.
Avec du C/C++ ou d'autre programme natif on utiliserait un debuggeur pour acceder à la mémoire et éventuellement la modifier... à partir d'un autre programme !
Il y a plein d'outils système pour ça (comme ptrace()), et probablement plein de logiciels prêt à l'emploi.

La grande majorité des jeux ne tournent pas sous Java, pourtant il existe des systèmes de triches pour bon nombre d'entre eux...

[thelvin]

Je dis juste que c'est plus facile en Java. Ça se remarque par exemple parce que tu n'as pas besoin d'autre outil que ton IDE et le décompilateur qui vient avec. C'est quand même vraiment une barre très basse pour celui qui veut venir bricoler le programme sur lequel il a mis la main.

Comme tu le dis, dans les autres langages, il y a besoin des "bons outils". Il faut comprendre ce qu'ils sont, les trouver, et les prendre en main. Et les décompilateurs sont particulièrement mauvais, ou disons simplement qu'ils font ce qu'ils peuvent, ce qui n'est pas brillant. On n'y peut rien, c'est l'architecture native et du langage qui font ça.