Est-ce que vous masquez votre code Java commercial ?[fermé]

Question

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 comportait en fait une étape obscurcissante dans l'étape de construction des fourmis pour les versions.

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

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

modifier: Ok, pour être précis sur mon point :Faites-vous de l'obscurcissement pour protéger votre propriété intellectuelle (vos algorithmes, le travail que vous avez consacré à votre produit) ?Je ne vais pas dissimuler pour des raisons de sécurité, cela ne me semble pas bien.Je parle donc uniquement de protéger le code de vos applications contre les concurrents.

@staffan a un bon point :

La raison pour laquelle il faut éviter de chaîner le flux de code est que certains de ces changements empêchent la JVM d'optimiser efficacement le code.En effet, cela dégradera les performances de votre application.

Answer 1

Si vous faites de l'obscurcissement, éloignez-vous des obfuscateurs qui modifient le code en modifiant le flux de code et/ou en ajoutant des blocs d'exception, etc., pour rendre difficile son démontage.Pour rendre le code illisible, il suffit généralement de modifier tous les noms des méthodes, champs et classes.

La raison pour laquelle il faut éviter de modifier le flux de code est que certains de ces changements empêchent la JVM d'optimiser efficacement le code.En effet, cela dégradera les performances de votre application.

Answer 2

Je pense que l'ancienne méthode (classique) d'obscurcissement perd progressivement de sa pertinence.Parce que dans la plupart des cas, un obfuscateur classique brise une trace de pile (ce n'est pas bon pour supporter vos clients)

De nos jours, l’essentiel n’est pas de protéger certains algorithmes, mais de protéger une donnée sensible :Connexions/mots de passe/clés API, code responsable des licences (piratage toujours là, en particulier Europe occidentale, Russie, Asie, à mon humble avis), identifiants de compte publicitaire, etc.

Fait intéressant:nous avons toutes ces données sensibles dans Strings.En fait, les chaînes représentent environ 50 à 80 % de la logique de nos applications.Il me semble que l'avenir de l'obscurcissement réside dans les "outils de chiffrement de chaînes".

Mais désormais, la fonctionnalité « Chiffrement de chaîne » n'est disponible que dans les obfuscateurs commerciaux, tels que : Allatori, Maître de classe Zelix, Écran de fumée, Boîte à outils d'obscurcissement Java Stringer, DashO.

N.-B.Je suis PDG de Licel LLC.Développeur de Stringer Java Obfuscator.

Answer 3

J'utilise proguard pour le développement JavaME.Ce n'est pas seulement très très efficace pour réduire la taille des fichiers jar (Essential pour mobile), mais c'est aussi un moyen plus agréable de créer du code spécifique à un appareil sans recourir à des outils de prétraitement hostiles à l'IDE 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");
    }
}

Ceci 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");
}

Vous pouvez ainsi disposer de variantes de code pour contourner les bogues du fabricant dans les implémentations de JVM/bibliothèque sans alourdir les fichiers de classe exécutables finaux.

Je pense que certains obfuscateurs commerciaux peuvent également fusionner des fichiers de classe dans certains cas.Ceci est utile car plus vous avez de classes, plus la taille du fichier zip (jar) est importante.

Answer 4

J'ai passé du temps cette année à essayer différents obfuscateurs Java, et j'en ai trouvé un qui avait une longueur d'avance sur les autres : JBCO.Il est malheureusement un peu lourd à mettre en place et n'a pas d'interface graphique, mais en termes de niveau d'obscurcissement qu'il produit, il est sans précédent.Vous essayez de lui alimenter une simple boucle, 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 des goto ?Eh bien, la JVM les prend en charge =)

Answer 5

j'utilise ProGuard et je le recommande vivement.Bien que l'obscurcissement protège votre code des attaquants occasionnels, son principal avantage réside dans l'effet minimisant de la suppression des classes et des méthodes inutilisées et du raccourcissement de tous les identifiants à 1 ou 2 caractères.

Answer 6

Je pense que pour la plupart, l'obscurcissement est inutile :même avec le code source complet, il est généralement assez difficile de comprendre quelle était l'intention (en supposant qu'il n'y ait pas de commentaires ni de noms significatifs pour les variables locales - ce qui est le cas lors de la régénération des sources à partir du code d'octet).L'obscurcissement ne fait que décorer le gâteau.

Je pense que les développeurs et en particulier leurs managers ont tendance à exagérer considérablement le risque que quelqu'un voie le code source.Même si de bons décompilateurs peuvent produire un code source joli, il n'est pas anodin de travailler avec lui, et les coûts associés (sans parler des risques juridiques) sont suffisamment élevés pour rendre cette approche rarement utile.J'ai uniquement décompilé pour déboguer des problèmes avec les produits des fournisseurs de sources fermées (blocages dans la couche d'abstraction de la base de données, pouah).Le bytecode était en fait obscurci, je pense, mais nous avons néanmoins trouvé le problème sous-jacent : il s'agissait d'un véritable problème de conception.

Answer 7

Je suppose que cela se résume vraiment à quoi votre code Java est destiné, comment il est distribué et qui sont 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 qu’il n’en vaut la peine.Si quelqu'un a accès à nos fichiers JAR et possède les connaissances nécessaires pour pouvoir les renifler, il peut alors faire des choses bien plus inquiétantes que d'arracher notre code source.