Discussion :

[Tymk]

Quel est l'interet d'obscurcir son code ? Il suffit de ne pas divulguer le code source et le programme sera protege.

[Médinoc]

Si tu parles de choses comme l'IOCCC, les gens font ça pour le fun, c'est tout.
Un code source obscurci n'a aucun intéret professionnel.

Par contre, en java et en .Net, le code compilé contient beaucoup plus d'informations permettant de le décompiler (par exemple, il contient les noms des classes et de leurs variables membres). Il est donc nécessaire d'obscurcir le code compilé pour ces plate-formes, si l'on veut protéger le code du reverse-engineering.

[JolyLoic]

Quand on livre une bibliothèque, on livre quand même pas mal de code, et quand c'est une bibliothèque templatée, c'est quasiment tout le code qu'on livre... D'où l'intérêt pour certains d'obscurcir. Je suis moyennement convaincu, je pense que ce genre de chose se règle avant tout au plan légal.

Pour les aspects .NET, je suggère Reflector pour voir ce qu'un quidam peut voir du code écrit.

[Laurent Gomila]

Personnellement j'ai récemment croisé un moteur physique (TrueAxis) complétement obscurci à base de macros et d'identificateurs bidons. La raison principale étant la flexibilité apportée par le fait que chacun peut recompiler lui-même le moteur sur sa propre plateforme avec ses propres options, sans pour autant avoir véritablement accès aux sources.

[koala01]

Salut,

Pour ce qui est du principe, il est simple: s'arranger pour rendre la lecture et la compréhension du code la plus compliquée possible de manière à éviter que des petits malins n'aillent (plusieurs possibilités possibles )

• récupérer une partie du code qui pourrait les intéresser
• détourner le code de son utilisation normal (correction de "bug" tels que le fait de rappeler qu'il faut acheter la licence après les trente jours d'essais)
• trouver les erreurs qui permettraient, en modifiant un peu le code, de s'ouvrir des voies d'accès à la faveur - par exemple - d'un stack overflow
• j'en passe, et de meilleures

La manière de s'y prendre est - elle aussi - relativement simple:

• utiliser des noms de variables qui ne sont absolument pas explicte (va savoir l'usage que l'on peut faire de l'entier xazerdf_ff )
• utiliser des noms de variables très proches, de manière à rendre plus compliquée la recherche (quand xazerdf_ff se trouve aux coté de xazerdf_fff, qui est en réalité le nom d'une fonction, retrouver les utilisations de la variable devient un véritable plaisir )
• utiliser un maximum de macro, aux noms les moins explictes possibles, et, tant qu'à faire, en ne respectant pas la "convention" qui veut qu'ils soient écrits en majuscules
• écrire plusieurs (toute les) instructions sur une seule ligne: la norme garantissant que les compilateurs qui la respectent sont capable de gérer des lignes composées de minium 65535 caractères, il y a de quoi faire
• préférer l'opérateur ternaire au bon vieux if...else
• j'en passe, et de meilleures

Quant à ce qu'il en est de l'intérêt de la manoeuvre, je dirais - à titre tout à fait personnel, ce la va de soi - qu'il est totalement nul et pire encore, contre productif.

Il faut bien te rendre compte que, si un code est obscurci, il l'est aussi pour toi, et que tu va donc avoir énormément de difficultés à apporter la moindre modification/correction...

Bien sur, tu peux toujours envisager de gérer deux versions de ton code: l'une "propre et lisible" et l'autre obscurcie, mais, même si quelque bons script peuvent suffir à obscurcir le code, cela nécessite toujours de gérer deux versions concurrentes, avec tous les problèmes que cela peut poser

[NewbiZ]

Bien sur, tu peux toujours envisager de gérer deux versions de ton code: l'une "propre et lisible" et l'autre obscurcie, mais, même si quelque bons script peuvent suffir à obscurcir le code, cela nécessite toujours de gérer deux versions concurrentes, avec tous les problèmes que cela peut poser

Non mais le code obfuscé n'est pas maintenu. Sa génération automatique est intégrée dans le processus de release.

A part ca, la principale utilité de l'obfuscation (outre le fun comme pour l'IOCCC), c'est d'obtenir l'équivalent d'un closed source, avec des langages interprétés.
L'exemple le plus simple est le javascript. Il n'en existe (à ma connaissance) aucune version compilée, ou même compressée, reconnue par les navigateurs. Une solution classique consiste donc à travailler avec un code JS clair en developpement (pour faciliter le debug), et de fournir une version
1) compressée, espaces inutiles enlevés, noms de variables réduits au maximum, etc... pour que ce soit plus petit à transmettre
2) obfuscée, parcequ'on ne veut pas forcément que chacun puisse la réutiliser/modifier.

Ca vaut aussi pour les langages comme Java et C# comme dit plus haut, car ils sont particulièrement verbeux même compilés (Autre exemple, essayes JAD en java, c'est assez impressionant ce qu'il peut recréer).

[zais_ethael]

Personnellement j'ai récemment croisé un moteur physique (TrueAxis) complétement obscurci à base de macros et d'identificateurs bidons. La raison principale étant la flexibilité apportée par le fait que chacun peut recompiler lui-même le moteur sur sa propre plateforme avec ses propres options, sans pour autant avoir véritablement accès aux sources.

L'ennui c'est que ce n'est pas forcément une bonne protection. Dans le cas d'une bibliothèque, on est forcé de supposer que tout ce qui est public (dans un header, à l'exception des membres private de classe) garde son nom d'origine. Donc en passant le code dans un pré compilateur puis dans un parser pour ensuite le réécrire avec une indentation correcte il sera nettement plus lisible. Le corps des méthodes contiendra toujours des variables au nom bizarre mais il est toujours plus facile de comprendre une fonction quand on sait ce qu'elle fait