Discussion :

[ghiwani80]

Bonjour
je travaille sur application un peu "sensible" et le client souhaite protéger le code source et éviter le décompilation des classe.

le projet est composé de deux sous-projets
+1) XXXCore.jar (spring hibernate): c'est le projet à obfusquer
+2)XXXWeb.war (interface web JSF): (pas besoins d'obfusquer).

le XXXCore sera inclut dans le lib du war.

seul le projet core a obfusquer.

- quelqu'un à déjà travaillé sur projet identique?
- quelqu'un aurait dans ces carton des doc pour l'obfuscation (proguard ou autre) en français de préférence?
- ou y a t'il moyen d'obfusquer tous le war.

merci d'avance

le XXXWeb dépend du core, la communication se fait par des appel service via une factorySpring

exemple
dans mon bean (UtilisateurBean)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public void login(...){
   ....
   ....
 IUtilisateurService userService = (IUtilisateurService) (MyServiceFactory.getInstance()
                    .get(IUtilisateurService.INSTANCE_PROXY_NAME));
 
  UtilisateurDto dto = userService.login("ghiwani", "password2010");
 
....
...
 
}

[Jimmy_]

Bonjour,

Quelqu'un pourra toujours décompiler le code et si le jeu en vaut la chandelle il pourra reconstituer un code source lisible.
Il faut obfusquer assez pour rendre ce travail plus cher que le gain espéré quand à l'obtention du code source.
Par contre je vois qu'il y a un login ... par expérience on n'obfusque jamais ce type de code. Toute sécurité par l'obscure est mauvaise.

[ghiwani80]

le projet core contient un code qui vérifié une licence.
une fois le projet livré chez "les clients de mon client", la vérification se fera en local en se basant sur un algorithme nomMachine, date, ....

donc mon client veut obfusquer ce bout de code

[Jimmy_]

Ok je vois dans ce cas pas trop le choix.

voici un tuto : http://cyberzoide.developpez.com/securite/obfuscation/


Mais de toute manière il y aura forcement quelqu'un qui va s'atteler à ce travail.
Les meilleures protections que j'ai vu dans ce domaine étaient redondantes et dispersées un peu partout dans le code.
Si bien que même si on parvenait à en comprendre une partie, il en restait une autre qui prenait le relais plus loin...

Ce que je veux dire, c'est qu'il faut non seulement obfusquer le code, mais en plus insérer dès la conception des leurres et des vérifications supplémentaires. Ne pas uniquement se reposer sur l'obfuscation.

Bon courage,

[ghiwani80]

ok merci,
je regarde, mais à premier vue, c'est que du java, je ne sais pas trop comment le war vas ce comporter puisque toutes les classe seront renommées en a.a.a.a.a...

je fais le tuto et je vous fais un retour.

merci bcp

[ghiwani80]

Re:
ce tuto explique juste le principe, auriez-vous un autre qui montre comment le mettre en pratique sur un projet .

merci d'avance

[yaraco]

Non, dsl. La documentation Proguard et quelques tests suffisent normalement.

Pense à ne pas obfusquer les noms de packages et les noms de classes que tu charges dynamiquement dans le code (si jamais tu as du code de ce type).

Et n'obfusque pas non plus les noms menant au point d'entré de ton programme (ton main).

Autre chose que tu pourras mettre en œuvre mais qui te demanderas un peu plus de temps : un ClassLoader personnalisé. Tu peux par exemple stocker ton code obfusqué dans un conteneur crypté avec à côté un ClassLoader de ton cru capable de d'explorer ce conteneur. C'est toujours pas ultime mais ça rajoute une petite couche de casse tête supplémentaire aux éventuels méchants pirates.

[ghiwani80]

holaaaa ça se complique là.

si j ai bien compris, proguard (l obfuscation) transforme le code avant compilation, ce qui va me rendre la tache très difficile puisque mon projet XXXCore contient des fichiers xml (spring et hibernate).

auriez-vous un autre moyen pour protéger le code ?

merci d'avance.

[tchize_]

les obfuscateur travaillent souvent après la compilation, en faisant plusieurs choses:

1) changer l'ordre d'instructions indépendantes en bytecode, pour que ça ne ressemble plus à la manière dont est habituellement traduite telle ou telle instruction

2) changer les noms des méthodes et des classes, sauf celle que tu as explicitement indiqué vouloir garder claires (histoire de permettre la visibilité de l'api publique de ta librairies)

3) Souvent, ça joue avec des noms de classes bizarres, comme A et a, qui sont différente, mais chiantes à sortir du jar sous une environnement windows (même non, avec casse différentes, windows il aime pas)


Comme dit, pour que l'obfuscation serve à quelque chose, il faut aussi que ton code vérifie la licence à plein d'endroits de manière différentes. Si tu fais un méthode générique du style isLicenceValid(), j'aurais vite fait de rajouter dans ton spring une couche de aop et de redéfinir cette méthode à la volée par return true