Question

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

Pour des raisons de propriété intellectuelle, je dois 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, c'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 pas pour obscurcir tous les membres de données de classe, car la difficulté 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é cela problématique en raison du changement des noms .dll (vous en avez souvent un par page) - que tous les outils ne gèrent pas bien.
Était-ce utile?

La solution

De retour avec .Net 1.1, l'obscurcissement était essentiel :la décompilation du code était facile, et vous pouviez passer de l'assemblage, à 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 assembly 3.5 ;ce que vous obtenez est loin d’être compilé.

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

Une équipe professionnelle disposant de beaucoup de temps pourrait toujours procéder à une 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 de signer par clé vos assemblys (ce qui signifie que si les pirates peuvent en recompiler un, ils doivent tous recompiler), mais je ne pense pas que l'obscurcissement en vaut la peine.

Autres conseils

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 certaines DLL et nous n'avons trouvé aucun obfuscateur capable de les 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'obscurcissement est un gros hack.

Même les problèmes qu’il aborde ne constituent pas entièrement un problème réel.La seule chose que vous devez vraiment protéger, ce sont les chaînes de connexion, les codes d’activation et les éléments sensibles à la sécurité comme celui-là.Cette absurdité selon laquelle une autre entreprise va procéder à l'ingénierie inverse de l'ensemble de votre base de code et créer un produit concurrent à partir de celle-ci relève du cauchemar d'un manager paranoïaque, et non de la réalité.

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

Xénocode - J'ai une ancienne licence pour Xenocode2005 que j'utilisais pour obscurcir mes assemblys .net 2.0.Cela fonctionnait bien sous XP et constituait 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 ahurissant de 1900$.Cela pourrait être un bon outil mais je ne vais pas le découvrir.Trop cher.

Réacteur.Net - C'est un prix beaucoup plus attractif et cela a bien fonctionné sur mon exécutable autonome.Le module Licences était également intéressant et m'aurait épargné beaucoup d'efforts.Malheureusement, il manque une fonctionnalité clé, à savoir la possibilité d'exclure des éléments de l'obscurcissement.Cela rend impossible l'obtention du résultat dont j'avais besoin (fusionner plusieurs assemblages ensemble, en masquer certains, pas en masquer d'autres).

Assemblage intelligent - 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 reste encore un peu élevé.

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

Confus - un projet open source qui fonctionne plutôt bien (pour confondre les gens, comme son nom l'indique). https://confuser.codeplex.com/
(ajouté par jgauffin)

Note:ConfuserEx serait "cassé" selon Numéro 498 sur leur dépôt GitHub.

Si vous en recherchez un 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é qu'Ezrinz .Net Reactor était bien meilleur pour moi sur les applications .net.Il obscurcit, prend en charge Mono, fusionne les assemblys et il dispose également d'un très joli module de licence pour créer une version d'essai ou lier la licence à une machine particulière (très facile à mettre en œuvre).Le prix est également très compétitif et lorsque j'ai eu besoin d'aide, ils ont été rapides.Eziriz

Juste 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 plus difficile la lecture de votre code par quelqu'un - dont certains ont été soulignés par d'autres réponses.

Cependant, tout cela ne fait que rendre la lecture plus difficile – ils augmentent la quantité d’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 multiniveau avec une interface asp.net et winform qui prend également en charge l'accès à distance.Je n'ai eu aucun problème avec l'utilisation d'un obfuscateur, à l'exception du type de chiffrement qui génère un chargeur qui peut être problématique de toutes sortes de manières inattendues et qui n'en vaut tout simplement pas la peine à mon avis.En fait, mon conseil serait plutôt du type "Évitez de chiffrer les obfuscateurs de type chargeur comme la peste".:)

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

Nous en avons utilisé plusieurs au fil des années dans nos applications commerciales et avons opté pour l'obfuscateur Spices de 9rays.net car le prix est correct, il fait le travail et ils ont un bon support même si nous n'avons plus vraiment besoin de support depuis des années, mais pour être honnête Je ne pense pas que le choix de l'obfuscateur que vous utilisez importe vraiment, les problèmes et la courbe d'apprentissage sont tous les mêmes si vous voulez qu'il fonctionne correctement avec l'accès à distance et asp.net.

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

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

Il est très 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 inquiétez pas.

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

Je pense que la raison pour laquelle de plus en 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 exécuter le code obscurci avec beaucoup d'efforts.Le déploiement d'un projet simple via ClickOnce était difficile, 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 revenait obscurcie et le CE ne disposait pas d'un désobfuscateur ou d'un clarificateur.

J'ai essayé de masquer un vrai projet VSTO basé sur Excel, avec l'intégration de Virtual Earth, de nombreux appels de service Web, 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, s’il s’agit d’un projet assez complexe, vous allez vous retrouver avec de sérieuses difficultés.

Obfuscateur de crypto-monnaie répondre à 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 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 vers 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 je l'ai inclus dans le projet.J'ai pensé qu'il n'y avait de toute façon aucun secret là-dedans qui ne soit pas dans le XML, donc il 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 arrêter cela.L'obscurcissement des langages de haut niveau est un problème difficile, car les flux d'opcodes de VM ne souffrent pas des deux plus gros problèmes des flux d'opcodes natifs :identification de la fonction/méthode et alias de registre.

Ce que vous devez savoir sur l'inversion du bytecode, c'est qu'il est déjà courant pour les testeurs de sécurité d'examiner le code X86 direct et d'y trouver des vulnérabilités.Dans le 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 natif n'ont accès aux noms de fonctions et de variables, sauf s'ils 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 faire cela plutôt que de publier du code avec des informations de niveau débogage, où le Reflector abandonne littéralement votre code source.Mais tout ce que vous faites au-delà de cela est susceptible d’engendrer 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 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 que votre code soit obscurci ?Habituellement, il y a très peu de problèmes à décompiler votre application, à moins qu'elle ne soit utilisée à des fins de sécurité.Si vous craignez que des personnes « volent » votre code, ne le soyez pas ;la grande majorité des personnes qui consulteront votre code le seront à des fins d’apprentissage.Quoi qu'il en soit, il n'existe pas de stratégie d'obscurcissement totalement efficace pour .NET - une personne suffisamment compétente sera toujours en mesure de décompiler/modifier votre application.

Évitez le réacteur.C'est complètement inutile (et oui j'ai payé une licence).Xenocode était le meilleur que j'ai rencontré et pour lequel j'ai également acheté une licence.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 le xénocode était de loin le plus robuste et faisait le meilleur travail (possibilité également de post-traiter votre exe .NET vers 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.La première 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, c'était environ 6 millions de fois plus lent.J'ai aussi eu l'impression que le réacteur était l'affaire d'un seul homme.

J'ai trouvé qu'Agile.Net offre une assez bonne protection pour votre assemblage .Net car il offre non seulement l'obscurcissement mais également 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 très facile de faire une erreur et de masquer quelque chose que vous ne vouliez pas masquer.Il est facile d'interrompre la construction 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 ne va pas et où.

Notre choix s'est porté sur 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 lui-même. J'espère que cela aide..., cela date de 2003, mais cela pourrait toujours être pertinent.

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

Cela ajoute également quelques problèmes supplémentaires.L'impression des noms de vos classes dans les fichiers journaux/exceptions doit être désobscurcie.Et bien sûr, vous ne pouvez pas créer une classe à partir de son nom.C'est donc une bonne idée d'examiner votre client et de voir quels problèmes vous pouvez rencontrer en obscurcissant.

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

la méthode gratuite serait d'utiliser dotfuscator depuis Visual Studio, sinon vous devrez acheter un obfuscateur comme Postbuild (http://www.xenocode.com/Landing/Obfuscation.aspx)

J'ai dû utiliser une protection d'obscurcissement/ressource dans mon dernier projet et j'ai trouvé Obfuscateur de crypto-monnaie comme un outil agréable et simple à 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.Cela semble bien fonctionner.Les types, propriétés, champs et méthodes peuvent être exclus.L'original est ici : https://code.google.com/p/obfuscar/, mais comme il ne semble plus être mis à jour, quelqu'un l'a copié ici : https://obfuscar.codeplex.com/

Vous souhaiterez peut-être également examiner de nouvelles technologies de protection du code telles que Métaforique et V.i.Labs et de nouvelles technologies de protection contre la copie de logiciels telles que OctetShield.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.c'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 je n'ai jamais apporté le logiciel.

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

Si vous disposez d'un fichier .NET Exe, il existe un Bien mieux solution.

j'utilise Thémida 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 obfuscateurs mentionnés ici et est le meilleur du marché. anti le piratage protection sur le marché.Il crée une machine virtuelle où les 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 quelque chose que Reflector ne reconnaît même plus comme un assemblage .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 du bon travail en vous donnant un certain contrôle...Bien qu'il manque beaucoup de choses qu'Eziriz propose, le prix pour Rummage est trop bon...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top