Bonjour à tous,
J'aimerai savoir si il est possible de récupérer le bytecode (byte[]) d'une classe au runtime (ceux qu'on utilise dans un classloader.defineClass) à part un hack de la jvm.
Le but est de protéger le code d'une décompilation.
Merci
Version imprimable
Bonjour à tous,
J'aimerai savoir si il est possible de récupérer le bytecode (byte[]) d'une classe au runtime (ceux qu'on utilise dans un classloader.defineClass) à part un hack de la jvm.
Le but est de protéger le code d'une décompilation.
Merci
Tu n'arrivera pas à protéger grand chose ainsi, je pense. Ce que tu cherche à faire c'est charger une classe à partir d'un tableau de byte non, cela est faisable, il faut que tu regare au niveau de ClassLoader, je crois même qu'il y en a déjà des personnalisé ( comme charger les données au dessus du réseau ).
Le but est effectivement de protéger les classes en chargeant les bytes soi même. Ne pas donner accès aux .class directement me semble un bon point de départ (en particulier utiliser un classLoader natif).
Mais une fois le binaire chargé dans la jvm, si il est possible d'y accéder d'une façon ou d'une autre (genre Class.getBytes) cette protection n'est pas utile en l'état car on peut injecter un code qui récupère au runtime le bytecode.
Donc est il possible d'accéder au bytecode une fois chargé dans la jvm (au runtime)?
Il y aura une partie qui chargera ta classe, je pense que tu es bien d'accord la dessus. Si ce code est écrit en java, et fait appel à une librairie native pour décoder. Il devient très facile de contourner cette protection : il suffit de coder une classe qui utilise tes méthode native : elle devra porter le même nom que ton code.
Ou encore changer le noms des méthodes aux sein de la librairie compilé.
Tu peut peut être appelé le class loader directement à partir du code natif, mais même dans ce cas je pense que le code peut être attrapé. Il y a notamment une API qui est sortie assez récemment : Instrumentation. Par ailleurs même du code natif peut être décompilé, si tu stock la clé dedans sous la forme d'un tableau d'octets, qui est utilisé par un algo tierce, le tableau pourra facilement être récupéré.
En voici un exemple d'utilisation :
http://today.java.net/pub/a/today/20...mentation.html
Bang :calim2: en plein dans le mile !
Donc on peut effectivement accéder au bytecode pendant le runtime.
De toute façon si la jvm utilisée est customisée pour récupérer le bytecode on ne peut rien n'y faire.
Il faut donc remonter jusqu'à la jvm elle même.
Ca veut dire :
-Certifier les arguments de la jvm
-Certifier le lanceur
-Certifier toutes les libs du classpath type jar
-Charger le classloader en natif (qui contient la clef de décryptage de nos classes)
-Décrypter nos classes
-Offusquer les parties natives.
C'est lourd.
Ca veut dire :
-Livrer une jvm certifiée avec notre code
-Ce qui n'est pas forcément possible pour des raisons de licences peut être (mac & solaris)
-Impossible d'utiliser une ide genre eclipse, netbean,... ou refaire un lanceur pour chaque (puisque le lanceur doit certifier un certain nombre de choses)
J'ai pas l'impression qu'il existe un outils comme ça ?
Salut,
Par curiosité : tu as quoi de si précieux à protéger ?
a++
Je pense que modifier la JVM pour que l'on puisse récupérer toutes les classes chargé est relativement simple à effectuer.
Citation:
Envoyé par adiGuba
Justement il ne va pas te le dire s'il veut le proteger ;) (je rigole)
C'est certainement top secret confidentielle...
une clé privée ? :p