Outils / stratégie d’obfuscation .NET

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

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

Ce que je sais, je devrais chercher jusqu’ici:

  • 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 difficulté de ne pas pouvoir charger des données qui étaient auparavant 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é cette problématique due à la modification des noms de fichiers .dll (vous en avez souvent un par page) – ce que tous les outils ne gèrent pas bien.

Retour avec .Net 1.1 obfuscation était essentiel: le code de décompilation était facile, et vous pouviez passer de l’assemblage, à l’IL, au code C # et le faire de nouveau comstackr avec très peu d’effort.

Maintenant, avec .Net 3.5, je ne suis pas du tout sûr. Essayez de décomstackr un assembly 3.5; Ce que vous obtenez est un long chemin depuis la compilation.

Ajoutez les optimisations de 3.5 (bien mieux que 1.1) et la manière dont les types anonymes, les delegates, etc. sont traités par reflection (ils sont un cauchemar à recomstackr). Ajoutez les expressions lambda, la «magie» du compilateur comme Linq-syntax et var , et les fonctions C # 2 comme yield (ce qui donne de nouvelles classes avec des noms illisibles). Votre code décompilé est très loin de compilable.

Une équipe de professionnels disposant de beaucoup de temps pourrait encore procéder au reverse engineering, mais il en va de même pour tout code obscurci. Quel code ils ont trouvé serait impossible à maintenir et très susceptible d’être très buggé.

Je vous recommande de signer vos assemblages (ce qui signifie que si les pirates peuvent en recomstackr un, ils doivent tout recomstackr), mais je ne pense pas que la dissimulation en vaut 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 le brouillage est un gros problème.

Même les problèmes abordés ne constituent pas un réel problème. La seule chose que vous devez vraiment protéger, ce sont les chaînes de connexion, les codes d’activation, etc. Ce non-sens qu’une autre entreprise va désosser l’intégralité de votre base de code et en créer un produit concurrent est quelque chose du cauchemar d’un gestionnaire paranoïaque, et non de la réalité.

Je suis “Knee Deep” dans ce moment, essayant de trouver une bonne solution. Voici mes impressions jusqu’ici.

Xenocode – J’ai une ancienne licence pour Xenocode2005 que j’utilisais pour masquer mes assemblys .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 de tenter le coup mais la version 2005 ne fonctionne même pas sur Vista (crash) alors je dois acheter maintenant ‘PostBuild2008’ à un prix défiant toute concurrence de 1900 $. Cela pourrait être un bon outil mais je ne vais pas le découvrir. Trop cher.

Reactor.Net – Ceci est un prix beaucoup plus attractif et il a bien fonctionné sur mon exécutable autonome. Le module de licence était également sympa 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’ai besoin (fusionner plusieurs assemblys ensemble, en obscurcir certains, pas en gêner d’autres).

SmartAssembly – J’ai téléchargé l’Eval pour cela et cela fonctionnait parfaitement. J’ai été capable de réaliser tout ce que je voulais et l’interface était de première classe. Le prix est encore un peu lourd.

Dotfuscator Pro – Impossible de trouver le prix sur le site Web. Actuellement en discussion pour obtenir un devis. Ça a l’air sinistre.

Confuser – un projet open source qui fonctionne assez bien (pour confondre ppl, comme son nom l’indique). https://confuser.codeplex.com/
(ajouté par jgauffin)

Remarque: ConfuserEx serait “cassé” selon le numéro 498 de son repository GitHub.

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


Depuis le 29 juin 2012 , Eazfuscator.NET est maintenant commercial. La dernière version disponible gratuite est 3.3.

J’ai utilisé smartassembly. Fondamentalement, vous choisissez un dll et il le rend obscurci. 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 sur le marché et SmartAssembly est le meilleur à mon avis.

J’ai également utilisé SmartAssembly. J’ai trouvé ce réacteur Ezrinz .Net beaucoup mieux pour moi sur les applications .net. Il obscurcit, supporte Mono, fusionne les assemblages et il a aussi 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 quand j’avais besoin de soutien, ils étaient rapides. Eziriz

Pour être clair, je suis juste un client qui aime le produit et n’a aucun lien avec la société.

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

Il existe divers outils qui compliquent la lecture de votre code – certains ont été signalés par d’autres réponses.

Cependant, tout cela rend la lecture plus difficile – ils augmentent la quantité d’effort requirejse, c’est tout. Souvent, cela suffit à dissuader les lecteurs occasionnels, mais une personne déterminée à explorer votre code sera toujours en mesure de le faire.

Nous avons une application multi-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 plus proche de “éviter de chiffrer les objects de type chargeur comme le fléau”. 🙂

D’après mon expérience, tout obfuscateur fonctionnera bien avec tous les aspects de .net, y compris asp.net et la communication à distance, il vous suffit de connaître les parameters et d’apprendre jusqu’où vous pouvez aller dans quels domaines de votre code. Et prenez le temps d’essayer le reverse engineering sur ce que vous obtenez et de voir comment cela fonctionne avec les différents parameters.

Nous avons utilisé plusieurs fois au cours des années dans nos applications commerciales et installé sur l’afficheur Spices de 9rays.net car le prix est correct, il fait le travail et ils ont un bon support bien que nous n’ayons plus besoin de soutien depuis des années mais pour être honnête Je ne pense pas que ce qui importe, quel brouilleur vous utilisez, les problèmes et la courbe d’apprentissage sont les mêmes si vous voulez que cela fonctionne correctement avec remoting et asp.net.

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

La licence est généralement le domaine clé pour la plupart des gens et vous devriez certainement utiliser un système de certificate signé numériquement pour les licences de toute façon. Votre plus grande perte viendra 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 ne vont jamais acheter.

Il est vraiment facile d’aller trop loin et d’avoir un impact négatif sur vos clients et votre entreprise, de faire ce qui est simple et raisonnable et de ne plus vous en soucier.

Ces deux derniers jours, j’expérimente Dotfuscator Community Edition advanced (téléchargement gratuit après avoir enregistré le 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 obtenir du code brouillé 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 que, en cas d’erreur, la trace de la stack était retournée et que le CE n’avait pas de désobfuseur ni de clarificateur.

J’ai essayé de masquer un vrai projet basé sur VSTO dans Excel, avec intégration de Virtual Earth, de nombreux appels de services Web et un conteneur IOC et beaucoup de reflection. C’était impossible.

Si l’obscurcissement est vraiment une exigence critique, vous devez concevoir votre application en fonction de cela dès le début, en testant les builds obscurcies au fur et à mesure de votre progression. Sinon, si le projet est assez complexe, vous allez vous retrouver avec beaucoup de douleur.

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

  1. Exclut automatiquement les types / membres de l’obscurcissement en fonction des règles. Les types / champs sérialisés en font partie.
  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 autre DLL et l’ai inclus dans le projet. Je pensais qu’il n’y avait aucun secret dans le XML de toute façon, donc il n’y avait pas besoin d’obscurcissement. S’il existe un code sérieux dans ces classes, l’utilisation de classes partielles dans l’assembly principal doit le couvrir.

Vous devriez utiliser ce qui est le moins cher et le plus connu pour votre plate-forme et l’appeler un jour. L’obscurcissement des langages de haut niveau est un problème difficile, car les stream de code d’opération de VM ne rencontrent pas les deux plus gros problèmes: les stream de code d’opération natifs: identification de fonction / méthode et alias de registre.

Ce que vous devez savoir à propos de l’inversion du bytecode, c’est qu’il est déjà courant que les testeurs de sécurité examinent le code X86 droit et y trouvent des vulnérabilités. Dans raw X86, 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 aucune circonstance, les inverseurs de code natifs n’ont access aux noms de fonctions et de variables, sauf s’ils examinent le code Microsoft, pour lequel MSFT fournit 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 plutôt que de publier du code avec des informations de niveau débogage, où le réflecteur renvoie littéralement votre code source. Mais tout ce que vous faites au-delà risque de générer 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 lire à ce sujet à:

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 que votre code soit obscurci? Habituellement, votre application est en cours de décompilation, sauf si elle est utilisée à des fins de sécurité. Si vous craignez que des personnes “volent” votre code, ne le faites pas; la grande majorité des personnes qui consultent votre code le seront à des fins d’apprentissage. Quoi qu’il en soit, il n’existe pas de stratégie de masquage totalement efficace pour .NET: une personne suffisamment compétente pourra toujours décomstackr / modifier votre application.

Évitez le réacteur. C’est complètement inutile (et oui j’ai payé pour une licence). Xenocode était le meilleur que j’ai rencontré et acheté une licence aussi. Le support était très bon mais je n’en avais pas besoin autant que ça fonctionnait. J’ai testé tous les obfuscateurs que je pouvais trouver et ma conclusion est que xenocode était de loin le plus robuste et faisait le meilleur travail (possibilité de post-traitement de votre fichier .NET sur un fichier natif que je ne voyais 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 assemblées n’est pas différente. Avec le réacteur, il était environ 6 millions de fois plus lent. J’ai aussi eu l’impression que ce réacteur était une opération à un seul homme.

J’ai trouvé que Agile.Net offrait une très bonne protection pour votre .Net Assembly, car il offre non seulement de l’obscurcissement, mais aussi du cryptage. Téléchargez une trace gratuite.
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 sharepoint vue de la maintenance. Comme vous l’avez mentionné, le problème de la sérialisation peut être évité, mais il est vraiment facile de faire une erreur et de masquer quelque chose que vous ne voulez pas masquer. Il est facile de casser la construction ou de modifier le modèle d’obfuscation et de ne pas pouvoir ouvrir d’anciens fichiers. De plus, il peut être difficile de savoir ce qui a mal tourné et où.

Nous avons choisi Xenocode, et si je devais faire le choix aujourd’hui, je préférerais ne pas masquer le code, ou utiliser Dotfuscator.

Voici un document de Microsoft eux-mêmes. J’espère que ça aide …, ça date de 2003, mais ça pourrait quand même être pertinent.

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

Ajoute aussi des problèmes supplémentaires. L’impression des noms de classe dans les fichiers journaux / exceptions doit être désembuée. Et bien sûr, vous ne pouvez pas créer une classe à partir de son nom. Il est donc judicieux de consulter votre client et de voir quels problèmes vous pouvez rencontrer en masquant.

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

le moyen libre serait d’utiliser dotfuscator à partir de Visual Studio, sinon vous devriez acheter un obfuscateur comme Postbuild ( http://www.xenocode.com/Landing/Obfuscation.aspx )

J’ai dû utiliser une protection de l’obscurcissement / des ressources dans mon dernier projet et j’ai trouvé que Crypto Obfuscator était un outil simple et convivial. Le problème de la sérialisation n’est qu’une question de parameters dans cet outil.

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

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

J’utilise aussi smartassembly. Cependant, je ne sais pas comment cela fonctionne pour une application Web. Cependant, j’aimerais 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 byte crack. 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 … ça m’a plu. Mais jamais apporté le logiciel.

L’obscurcissement n’est pas une véritable protection.

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

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 les DLL)

Themida est de loin moins cher que les obfuscateurs mentionnés ci-dessus et est la meilleure protection contre le piratage sur le marché. Il crée une machine virtuelle dans laquelle des parties critiques de votre code sont exécutées et exécute plusieurs threads qui détectent les manipulations ou les points d’arrêt définis par un pirate. Il convertit l’Exe .NET en un élément que Reflector ne reconnaît même plus comme un ensemble .NET.

S’il vous plaît 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’Eziriz propose mais que le prix pour Rummage est trop bon …