Comment protéger les DLL?

Question

Comment protéger les DLL de mon projet de manière à ce qu'elles ne puissent pas être référencées et utilisées par d'autres personnes?

Merci

Answer 1

La réponse courte est qu'au-delà des choses évidentes, il n'y a pas grand chose à faire.

Les choses évidentes que vous pourriez envisager (à peu près dans l'ordre croissant de difficulté et de la vraisemblance décroissante) comprennent:

• lien statique donc il n'y a pas de DLL pour attaquer.
• Supprime tous les symboles.
• Utilisez un fichier .DEF et une bibliothèque d'importation pour que seules les exportations anonymes soient connues uniquement par leurs identifiants d'exportation.
• Conservez la DLL dans une ressource et exposez-la dans le système de fichiers (sous un nom suffisamment obscur, peut-être même généré lors de l'exécution) uniquement lors de l'exécution.
• Masquer toutes les fonctions réelles derrière une méthode d'usine qui échange un secret (mieux, preuve de la connaissance d'un secret) pour une table de pointeurs de fonction aux méthodes réelles.
• Utilisez des techniques anti-débogage empruntées au monde des logiciels malveillants pour empêcher l'ingénierie inverse. (Notez que cela vous donnera probablement des faux positifs des outils AV.)

Quoi qu'il en soit, un utilisateur suffisamment déterminé peut toujours trouver des façons de l'utiliser. Un désassembleur décent fournira rapidement toutes les informations nécessaires. Notez que si votre DLL est vraiment un objet COM, ou pire encore un assemblage CLR, il y a énormément d'informations sur le type d'exécution que vous ne pouvez pas supprimer sans casser son utilisation.

EDIT: Puisque vous avez retagged impliquer que C# et .NET sont l'environnement plutôt que d'une DLL pure win32 écrit en C, alors je devrais revoir ce qui précède: « Vous ne pouvez pas, mais .. "

Il existe depuis longtemps un marché pour les outils d'obfuscation pour traiter les environnements où la fourniture d'une source compilable est obligatoire, mais vous ne voulez pas fournir de source utile. Il y a des produits C# qui jouent sur ce marché, et il semble qu'au moins un ait été activé.

Parce que le chargement d'un assemblage nécessite beaucoup d'efforts de la structure, il est probable qu'il existe des bits d'autorisation qui exercent un certain contrôle pour fournisseurs honnêtes et consommateurs d'assemblées. Je n'ai pas vu de discussion sur la sécurité réelle fournie par ces méthodes et je ne sais tout simplement pas à quel point ils sont efficaces contre une attaque déterminée.

Beaucoup dépend de votre cas d'utilisation. Si vous voulez simplement éviter une utilisation occasionnelle, vous pouvez probablement trouver une solution qui fonctionne pour vous. Si vous souhaitez protéger vos précieux secrets commerciaux contre l'ingénierie inverse et la réutilisation, vous ne serez peut-être pas si heureux.

Answer 2

Vous pouvez intégrer dans votre exécutable, et extraire et LoadLibrary lors de l'exécution et de remettre en elle. Ou vous pouvez utiliser une sorte de clé partagée pour crypter/décrypter le fichier d'accompagnement et faire la même chose ci-dessus.

Je suppose que vous avez déjà envisagé des solutions comme le compiler si vous ne voulez pas le partager. Si quelqu'un veut vraiment y arriver, il y a plusieurs façons de le faire.

Answer 3

Jetez un coup d'œil au StrongNameIdentityPermissionAttribute. Cela vous permettra de déclarer l'accès à votre assembly. Combiné avec un bon outil de protection de code (comme CodeVeil (disclaimer je vends CodeVeil)) vous serez très heureux.

Answer 4

Vous êtes confrontés au même problème que les promoteurs de DRM.

Si votre programme (que vous souhaitez être en mesure d'exécuter la DLL) est exécutable par un compte utilisateur, il n'y a rien qui peut arrêter un programmeur suffisamment déterminé qui peut se connecter en tant que utilisateur d'isoler le code qui exécute le décryptage et l'utilise pour décrypter votre DLL et l'exécuter.

Vous pouvez bien sûr rendre la manipulation de l'ingénierie inverse peu pratique, et cela peut suffire.

Answer 5

Vous pouvez être intéressé par les informations suivantes sur les assemblées de votre ami: http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

Answer 6

Eh bien, vous pouvez marquer toutes vos classes « public » comme « interne » ou « protégés interne » marqueront alors vous assemblées avec [assemblage: InternalsVisibleTo ("")] Attribut et personne d'autre que les assemblages marqués peuvent voir le contenu.

Answer 7

Avez-vous essayé le réacteur .Net? Je suis récemment tombé dessus. Certaines personnes disent que c'est génial mais je suis encore en train de tester.