CRYPTER VOS CLASSES : CHARGEUR DE CLASSES CRYPTÉES !

Commentaire de GodConan le 02/12/2003 23:48:18

dit dc heureusement que g toujour eclipse sur moi ;o)  :  c chian tous c repertoire ;o) et pis moi g pas de var classpath sur ma machine ...
sa ser a rien ;o) G 3 JDK en ligne ;o) héhé...

autrement c pas mal ton source ;o) pour voir comment fonctionne un class loader car il existe deja pas mal de chiffreure de class ;o) gratuit.. ;o)

++

Commentaire de GodConan le 03/12/2003 01:33:02

;o) moi c tou les matin 6h ;o)
pis te cas pas pour le projet eclipse ;o) i en a pas besoin ;o) ...
sa ce fait en 3 secondes ... par contre ;o) moi j enleve tou les package a cause de toi (ton premier post sur ma source...) ;o) héhé ;o) car jadore sa aussi ;o) mais fo reconnaitre c qd meme plus simple a compiler qd on use seulement javac ... ;o)

bn
++

Commentaire de bax1982 le 14/12/2003 15:07:10

Hehe, ca a l'air pas mal, mais il ne faut pas oublier que malgré tous les efforts qu'on peut faire pour crypter le fichier .class, en utilisant le chargeur de classe adapté pour charger les classes cryptées, il est toujours possible de regénérer les fichiers .class originaux, non cryptés, et de les décompiler en code java clair ... Evidemment, cela demande un minimum de connaissances en java, mais toute personne normalement constituée et capable d'écrire un classloader doit être capable de décompiler les classes meme les mieux cryptées s'il possède le classloader sans réécrire l'algorithme à l'envers ...


bonne continuation
@++

Commentaire de bax1982 le 16/12/2003 22:59:42

Même avec un classloader en JNI,  cela ne pose aucun problème à partir du moment ou il est possible de l'utiliser pour charger la classe. Il suffit d'utiliser la librairie BCEL du projet jakarta (http://jakarta.apache.org) qui permet de dumper une classe chargée en mémoire.
Mais, et sur ce point, tu as tout à fait raison, à partir du moment ou le code est "brouillé" par un obfuscator, il devient vite compliqué de comprendre quelque chose à un code ne fut-ce qu'un tout petit peu complexe. Et là, je pense qu'aucun programme ne peut être capable de regénérer des noms de variables sensés et cohérents ...

@++

Commentaire de bax1982 le 17/12/2003 19:28:19

C'est un projet mené par l'Apache Software Foundation qui reprend une série de sous projets liés au langage Java. La librairie BCEL est un de ces sous projets qui permet de manipuler les classes Java, les méthodes et les propriétés sous la forme d'objets, de façon un peu plus poussée qu'à l'aide de la Reflection API. Si le sujet te passionne, sache également qu'il existe une autre librairie avec le même genre de fonctionnalités et qui a l'air plus rapide que BCEL (à ce que disent les développeurs de cette deuxieme librairire), il s'agit d'ASM chez ObjectWeb (http://asm.objectweb.org/), et il en existe encore une troisième, c'est SERP (http://serp.sourceforge.net).

Il ya moyen de faire des trucs techniquements géniaux avec ça, il reste juste à trouver une idée intéressante.

Voilà voilà, amuse toi bien ;-)

@++

Commentaire de guillaume_master le 06/01/2004 21:05:24

j'ai une question ! Le loader il est obligé d'être en .class ? donc on peut décompiler le loader, donc on peut connaitre l'aglo de décryptage ? donc on peut décrypter le .caesar donc on peut avoir le code source !

donc ... ca sert à rien ?

Commentaire de guillaume_master le 07/01/2004 00:52:34

ok ca me confirme dans ce que j'ai compris (pardon pour la redondance). J'ai pas trop compris le coup de l'obfuscator, je vais bosser ca. En fait moi perso, j'essaye de trouver un moyen de cacher mon code et de faire un logiciel absolument in-crackable. Je viens de delphi et la à mon avis y a rien à faire. Alors que en java on peut peut etre utiliser le cryptage ou bien ce fameux obfuscator pour planquer le code. V bosser un peu et je reviendrais ;-)

merci bcp et pardon pour la redondance de ma remarque

Commentaire de Backslash le 07/01/2004 20:10:36

Des dé-obfuscators ??? Je n'avais jamais entendu parler de ça !!! Et comment ces dé-obfuscators font ils pour regénérer des noms de variables compréhensibles et surtout cohérents ... ???
Le code passé dans un obfuscator est compréhensible si ta classe est ultra simple. (genre tout en une classe et pas plus compliqué qu'une petite calculatrice .. ok) :-p
Mais si tu as une application bien structurée avec des dizaines (voir meme des centaines ou des milliers de classes) avec des dépendances dans tous les sens, si tous ces noms de classes, tous leurs attributs et leurs noms de méthodes sont renommés en quelque chose du style "aXpq7bv" je me demande comment tu fais pour y comprendre quelque chose ...

Pour ton idée de logiciel incrackable ... Je crois que c'est utopique d'imaginer quelque chose d'incrackable ... Si quelqu'un est suffisamment doué pour faire quelque chose de très solide, il existe quelqu'un d'autre (ou un groupement d'autres) qui sera encore plus fort pour refaire la même chose à l'envers ou pour trouver un système qui permet de contourner la difficulté.

Je pense qu'actuellement la meilleure façon de protéger sa "logique" est de la faire tourner chez soi, la ou les utilisateurs n'y ont pas accès. Néanmoins, je peux t'assurer que l'open source a fait ses preuves et que jusqu'ici c'est comme ça que les softwares se développent le mieux. Je ne veux pas ici relancer le débat entre linux et windows, ni entre les logiciels propriétaires et l'open source. Si je participe à cette discussion sur ce site, c'est parce que le projet fait intervenir d'intéressantes notions autant au point de vue technique  java (reflection etc ...) qu'au niveau théorique et mathématique (crypto and co ...). Je ne pense pas que ce projet soit réellement utile mais je le trouve très intéressant parce qu'il fait intervenir ces notions qui me plaisent beaucoup. Une entreprise privée qui développe des logiciels de vraiment bonne qualité (j'en connais !) pourraient voir une utilité à crypter leur code pour protéger leurs secrets de fabrication, mais comme je disais, une fois que la logique tourne, il est facile de suivre en mémoire ce qui se passe, dans certains cas des notions d'assembleur sont nécessaires, en Java, c'est beaucoup plus simple puisqu'une fois qu'une classe est chargée elle peut etre dumpée en clair. Si une protection doit etre mise en place pour ça en Java, je pense que c'est dans la machine virtuelle qu'elle doit être implémentée.

Voilà,

Bien à vous, ...

Commentaire de guillaume_master le 08/01/2004 01:31:00

Oui c'est un sujet trés intéressant le débat sur l'Open Source et la propriétaire. Sinon un site trés intéressant sur les obfuscateurs :

http://www.semdesigns.com/Products/

on peut choisir un langage de prog et ca donne des exemples avant et aprés le brouillage.

Sinon, dans le cadre d'un code se voulant propriétaire, mon idée est de déporter une partie du code fonctionnel du programme sur un serveur.

A+

Commentaire de neodante le 09/01/2004 10:18:37 administrateur CS

Salut GodConan,
simplement pour cacher l'algo génial que tu veux vendre et breveter : en attendant les sous pour le faire ... c'est pas très Open Source mais combien de fois t'ais tu fais 'emprunter' des bouts de codes pour un autre projet par kk1 d'autre sans un petit mail au moins : merci ça coûte pas cher !
Mais au fond le cryptage du code n'est vraiment vrai que pour les très gros projets qui deviennent alors vraiment incompréhensible à moins de passer des jours à essayer de remettre le code debout en redéfinissant toutes les variables et en sachant ce qu'elle signifie !
@+

Commentaire de neodante le 07/03/2005 13:17:34 administrateur CS

Je viens de trouver un article qui explique un peu pourquoi l'obfuscation n'est pas (toujours ...)  une solution :
http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?
Je voulais en faire profiter à tout le monde !

@+