Est-ce que vous obscurcissez votre code Java commercial?

Je me demande si quelqu’un utilise des obfuscateurs java commerciaux / gratuits sur son propre produit commercial. Je ne connais qu’un seul projet qui a eu une étape obscure dans l’étape de la construction de la fourmi pour les versions.

Est-ce que vous obscurcissez? Et si oui, pourquoi vous éclatez-vous?

Est-ce vraiment un moyen de protéger le code ou est-ce juste un meilleur sentiment pour les développeurs / gestionnaires?

edit: Ok, pour être précis sur mon propos: Est-ce que vous obscurcissez pour protéger votre IP (vos algorithmes, le travail que vous avez mis dans votre produit)? Je ne vais pas obscurcir pour des raisons de sécurité, cela ne semble pas correct. Je ne parle donc que de protéger le code de vos applications contre les concurrents.

@staffan a un bon point:

La raison de ne pas enchaîner le stream de code est que certaines de ces modifications empêchent la JVM d’optimiser efficacement le code. En fait, cela va réellement dégrader les performances de votre application.

Si vous ne le faites pas, éloignez-vous des obfuscateurs qui modifient le code en modifiant le stream de code et / ou en ajoutant des blocs d’exception, afin de le rendre difficile à démonter. Pour rendre le code illisible, il suffit généralement de modifier tous les noms de méthodes, champs et classes.

La raison de ne pas modifier le stream de code est que certaines de ces modifications empêchent la JVM d’optimiser efficacement le code. En fait, cela va réellement dégrader les performances de votre application.

Je pense que l’ancienne manière (classique) de l’obscurcissement perd progressivement de sa pertinence. Parce que dans la plupart des cas, un obfuscateur classique brisant une trace de stack (ce n’est pas bon pour supporter vos clients)

De nos jours, le point principal est de ne pas protéger certains algorithmes, mais de protéger des données sensibles: identifiants / mots de passe / clés API, code responsable des licences (piratage toujours en Europe occidentale, Russie, Asie, IMHO), .

Fait intéressant: nous avons toutes ces données sensibles dans Ssortingngs. En fait, Ssortingngs représente environ 50 à 80% de la logique de nos applications. Il me semble que l’avenir de l’obscurcissement est «Outils de chiffrement de chaînes».

Mais maintenant, la fonctionnalité de “cryptage de chaîne” est disponible uniquement dans les obfuscateurs commerciaux, tels que: Allatori , Zelix KlassMaster , Smokescreen , Ssortingnger Java Obfuscation Toolkit , DashO .

NB Je suis PDG chez Licel LLC. Développeur de Ssortingnger Java Obfuscator.

J’utilise proguard pour le développement JavaME. Il est non seulement très efficace pour réduire la taille des fichiers jar (Essential pour mobile), mais il est également très utile pour créer du code spécifique à l’appareil sans avoir recours à des outils de prétraitement peu conviviaux tels que l’antenne.

Par exemple

public void doSomething() { /* Generated config class containing static finals: */ if (Configuration.ISMOTOROLA) { System.out.println("This is a motorola phone"); } else { System.out.println("This is not a motorola phone"); } } 

Cela est compilé, obscurci et le fichier de classe se termine comme si vous aviez écrit:

 public void doSomething() { System.out.println("This is a motorola phone"); } 

Ainsi, vous pouvez avoir des variantes de code pour contourner les bogues du fabricant dans les implémentations JVM / bibliothèque sans décomposer les fichiers de classes exécutables finales.

Je pense que certains appareils de communication commerciaux peuvent également fusionner des fichiers de classes dans certains cas. Ceci est utile car plus vous avez de classes, plus la taille que vous avez dans le fichier zip (jar) est grande.

Cette année, j’ai passé du temps à essayer divers obfuscateurs Java, et j’en ai trouvé un de plus que JBCO . C’est malheureusement un peu lourd à mettre en place et sans interface graphique, mais en termes de niveau de brouillage, il est sans précédent. Vous essayez de lui fournir une boucle simple, et si votre décompilateur ne plante pas en essayant de le charger, vous verrez quelque chose comme ceci:

  if(i < ll1) goto _L6; else goto _L5 _L5: char ac[] = run(stop(lI1l)); l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL; if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$) { l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL; } else { for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L) { for(int j = III; j < ll1; j++) { l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L; l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L; l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L; l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL; l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L; if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L)) { l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL; } } } } 

Vous ne saviez pas que Java avait un goto? Eh bien, la JVM les supporte =)

J’utilise ProGuard et le recommande vivement. Bien que l’obscurcissement protège votre code contre les attaquants occasionnels, son principal avantage est de minimiser l’effet de la suppression des classes et des méthodes inutilisées et de raccourcir tous les identificateurs à 1 ou 2 caractères.

Je pense que la plupart des obscurcissements sont inutiles: même avec le code source complet, il est généralement assez difficile de comprendre ce que l’intention était (en supposant qu’il n’ya pas de commentaires et pas de noms significatifs pour les variables locales). -generating sources from byte code). L’obscurcissement ne fait que décorer le gâteau.

Je pense que les développeurs et surtout leurs gestionnaires ont tendance à exagérer considérablement le risque que quelqu’un voit le code source. Bien que les bons décompilateurs puissent produire un code source intéressant, il n’est pas sortingvial de travailler avec lui, et les coûts associés (sans parler des risques juridiques) sont suffisamment élevés pour que cette approche soit rarement utile. Je n’ai décompilé que pour déboguer les problèmes avec les produits des fournisseurs à source fermée (blocages dans la couche d’abstraction de la firebase database, ugh). Je pense que le bytecode était en réalité obscurci, mais nous avons néanmoins trouvé le problème sous-jacent – c’était un problème de conception réel.

J’imagine que cela dépend vraiment de la nature de votre code Java, de sa dissortingbution et de l’identité de vos clients. Nous ne dissimulons rien, car nous n’en avons jamais trouvé un qui soit particulièrement bon et cela a tendance à poser plus de problèmes que sa valeur. Si quelqu’un a access à nos fichiers JAR et a les connaissances nécessaires pour pouvoir les détecter à l’intérieur, alors il peut faire bien plus de choses que d’extraire notre code source.