Discussion :

[Jimalexp]

Salut,

Est-il possible d'empêcher ou limiter l'héritage d'une classe ?

Je voudrais savoir ce qu'il existe comme possibilités dans le cas où il voudrais éviter que des classes compilées soient "détournées".

Je sais qu'il est conseillé d'utiliser la keyword private et il y a peut être le mot final. Existe t-il des astuces en plus de cela ?

[natha]

Tu as tout dis, private, final.
Ensuite tu pourrais éventuellement inventer d'autres restrictions via les annotations et APT mais est-ce vraiment utile ?

[Jimalexp]

mais est-ce vraiment utile ?

Pas avec une application normale et ni dans un environnement sécurisé.

Disons que j'ai le projet de faire une petite application shareware et il serais intéressant d'avoir un mode sécurisé où certaines classes seraient vérouillées pour éviter qu'elles soient subtituées d'une manière ou de l'autre. Après ca, il reste le problème du bytehacking qui est plus délicat.

P.S: En effet, grâce aux annotations et l'introspection, il y a la possibilité d'ajouter des restrictions.

[natha]

Ah dans ce cas on dirait qu'il faut te tourner vers l'obfuscation de code. Il y a des obfuscateurs java gratuits et d'autres payant.
Demande à ton ami Google plus d'infos

[Redger]

Salut,

déclare une interface si tu veux empêcher l'héritage

fabrique un Singleton si tu veux une seule instance de ta classe (le constructeur est privé)

et pense à surcharger la méthode clone()

Code :

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

1
2
3
4
 
public final void clone() throws java.lang.CloneNotSupportedException {
     throw new java.lang.CloneNotSupportedException();
}

car elle permet de contourner tes constructeurs,

enfin çà dépend de ce que tu appelles "limiter"

[nabodix]

Je savais pas qu'il y avait moyen d'influer sur le nombre d'objets créé
Mais ca à l'air amusant comment tu fais (le Singloton) ?

En quoi la déclaration d'une interface va t'empêcher d'étendre la classe? (Par contre le modificateur final, pour une classe, empêchera celle ci d'être étendue..)

Pour clone(), j'y aurait pas pensé.. Mais en fait, il faut bien que la classe étende clonable, pour pouvoir cloner un object, non? Donc à quoi servirait de surcharger clone() ?
Si il y a des méthodes pour contourner ce problème, ca m'intéresse

Sinon pour le sujet premier du post, (vu que tu veux protéger ton code) je te conseil aussi de regarder du coté des obfuscateurs ==> http://java-source.net/open-source/obfuscators ou tu compile en natif avec gcj

[Jimalexp]

Je savais pas qu'il y avait moyen d'influer sur le nombre d'objets créé
Mais ca à l'air amusant comment tu fais (le Singloton) ?

Le singleton est un des design pattern gang of four (ensemble de solutions toute faites en programmation objet) : http://smeric.developpez.com/java/uml/singleton/

L'idée est simple sur papier :
- La classe comporte un attribut static du même type que cette classe.
- Les constructeurs sont tous privé ce qui bloque tout méssage d'instanciation extérieur.
- La seule manière d'obtenir une instance de cette classe est d'envoyer un méssage vers une méthode qui va soit créer une nouvelle instance et la stocker dans l'attribut mentionné ci-dessus ou renvoyer la référence s'il est non null. Par exemple la méthode getInstance() de la classe SingletonTest va renvoyer un seul objet SingletonTest.

Comme l'explique également la page de Sébastien Meric, l'instance unique n'est pas garantie lorsqu'on travaille avec des threads.

Sinon, concernant l'obfuscation, existe t-il des sites qui expliquent certaines techniques ? Je vais déjà regarder les projets open source mais ce serais bien de savoir ce qui est e plus courramment utilisé.

[Invité]

Comme l'explique également la page de Sébastien Meric, l'instance unique n'est pas garantie lorsqu'on travaille avec des threads.

Il y a un moyen de l'assurer en environnement multithread qui est de créer l'instance lors du chargement de la classe en mémoire. L'unicité est alors assurée par la spec de la JVM qui dit qu'une classe nest chargée qu'une fois, comme il est expliqué dans ce tutoriel : http://christophej.developpez.com/tu...n/multithread/

[anadoncamille]

Salut,

si tu veux empêcher des modifications de ton code après publication, équipe ton programme d'un algorithme qui empêche l'exécution de ton programme si l'intégrité des fichiers que tu veux protéger n'est pas respectée (tests de sommes de contrôle, reflets cryptés, etc...).

[Jimalexp]

Salut,

si tu veux empêcher des modifications de ton code après publication, équipe ton programme d'un algorithme qui empêche l'exécution de ton programme si l'intégrité des fichiers que tu veux protéger n'est pas respectée (tests de sommes de contrôle, reflets cryptés, etc...).

C'est pas bête du tout comme idée. J'avais déjà pensé à un genre de totalisateur qui symboliserais l'ensemble des méthodes dans une classe. Si une méthode se comporte de manière imprévue, cette variable pourrais servir d'indicateur.

J'aimerais en savoir plus sur l'idée des reflets cryptés.

[anadoncamille]

Salut,

les reflets cryptés sont une méthode de protection qui utilise une copie codée d'un fichier pour valider l'intégrité de ce dernier.

Tu as un fichier A dont tu crées une copie, rA. Ensuite tu cryptes ou non cette copie, le plus simple est de ne pas la crypter mais c'est moins sûr. Puis tu compares octet par octet A et rA en tenant compte du cryptage.
C'est une méthode que j'avais envisagé de développer mais que j'ai abandonnée pour des raisons de taille de projet (au minimum ça double la taille de tes données)

Les sommes de contrôle sont plus légères et sont très fiables.

[millie]

Salut,

si tu veux empêcher des modifications de ton code après publication, équipe ton programme d'un algorithme qui empêche l'exécution de ton programme si l'intégrité des fichiers que tu veux protéger n'est pas respectée (tests de sommes de contrôle, reflets cryptés, etc...).

Si la personne cherche déjà à modifier le code. C'est qu'il risque de décompiler le jar, du coup, supprimer la partie tests de la somme de contrôle risque d'être assez facile.

Donc du coup, je comprend pas trop ^o)

[nabodix]

Si la personne cherche déjà à modifier le code. C'est qu'il risque de décompiler le jar, du coup, supprimer la partie tests de la somme de contrôle risque d'être assez facile.

Ca c'est clair.. Mais il y a sans doute moyen d'inclure une partie dans le code principal à fin qu'il ne suffise pas de "bêtement" supprimer la classe qui bloque l'exécution..

Surtout si le code est obfusqué, ca ne facilitera pas la tâche du hacker.. mais c'est sur que ce n'est pas cela qui va l'arrêter.. (mais bon, je trouve le principe amusant , et relativement légé à mettre en œuvre.. )

[millie]

Surtout si le code est obfusqué, ca ne facilitera pas la tâche du hacker

Bah le truc, c'est que s'il a le courage de s'attaquer à du code obfusquer, supprimer la partie vérification que l'application n'a pas été trafiqué ou que trafiquer effectivement l'application va être au moins aussi dur. La seule chance, c'est d'espérer que la personne ne sache pas qu'il y a une sécurité... donc dans ce cas, risque de se casser les dents.

Donc, c'est pour ça que je comprend pas trop.


Soit d'un côté le code n'est pas obfusqué, donc facile à modifier, donc surement facile à supprimer la sécurité.
Soit d'un autre côté le code est obfusqué, donc difficile de modifier, et difficile de supprimer la sécurité (mais est-ce utile si c'est déjà difficile à modifier ?)

[nabodix]

En fait, ouais ...
C'est vrai que le type qui a passé autant de temps à comprendre le code, ne prendra pas plus de 5min pour retirer les instructions du genre :

Code :

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

1
2
 
if(!testSum()) System.exit(-1);

Sinon c'est drôle, pcq je suis entrain de "travailler" (depuis hier) sur un code qui à été obfusqué , et ca peut être assez casse c****** (mais bon, moi ca m'amuse .. pour le moment.. ), mais ce n'est clairement pas une sécurité suffisante..

[EDIT]:Si ca intéresse qq1, c'est cette applet (le graphisme foire sans doute un peu, mais ca ne change rien à la difficulté (pas énorme) de l'exercice.. ) Et sinon le reste du site est également divertissant..

[tchize_]

d'un point de vue algorithmique, si tu veux empecher l'héritage, c'est le final qu'il faut utiliser, avec tout ce qui n'est pas nécessaire en privé. Le reste c'est la question de l'environnement. Si tu veux empecher des scripts utilisateur de bidouiller tes sécurité par substitution, le securitymanager (empechant l'introspection) combiné aux regles ci dessus est suffisant.

si t'es coté client où du code pourrait etre injecté, il ne reste aucune solution 100% garantie.

[Jimalexp]

Si la personne cherche déjà à modifier le code. C'est qu'il risque de décompiler le jar, du coup, supprimer la partie tests de la somme de contrôle risque d'être assez facile.

Donc du coup, je comprend pas trop ^o)

C'est clair que si une personne est capable de, disons, modifier un test d'égalité (c'est ce qui serais le plus facile à identifier dans le bytecode), il pourrais en faire de même avec les tests de contrôle. Donc, les affectations en "clair" sont à proscrire.

Dans le même ordre d'idée que ce que propose anadoncamille (sauf que la reflexion est beaucoup plus puissante), j'avais pensé à une méthode "autotest" sans affectations qui redirige une série de méssages en entrée vers toutes les autres méthodes et qui les renvois immédiatemment ailleurs (un serveur ?) pour effectuer des comparaisons. Pour contrer ca, il faudrais modifier les jump et il y aurais peut être moyen de soulever des incohérences à ce niveau. Toutefois, je ne sais si ce serais réellement éfficace.

J'ai essayé de trouver des techniques existantes mais c'est difficile de savoir si elles sont applicables en Java. Par exemple, j'ai lu quelque chose à propos d'une "magic key" qui est générée au runtime et utilisée pour s'assurer que le côté client fonctionne comme prévu. Peut être que cette key est intégrée dans tous les méssages échangés avec le serveur.

Pour éviter la décompilation et donc l'accès au code, il y a l'obfusaction qui as déjà été citée ici. Il n'y a pas beaucoup de documentation sur les techniques utilisées mais il y a une approche qui consiste à introduire une série de jump et du code inutile pour essayer de tromper les décompilateurs. Il y a surement moyen d'en savoir plus en jetant un coup d'oeil sur des projets open source.

Finalement, l'idéal c'est que la JVM en elle même offre une possibilité de tester l'intégrité d'une class ou package. Un genre de checksum pourrais être encodé ou crypté à bas niveau.

si t'es coté client où du code pourrait etre injecté, il ne reste aucune solution 100% garantie.

C'est certain. L'idéal c'est de tendre à une solution qui rendrais la tâche difficile pour la majorité des utilisateurs.

[EDIT]:Si ca intéresse qq1, c'est cette applet (le graphisme foire sans doute un peu, mais ca ne change rien à la difficulté (pas énorme) de l'exercice.. ) Et sinon le reste du site est également divertissant..

Super intéressant ce site. Ce seras un excellent début pour en apprendre plus sur le cryptage.

[nabodix]

Super intéressant ce site. Ce seras un excellent début pour en apprendre plus sur le cryptage.

Content que ca te plaise .. Et il est vraiment chouette..

Sinon, pour le sujet principal, est ce que l'application pourra être en permanence connecté? Pcq si c'est le cas, comme le dis Jimalexp et en cherchant, il y a moyen de faire des truc bien plus secure encore!

[anadoncamille]

Salut,

effectivement, il n'est pas facile de dissuader un hacker de faire son oeuvre et s'il veut vraiment y arriver il sera difficile de l'en empêcher.

Dans mon projet, j'ai ajouté aux sommes de contrôle un simple algo d'auto-destruction. Si les sommes de contrôle sont invalides, le programme s'auto-détruit. Au moins ça fait ramer le hacker.

De plus mon code est truffé de messages explicites du genre "N'avez-vous rien de mieux à faire ?", "Une partie de jambes en l'air ne serait-elle pas plus jouissive ?", etc... Je n'ai pas de nom pour cet algorithme, c'est de la simple démoralisation et de la dissuasion psychologique.

Dans mon projet, j'utilise sans vergogne la dissuasion psychologique avec objectif explicite de faire péter un cable aux hackers potentiels. Dites-vous qu'un hacker se place lui-même hors-la-loi et qu'aucun recours en justice ne le protègera de ce qui peut lui arriver en dehors de la légalité. Je vois mal un hacker se plaindre au tribunal avec une plainte du style "j'étais tranquillement en train de pirater un logiciel quand toutes mes données ont été effacées."

[nabodix]

Héhé..
<anecdote>
ca me fait penser à Maxxuss qui, en hackant le code d'Apple est tombé sur quelques lignes poétique écrites par les informaticiens d'Apple visant à décourager quiconque de pirater leurs codes..
Mais apparemment, ca n'a pas suffit.. Maxxuss leur même répondu, à son tour, par un petit poème
</anecdote>


Mais si tu obfusque ton code (ce que je te conseille) d'une manière classique, je pense bien que toutes les lignes de codes seront retiré..