Dois-je craindre de brouiller mon code .NET ?[fermé]

Question

Je suis sûr que de nombreux lecteurs sur SO ont utilisé Lutz Röderc'est Réflecteur .NET pour décompiler leur code .NET.J'ai été étonné de voir avec quelle précision notre code source pouvait être reconstruit à partir de nos assemblys compilés.

J'aimerais savoir combien d'entre vous utilisent l'obscurcissement et pour quel type de produits ?

Je suis sûr qu'il s'agit d'un problème beaucoup plus important, par exemple, pour une application .NET que vous proposez en téléchargement sur Internet, par opposition à quelque chose qui est conçu sur mesure pour un client particulier.

Answer 1

Je ne m'en inquiéterais pas trop.Je préfère me concentrer sur la création d'un produit génial, l'obtention d'une bonne base d'utilisateurs et le bon traitement de vos clients plutôt que de m'inquiéter du pourcentage minimal d'utilisateurs concernés par le vol de votre code ou la recherche de la source.

Answer 2

N'oubliez pas que l'obscurcissement n'est pas un chiffrement.À mon humble avis, si quelqu'un perçoit l'intérêt de la rétro-ingénierie de votre code, il le fera.C'est vrai pour le code managé ou le code natif, obscurci ou non.Bien sûr, l’obscurcissement dissuade l’observateur occasionnel, mais votre entreprise est-elle réellement menacée par de telles personnes ?Chaque méthode d'obscurcissement .NET que j'ai vue rend votre vie de développeur plus difficile.

Il existe des services qui offrent un véritable cryptage, comme SLPS de Microsoft.Voir http://www.microsoft.com/slps/default.aspx

Answer 3

Nous masquons actuellement toute notre production, même si nous sommes une petite entreprise qui vend des logiciels spécialisés à un petit nombre de clients.

Nous avons pris cette décision pour une raison simple : nous avons découvert qu'un ancien employé mécontent s'adressait activement à nos clients pour leur demander des fichiers binaires. Certains craignaient qu'il ait l'intention de procéder à une ingénierie inverse de nouvelles fonctionnalités afin d'offrir des fonctionnalités concurrentes.

Bien sûr, il est toujours capable de le faire s'il utilise le logiciel, mais il n'y a aucune raison de lui faciliter la tâche.

Answer 4

Pas de nouvel obscurcissement, mais beaucoup d'astuces du compilateur depuis la 1.1

Par exemple, chaque fois que vous utilisez un type anonyme, vous obtenez un IL qui se compile avec un nom assez obscur.Chaque fois que vous utilisez rendement, vous obtenez une toute nouvelle classe qui implémente à la fois IEnumerable et IEnumerable (optimisation intelligente, code illisible).Chaque fois que vous utilisez un délégué anonyme, vous obtenez une nouvelle méthode avec un nom invalide dans tous les langages .Net que je connais, mais c'est bien dans l'IL.

Answer 5

@Rob Cooper

Ayant eu quelques discussions avec mon manager au travail, il a dit qu'il n'obscurcit pas, mais que Ngen sur l'installation, apparemment, cela devrait être suffisant pour empêcher le réflecteur de travailler sur vos assemblées, mais je ne sais pas si c'est vrai et dans quelle mesure , alors ne le prenez pas comme l'évangile :)

Cela n'offre aucune sorte de protection contre le démontage.Tout d'abord, j'imagine qu'il est tout à fait possible d'extraire des fichiers bruts de n'importe quel package d'installation comme un fichier MSI ou CAB.

Mais plus important encore, Ngen s’exécute sur la machine cliente une fois l’assembly installé.Ngen force simplement l'assembly à se compiler maintenant au lieu de plus tard en utilisant le JIT.L'assembly d'origine reste et n'est pas modifié et il doit rester car Ngen pourrait ne pas être en mesure de compiler l'intégralité de l'assembly.

Ngen est destiné aux performances, pas à la sécurité, et ne fait rien pour empêcher le démontage ou le rendre encore un peu plus difficile.

Answer 6

facile pour moi - si vous avez besoin de protéger la propriété intellectuelle - obfuicez - sinon ne le faites pas.

Facile à faire avec les bons outils.

Answer 7

Je pense que dans une certaine mesure, nous devrions TOUS nous soucier de notre IP :)

Bonne question cependant car c'est quelque chose sur lequel j'ai hâte d'en savoir plus (je le fais actuellement) pas brouiller).

Après avoir eu quelques discussions avec mon manager au travail, il a dit qu'il ne dissimulait pas, mais qu'il faisait NGEN lors de l'installation, apparemment cela devrait suffire à empêcher Reflector de travailler sur vos assemblages, mais je ne sais pas si cela est vrai et dans quelle mesure , alors s'il vous plaît, ne le prenez pas comme un évangile :)

Bonne question :) +1

Answer 8

Nous n'utilisons pas l'obscurcissement pour les applications "non publiques", mais nous l'utilisons pour les applications publiques disponibles.L'application obscurcie contient de nombreux codes très sophistiqués qui nous ont pris un temps exorbitant à écrire et c'est la raison qui me laisse penser que l'obscurcissement est un must - du moins dans ce cas.

Answer 9

L'obscurcissement est limité dans son efficacité, il pourrait éloigner le gars occasionnel.L'obscurcissement le plus efficace consiste à ne rendre disponible que la plus petite quantité de code à l'utilisateur.Si vous le pouvez, faites en sorte que l'exécution de votre application dépende fortement d'un gros serveur.

Answer 10

D’accord, la plupart des gens qui savent coder ne serait-ce qu’un peu n’ont pas besoin de voler votre code !