Outils/stratégie d'obscurcissement .NET

Mon produit comporte plusieurs composants : ASP.NET, l'application Windows Forms et le service Windows. Environ 95 % 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'utilisais 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 de ne pas obscurcir les membres de données de la classe, car la difficulté de ne pas pouvoir charger des données précédemment sérialisées est tout simplement trop importante.
  • Intégration avec le processus de création
  • 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.
请先 登录 后评论

6 réponses

Shawn

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

请先 登录 后评论
Andrew Peters

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

请先 登录 后评论
Judah Himango

Nous avons essayé plusieurs 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 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'obscurcissement est un gros hack.

Même les problèmes qu'il traite ne sont pas entièrement un vrai problème. La seule chose que vous devez vraiment protéger, ce sont les chaînes de connexion, les codes d'activation, les éléments sensibles à la sécurité comme ça. Ce non-sens qu'une autre entreprise va désosser toute votre base de code et créer un produit concurrent à partir de celle-ci est quelque chose du cauchemar d'un gestionnaire paranoïaque, pas la réalité.

请先 登录 后评论
Keith

Avec .Net 1.1, l'obscurcissement était essentiel : la décompilation du code était facile et vous pouviez passer de l'assemblage à l'IL, puis au C

请先 登录 后评论
Jon Dewees

J'obfusque 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 d'obscurcir quelque chose que vous ne vouliez pas obscurcir. Il est facile de casser 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 s'est mal passé et où.

Notre choix s'est porté sur Xenocode, et si je devais refaire ce choix aujourd'hui, je préférerais ne pas masquer le code ou utiliser Dotfuscator.

请先 登录 后评论
Geoff Appleford

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

请先 登录 后评论