Une protection de code révolutionnaire?!?

Un peu long, mais pour ceux qui s'intérresse à la protection du code
source, ça mérite une lecture attentive

En faisant des recherches sur l'obfuscation, et la protection de
code source java en général, je suis tombé sur le site de JEncoder
(http://www.new-era-soft.com).

J'ai été intéressé et intrigué par leur solution pour le moins
originale. Je leur ai demandé plus d'info en vue d'en savoir plus et
de vous en faire profiter. Sur ma demande il m'ont fournit un texte
assez technique (et surtout pas trop marketing) exposant le principe
général, les conditions de mise en œuvre de leur solution.

J'ai traduit ce texte pour ceux qui sont vraiment allergique à
l'anglais. Vous avez ma traduction puis la VO, plus bas.

La solution semble réellement séduisante, bien plus que
l'obfuscation. J'attend maintenant votre avis sur cette technique.

PS : Ça ressemble à de la pub, mais mon but c'est simplement de
discuter avec vous de quelque chose qui semble très intéressant.
Après, selon vos avis, cette information se transformera en
avertissement ou en bon tuyau.

****************************************************************
****************************************************************
Avertissement: il s'agit de ma traduction. L'original est en bas de
mon post.

D'ailleurs si il y a des erreurs grossières ne vous gênez pas pour
"patcher"…

Date: 22 Juillet 2003

Sujet: Spec Technique de JEncoder 3.70

Présenté par New Era Soft (http://www.new-era-soft.com)

1) Jencoder est un outils conçu pour protéger les applications Java
de la décompilation (Reverse-Engineering)

2) L'idée de base utilisée par JEncoder est la suivante:

a. Prendre une application java normale et crypter ses classes en
utilisant un mot de passe (fournit par le propriétaire de
l'application) comme clé privé de l'algorithme de cryptage.

b. Sauver les classes cryptée dans un fichier jar.

c. Créer, en plus de la classe cryptée, une librairie dynamique
native (DLL sous Windows) contenant les informations permettant de
décrypter les classes cryptées. (Cette librairie est distribuée comme
partie intégrante de l'application cryptée).

d. A l'exécution, décrypter les classes cryptées et les charger en
mémoire.

3) La version actuelle de JEncoder peut seulement crypter les
applications (java). Dans un future proche, JEncoder sera capable de
crypter aussi les Applets et les Servlets.

Dans la mesure où un accès a une librairie native est nécessaire
pour utiliser les classes cryptées, quand les applets seront
supportées, un certificat sera nécessaire pour utiliser les applets
cryptées. (Un certificat est une confirmation que l'utilisateur doit
accepter pour autoriser un processus à s'exécuter via un navigateur
internet. Dans le cas présent, il devra accepter d'utiliser la
librairie native de JEncoder).

4) La version actuelle de JEncoder ne peut crypter les applications
que pour les systèmes d'exploitation Windows et Solaris. Dans le
futur, New Era Soft à l'intention de supporter d'autres systèmes
d'exploitations (comme Linux, Web Logic, IBM, Mac Os X, etc.).

5) JEncoder s'exécute sous Windows, et il nécessite un JDK 1.3 ou
plus pour s'exécuter.

JEncoder nécessite aussi les droits d'Administrateur pour
s'installer et s'exécuter sur votre ordinateur.

Ces contraintes ne s'appliques pas aux application cryptées (celle
qui ont été crypté par JEncoder), leurs contraintes sont les mêmes
qu'avant cryptage. La seule contrainte supplémentaire est qu'il faut
un JDK1.2 ou plus (JDK 0 ou 1 ne fonctionneront pas avec les
applications cryptées par JEncoder).

6) Bien qu'on pense généralement que quelque soit ce qui entre dans
la machine virtuelle Java cela peut être lu par n'importe qui, et bien
que les applications cryptées par JEncoder utilise une machine
virtuelle standard, il n'est pas possible de récupérer le byte-code
des classes cryptées par JEncoder.

Les ingénieurs de New Era Soft on trouvé une technique spéciale et
originale qui protège contre la récupération du byte-code chargé.

7) Dans la mesure où les classes d'une application cryptée doivent
être décryptées durant l'exécution (avant la "résolution" de la
classe), il faut plus de temps pour les charger que dans l'application
originale.

Le délai supplémentaire est pour chaque classe (utilisées par
l'application, évidemment), mais seulement une fois (puisque chaque
classe n'est chargée qu'une fois en mémoire).

Le code de description des classes étant natif, et le délai
supplémentaire ne s'applique qu'une fois, le coût est négligeable.

New Era Soft a effectué des tests sur de nombreuses applications
pour tester ce point, et ils ont constaté que le temps de chargement
d'une application cryptée est presque le même que le temps de
chargement de la même application non cryptée.

En fait, comme le temps de chargement des applications est affectée
par d'autres choses (comme l'état des autres processus sur la machine
durant le chargement), il est presque impossible d'attribuer la perte
de temps au chargement au fait que l'application est cryptée.

*******************************************************************
*******************************************************************
Date: July 22, 2003.

Subject: JEncoder 3.70 – Technical spec.

Presented by New Era Soft (http://www.new-era-soft.com)

1) JEncoder is a tool designed to protect Java against
Reverse-Engineering (decompilation).

2) The basic idea used by JEncoder is this:

a. Take a regular java application and encrypt its classes using a
password (supplied by the owner of the application) as a private key
for the encryption algorithm.

b. Write the encrypted classes into a jar file.

c. Along with the encrypted classes create a native dynamic library
containing the information of how to decrypt the encrypted classes.
(This library will be distributed as a part of the encrypted
application).

d. In runtime, decrypt the encrypted classes and load them into
memory.

3) The current version of JEncoder can encrypt only java
applications. In the near future, JEncoder will be able to encrypt
also Java Servlets and Applets.
Since a native is needed for using enrypted classes, when applets will
be supported, a certificate will be needed for using encrypted
applets. (A certificate is a confirmation that the user must accept
for allowing a process to continuing through a web-browser. In our
case the user will have to accept using JEncoder's native library).

4) The current version of JEncoder can encrypt applications only for
Windows and Solaris Operating Systems. In the future, New Era Soft
intends to enable other Operating Systems (such as Linux, Web logic,
IBM, Mac Os X, etc.).

5) JEncoder is running on Windows OS, and needs JDK1.3 or higher to
run.
JEncoder also needs Administrative rights to be installed and run on
your computer.
These requirements do not apply on the encrypted applications (that
were encrypted by JEncoder), and their requirements depend on the
original requirements of the application. The only additional
requirement, is JDK1.2 or higher (JDK 0 or 1 will not work with
JEncoder's encrypted applications).

6) Despite the fact that it is considered to be thought that
whatever enters the Java Virtual Machine can be seen by anyone, and
despite the fact that applications that were encrypted by JEncoder use
a standard Java Virtual Machine, it is still not possible to retrieve
the bytecode of classes that were encrypted by JEncoder.

New Era Soft engineers have found a special and unique technique
that prevents getting the bytecode of classes that were loaded.

7) Since the classes of an encrypted application need to be decrypted
during runtime prior to the class resolving process, it takes more
time to load them than in the original application.

The delay is for each class (that is actually used by the
application), but only once (since each class is loaded once into
memory).
Since the code that decrypts the classes is written in native code,
and the delay is only once for each class, the overhead is redundant.

New Era Soft has performed tests on several applications to test
this issue, and found that the loading time of an encrypted
application is pratically the same as the loading time of the same
application when it is not encrypt.

As a matter of fact, since the loading time of applications is
affected by other things (such as the state of other processes on the
machine at the time of loading), it is almost impossible to attribute
the time delay of the loading to the fact that the application was
encrypted.