Quel est l'interet d'obscurcir son code ? Il suffit de ne pas divulguer le code source et le programme sera protege.
Version imprimable
Quel est l'interet d'obscurcir son code ? Il suffit de ne pas divulguer le code source et le programme sera protege.
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.
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.
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.
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 :D)
- 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:
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.
- 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 :aie:)
- 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 :D)
- 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:question:) 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 :D
- préférer l'opérateur ternaire au bon vieux if...else
- j'en passe, et de meilleures :D
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 ;)
Non mais le code obfuscé n'est pas maintenu. Sa génération automatique est intégrée dans le processus de release.Citation:
Envoyé par koala01
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).
Peut-être... jusqu'au jour où...Citation:
Envoyé par NewbiZ
au vu des performances des connections internet actuelles, cet argument perd quand même énormément de son intérêt...Citation:
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
La question étant posée sur le forum C++, on peut quand même estimer qu'il pose la question au sujet des codes... C++...Citation:
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).
Cet argument, dont la valeur peut selon moi être fortement débattue au sujet des autres langages (le javascript, par exemple, devrait déjà être limité à une "prévérification" éventuelle, et ne contenir aucune information "sensible") devrait plutôt être réservé comme... argument en faveur du C++ et en défaveurs des autres ;)
Ca a toujours un intéret pour certains spammeurs, qui envoient des pages au format HTML contenant du javascript obfusqué...Citation:
Envoyé par koala01
Ce serait donc un inconvénient du code obfsuqué, et cela aurait donc tendance à plaider contre la technique ;)Citation:
Envoyé par Médinoc
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 :)Citation:
Envoyé par Laurent Gomila
Effectivement, je me posais la question au sujet du C++ et par extension aux autres langages compiles. Je comprends qu'il puisse y avoir un interet pour les langages interpretes.Citation:
Envoyé par koala01
Donc, en resume c'est utile pour les bibliotheques mais c'est surtout une question d'appreciation personnelle ?
Aucun, j'ai tellement lu de codes livrés avec des livres et donc censés être "éducatifs" qui sont tellement mal écris, bourrés d'erreurs et incompréhensibles que je hais tous les gens qui écrivent ces codes :aie:.
A peu près comme tout avis subjectif que tu peux demander...Citation:
Envoyé par Tymk
Personnellement, je trouve dans la majeure partie des cas que c'est inutile et même contre productif:
- Si tu ne veux pas permettre au gens de comprendre ton code lorsque tu crée ta bibliothèque, fournis la compilée et sans code-source
- utilise les langages pour ce pour quoi ils sont prévus (par exemple: ne demande pas à javascript de faire une autentification auprès d'un serveur)
- Si tu travailles avec un langage semi-compilé (semi interprété) comme C# ou java, fais ton choix: ou bien tu accepte de "courir le risque" de voir les gens "tripatouiller" ton code, ou bien tu choisi un langage pour lequel il sera plus difficile de retrouver le code à partir de l'exécutable
Quoi qu'il en soit, n'oublie de toutes façons jamais que, l'un dans l'autre, nombre de situations sont malgré tout fort similaires, que tu te sera peut être inspiré d'autre chose, et qu'il y a à l'heure actuelle finalement fort peu de chances - hormis dans certains cas très particuliers - pour que ton algorithme (car c'est peut être ce que l'on souhaiterait le plus protéger) soit à ce point "novateur" qu'il n'y en ait pas une version ne serait-ce que approximativement similaire ailleurs...
Tu l'auras sans doute remarqué, je suis plutôt tourné vers la notion de partage en informatique, mais je conçois que certains puissent vouloir "cacher" leur travail...
Simplement, je me dis que l'obfuscation du code reste la pire des manières (en dehors du "fun" de le faire) pour y arriver ;)
Personnellement, le meilleur moyen d'obscurcir un code est de le compiler :D.... Certes, tu trouveras toujours un hacker fou capable de modifier ta librairie après l'avoir désassemblée, mais c'est quand même plus rare...
Ton objectif est:
1/ Protégé ton source: un code compilé + du droit (licence).
2/ garantir contre des attaques liés à des bugs et/ou connaissance du code. Gestion des attaques à tous les niveaux du projet: spec + conception + tests de l'appli/librairie et du système. Il faut alors travailler avec des experts de ton métier capable d'identifier le type d'attaque que tu veux prévenir.
@3DArchi: En java ou en .Net, compiler le code ne suffit pas: Il faut également obscurcir le code compilé, à cause des informations de type, méta-données, etc. qui s'y trouvent.
3DArchi >> C'est très beau sans template. Mais dès qu'il y en à, ce n'est plus valable (cf un post de JolyLoic dans cet topic)
Médinoc: Il me semble qu'on est en C++, donc le code est compilé vers une machine cible...
Davidbrcz: Une interface en template revient effectivement à exporter le code source tel quel. Mais est-ce tout le temps applicable? Peut-être faut-il au moment de la conception séparer les éléments que l'on estime sensibles des autres et accepter quelques sacrifices.