Outils / stratégie d'obfuscation .NET [fermé]

Mon produit comporte plusieurs composants: ASP.NET, Windows Forms App et Windows Service. 95% environ du code est écrit en VB.NET.

Pour des raisons de propriété intellectuelle, j'ai besoin d'obscurcir le code, et jusqu'à présent j'utilise une version de dotfuscator qui a maintenant plus de 5 ans. Je pense qu'il est temps de passer à un outil de nouvelle génération. Ce que je recherche est une liste d'exigences que je devrais prendre en compte lors de la recherche d'un nouvel obfuscateur.

Ce que je sais que je devrais rechercher jusqu'à présent:

• Sérialisation / désérialisation . Dans ma solution actuelle, je dis simplement à l'outil de ne pas masquer les membres de données de classe, car la douleur de ne pas pouvoir charger des données précédemment sérialisées est tout simplement trop grande.
• Intégration avec le processus de construction
• Travailler avec ASP.NET . Dans le passé, j'ai trouvé ce problème en raison de la modification des noms .dll (vous en avez souvent un par page) - que tous les outils ne gèrent pas bien.

De retour avec .Net 1.1, l'obscurcissement était essentiel: la décompilation du code était facile, et vous pouviez passer de l'assembly à l'IL, au code C # et le faire recompiler avec très peu d'effort.

Maintenant, avec .Net 3.5, je ne suis pas du tout sûr. Essayez de décompiler un assemblage 3.5; ce que vous obtenez est loin d'être compilé.

Ajoutez les optimisations de 3.5 (bien mieux que 1.1) et la façon dont les types anonymes, les délégués et ainsi de suite sont traités par réflexion (ils sont un cauchemar à recompiler). Ajoutez des expressions lambda, un compilateur «magique» comme la syntaxe Linq et var, et des fonctions C # 2 comme yield(ce qui entraîne de nouvelles classes avec des noms illisibles). Votre code décompilé est loin d'être compilable.

Une équipe professionnelle disposant de beaucoup de temps pourrait encore faire de l'ingénierie inverse, mais il en va de même pour tout code obscurci. Le code qu'ils en tireraient serait impossible à maintenir et très probablement très bogué.

Je recommanderais la signature de vos assemblys par clé (ce qui signifie que si les pirates peuvent en recompiler un, ils doivent tous recompiler) mais je ne pense pas que l'obfuscation en vaille la peine.

Nous avons essayé un certain nombre d'obfuscateurs. Aucun d'entre eux ne fonctionne sur une grande application client / serveur qui utilise la communication à distance. Le problème est que le client et le serveur partagent des DLL, et nous n'avons trouvé aucun obfuscateur capable de le gérer.

Nous avons essayé DotFuscator Pro, SmartAssembly, XenoCode, Salamander et plusieurs petites applications dont les noms m'échappent.

Franchement, je suis convaincu que l'obfuscation est un gros hack.

Même les problèmes qu'il aborde ne sont pas entièrement un problème réel. La seule chose que vous devez vraiment protéger est les chaînes de connexion, les codes d'activation, des éléments sensibles à la sécurité comme ça. Cette absurdité qu'une autre entreprise va rétroconcevoir l'ensemble de votre base de code et en créer un produit concurrent est quelque chose du cauchemar d'un manager paranoïaque, pas de la réalité.

Je suis «Knee Deep» dans ce domaine maintenant, essayant de trouver une bonne solution. Voici mes impressions jusqu'à présent.

Xenocode - J'ai une ancienne licence pour Xenocode2005 que j'utilisais pour masquer mes assemblages .net 2.0. Cela fonctionnait bien sur XP et était une solution décente. Mon projet actuel est .net 3.5 et je suis sur Vista, le support m'a dit d'essayer mais la version 2005 ne fonctionne même pas sur Vista (plantages) donc moi et maintenant je dois acheter 'PostBuild2008' à un prix époustouflant de 1900 $. C'est peut-être un bon outil mais je ne vais pas le découvrir. Trop cher.

Reactor.Net - C'est un prix beaucoup plus attractif et cela a bien fonctionné sur mon exécutable autonome. Le module de licence était également agréable et m'aurait épargné beaucoup d'efforts. Malheureusement, il manque une fonctionnalité clé et c'est la possibilité d'exclure des éléments de l'obscurcissement. Cela rend impossible d'obtenir le résultat dont j'avais besoin (fusionner plusieurs assemblys ensemble, obscurcir certains, pas obscurcir les autres).

SmartAssembly - J'ai téléchargé Eval pour cela et cela a fonctionné parfaitement. J'ai pu réaliser tout ce que je voulais et l'interface était de première classe. Le prix est encore un peu élevé.

Dotfuscator Pro - Impossible de trouver le prix sur le site Web. Actuellement en discussion pour obtenir un devis. Cela semble inquiétant.

Confuser - un projet open source qui fonctionne assez bien (pour confondre ppl, comme son nom l'indique).

Remarque: ConfuserEx serait "cassé" selon le problème n ° 498 sur leur dépôt GitHub.

Si vous recherchez un logiciel gratuit, vous pouvez essayer DotObfuscator Community Edition fourni avec Visual Studio ou Eazfuscator.NET .

Depuis le 29 juin 2012 , Eazfuscator.NET est désormais commercial. La dernière version gratuite disponible est la 3.3.

J'utilise smartassembly. Fondamentalement, vous choisissez une dll et elle la renvoie obscurcie. Cela semble bien fonctionner et je n'ai eu aucun problème jusqu'à présent. Très, très facile à utiliser.

J'ai essayé presque tous les obfuscateurs du marché et SmartAssembly est le meilleur à mon avis.

J'utilise également SmartAssembly. J'ai trouvé que Ezrinz .Net Reactor était bien meilleur pour moi sur les applications .net. Il obscurcit, supporte Mono, fusionne les assemblages et il dispose également d'un très bon module de licence pour créer une version d'essai ou lier la licence à une machine particulière (très facile à implémenter). Le prix est également très compétitif et lorsque j'ai besoin de support, ils sont rapides. Eziriz

Pour être clair, je ne suis qu'un client qui aime le produit et qui n'a aucun lien avec l'entreprise.

La réponse courte est que vous ne pouvez pas.

Il existe divers outils qui rendront la lecture de votre code plus difficile pour quelqu'un - dont certains ont été signalés par d'autres réponses.

Cependant, tout cela rend la lecture plus difficile - ils augmentent l'effort requis, c'est tout. Souvent, cela suffit à dissuader les lecteurs occasionnels, mais quelqu'un qui est déterminé à fouiller dans votre code sera toujours en mesure de le faire.

Nous avons une application à plusieurs niveaux avec une interface asp.net et winform qui prend également en charge la communication à distance. Je n'ai eu aucun problème avec l'utilisation d'un obfuscateur à l'exception du type de cryptage qui génère un chargeur qui peut être problématique de toutes sortes de manières inattendues et ne vaut tout simplement pas la peine à mon avis. En fait, mon conseil serait plutôt du type "Évitez de crypter les obfuscateurs de type chargeur comme la peste". :)

D'après mon expérience, tout obfuscateur fonctionnera bien avec n'importe quel aspect de .net, y compris asp.net et la communication à distance, il vous suffit de devenir intime avec les paramètres et d'apprendre jusqu'où vous pouvez le pousser dans quelles zones de votre code. Et prenez le temps d'essayer la rétro-ingénierie sur ce que vous obtenez et voyez comment cela fonctionne avec les différents paramètres.

Nous en avons utilisé plusieurs au fil des ans dans nos applications commerciales et nous nous sommes installés sur l'obscurcisseur d'épices de 9rays.net parce que le prix est correct, il fait le travail et ils ont un bon support bien que nous n'ayons plus vraiment besoin du support depuis des années, mais pour être honnête Je ne pense pas que l'obfuscateur que vous utilisez ait vraiment d'importance, les problèmes et la courbe d'apprentissage sont les mêmes si vous voulez qu'il fonctionne correctement avec Remoting et asp.net.

Comme d'autres l'ont mentionné, tout ce que vous faites vraiment est l'équivalent d'un cadenas, empêchant les personnes honnêtes de sortir et / ou rendant plus difficile la simple recompilation d'une application.

La licence est généralement le domaine clé pour la plupart des gens et vous devriez certainement utiliser une sorte de système de certificat signé numériquement pour la licence de toute façon. Votre plus grande perte proviendra du partage occasionnel de licences si vous n'avez pas de système intelligent en place, les personnes qui enfreignent le système de licences n'achèteront jamais en premier lieu.

Il est vraiment facile d'aller trop loin et d'avoir un impact négatif sur vos clients et votre entreprise, faites ce qui est simple et raisonnable et ne vous en faites pas.

Au cours des deux derniers jours, j'ai expérimenté Dotfuscator Community Edition advanced (un téléchargement gratuit après l'enregistrement du CE de base fourni avec Visual Studio).

Je pense que la raison pour laquelle plus de gens n'utilisent pas l'obscurcissement comme option par défaut est que c'est un problème sérieux par rapport au risque. Sur des projets de test plus petits, je pouvais faire fonctionner le code obscurci avec beaucoup d'efforts. Déployer un projet simple via ClickOnce était gênant, mais réalisable après avoir signé manuellement les manifestes avec mage. Le seul problème était qu'en cas d'erreur, la trace de la pile est revenue obscurcie et le CE n'a pas de désobfuscateur ou de clarificateur emballé.

J'ai essayé de brouiller un vrai projet qui est basé sur VSTO dans Excel, avec l'intégration de Virtual Earth, beaucoup d'appels de services Web et un conteneur IOC et beaucoup de réflexion. C'était impossible.

Si l'obscurcissement est vraiment une exigence critique, vous devez concevoir votre application en gardant cela à l'esprit dès le début, en testant les versions obscurcies au fur et à mesure de votre progression. Sinon, si c'est un projet assez complexe, vous allez vous retrouver avec une grosse douleur.

Crypto Obfuscator répond à toutes vos préoccupations et scénarios. Il :

1. Exclut automatiquement les types / membres de l'obscurcissement en fonction des règles. Les types / champs sérialisés sont l'un d'entre eux.
2. Il peut être intégré au processus de construction à l'aide de MSBUild.
3. Prend en charge les projets ASP.Net.

J'ai récemment essayé de canaliser la sortie d'un obfuscateur gratuit dans un autre obfuscateur gratuit - à savoir Dotfuscator CE et le nouvel obfuscateur Babel sur CodePlex. Plus de détails sur mon blog .

En ce qui concerne la sérialisation, j'ai déplacé ce code dans une DLL différente et l'ai inclus dans le projet. J'ai pensé qu'il n'y avait pas de secrets là-dedans qui ne soient de toute façon pas dans le XML, donc cela n'avait pas besoin d'être obscurci. S'il y a du code sérieux dans ces classes, l'utilisation de classes partielles dans l'assembly principal devrait le couvrir.

Vous devez utiliser ce qui est le moins cher et le plus connu pour votre plate-forme et l'appeler un jour. L'obfuscation des langages de haut niveau est un problème difficile, car les flux d'opcode VM ne souffrent pas des deux plus gros problèmes que les flux d'opcode natifs font: l'identification de fonction / méthode et l'alias de registre.

Ce que vous devez savoir sur l'inversion de bytecode, c'est qu'il est déjà une pratique standard pour les testeurs de sécurité d'examiner le code X86 pur et d'y trouver des vulnérabilités. Dans X86 brut, vous ne pouvez même pas nécessairement trouver des fonctions valides, et encore moins suivre une variable locale tout au long d'un appel de fonction. Dans presque aucun cas, les inverseurs de code natifs n'ont accès aux noms de fonctions et de variables - à moins qu'ils n'examinent le code Microsoft, pour lequel MSFT fournit utilement ces informations au public.

"Dotfuscation" fonctionne principalement en brouillant les noms de fonctions et de variables. Il est probablement préférable de le faire que de publier du code avec des informations de niveau de débogage, où le réflecteur abandonne littéralement votre code source. Mais tout ce que vous faites au-delà de cela risque d'entraîner des rendements décroissants.

Je n'ai eu aucun problème avec Smartassembly.

Vous pouvez utiliser "Dotfuscator Community Edition" - il est fourni par défaut dans Visual Studio 2008 Professional. Vous pouvez en savoir plus sur:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

La version "professionnelle" du produit coûte de l'argent mais est meilleure.

Avez-vous vraiment besoin de votre code obscurci? Habituellement, il y a très peu de problèmes avec votre application en cours de décompilation, sauf si elle est utilisée à des fins de sécurité. Si vous craignez que les gens «volent» votre code, ne le soyez pas; la grande majorité des personnes qui consultent votre code le seront à des fins d'apprentissage. Quoi qu'il en soit, il n'y a pas de stratégie d'obfuscation totalement efficace pour .NET - quelqu'un avec suffisamment de compétences sera toujours en mesure de décompiler / modifier votre application.

Évitez Reactor. C'est complètement inutile (et oui j'ai payé une licence). Xenocode était le meilleur que j'ai rencontré et j'ai acheté une licence pour aussi. Le support était très bon mais je n'en avais pas vraiment besoin car cela fonctionnait. J'ai testé tous les obfuscateurs que j'ai pu trouver et ma conclusion est que xenocode était de loin le plus robuste et faisait le meilleur travail (également possibilité de post-traiter votre exe .NET dans un exe natif que je n'ai vu nulle part ailleurs.).

Il existe deux différences principales entre le réacteur et le xénocode. Le premier est que Xenocode fonctionne réellement. La seconde est que la vitesse d'exécution de vos assemblys n'est pas différente. Avec le réacteur, il était environ 6 millions de fois plus lent. J'ai également eu l'impression que le réacteur était une opération par un seul homme.

J'ai trouvé qu'Agile.Net fournissait une assez bonne protection pour votre .Net Assembly car il offre non seulement l'obscurcissement mais aussi le cryptage. Téléchargez un parcours gratuit.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

J'ai obscurci le code dans la même application depuis .Net 1, et cela a été un casse-tête majeur du point de vue de la maintenance. Comme vous l'avez mentionné, le problème de sérialisation peut être évité, mais il est vraiment facile de faire une erreur et d'obscurcir quelque chose que vous ne vouliez pas obscurcir. Il est facile de casser la compilation ou de modifier le modèle d'obscurcissement et de ne pas pouvoir ouvrir d'anciens fichiers. De plus, il peut être difficile de savoir ce qui n'a pas fonctionné et où.

Notre choix était Xenocode, et si je devais refaire ce choix aujourd'hui, je préférerais ne pas obscurcir le code ou utiliser Dotfuscator.

Voici un document de Microsoft eux-mêmes. J'espère que ça aide ..., c'est à partir de 2003, mais cela pourrait encore être pertinent.

Nous utilisons SmartAssembly sur notre client Windows. Fonctionne très bien.

Ajoute également des problèmes supplémentaires. L'impression de vos noms de classe dans les fichiers journaux / exceptions doit être supprimée. Et bien sûr, ne peut pas créer une classe à partir de son nom. C'est donc une bonne idée de jeter un œil à votre client et de voir quels problèmes vous pouvez obtenir en obscurcissant.

Tout dépend du langage de programmation que vous utilisez. Lire l'article: Code obscurci

la manière gratuite serait d'utiliser dotfuscator depuis Visual Studio, sinon vous devrez acheter un obfuscator comme Postbuild ( http://www.xenocode.com/Landing/Obfuscation.aspx )

J'ai dû utiliser une protection d'obfuscation / ressource dans mon dernier rpoject et j'ai trouvé Crypto Obfuscator comme un outil simple et agréable à utiliser. Le problème de sérialisation n'est qu'une question de paramètres dans cet outil.

Il existe une bonne version open source appelée Obfuscar. Semble bien fonctionner. Les types, propriétés, champs, méthodes peuvent être exclus. L'original est ici: https://code.google.com/p/obfuscar/ , mais comme il ne semble plus être mis à jour

Vous voudrez peut-être également examiner les nouvelles technologies de protection de code telles que Metaforic et ViLabs et les nouvelles technologies de protection contre la copie de logiciels telles que ByteShield . Divulgation: je travaille pour ByteShield.

J'utilise également smartassembly. Cependant, je ne sais pas comment cela fonctionne pour une application Web. Cependant, je tiens à souligner que si votre application utilise une protection de type shareware, assurez-vous qu'elle ne vérifie pas une licence avec un retour booléen. il est trop facile de cracker des octets. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

SmartAssembly est génial, j'ai été utilisé dans la plupart de mes projets

J'ai essayé la version démo d'Eziriz .... Je l'ai aimé. Mais jamais apporté le logiciel.

Obscurcir n'est pas une vraie protection.

Si vous avez un fichier .NET Exe, il existe une solution bien meilleure .

J'utilise Themida et je peux dire que cela fonctionne très bien.

Le seul inconvénient de Themida est qu'il ne peut pas protéger les DLL .NET. (Il protège également le code C ++ dans Exe et DLL)

Themida est de loin moins cher que les obfuscators mentionnés ici et est le meilleur en matière de protection anti- piratage sur le marché. Il crée une machine virtuelle sur laquelle des parties critiques de votre code sont exécutées et exécute plusieurs threads qui détectent la manipulation ou les points d'arrêt définis par un pirate. Il convertit le .NET Exe en quelque chose que Reflector ne reconnaît même plus comme un assembly .NET.

Veuillez lire la description détaillée sur leur site Web: http://www.oreans.com/themida_features.php

J'ai essayé un produit appelé Rummage et il fait un bon travail en vous donnant un certain contrôle ... Bien qu'il manque beaucoup de choses qu'offre Eziriz mais le prix pour Rummage est trop bon ...