Restriction à l'aide de la fonctionnalité dlls nommée forte

J'essaie de trouver un moyen qui empêche les autres d'utiliser vos DLL publiées. Par exemple, imaginons que vous créez un outil de traitement de photos WinUI léger et léger, séparé en plusieurs assemblages. L'un d'entre eux est votre précieux assembly filters.dll qui fait essentiellement tout le travail de filtrage de base. Une fois que vous publiez votre application, comment pouvez-vous empêcher d'autres de prendre ce filters.dll et de l'utiliser dans d'autres projets?Restriction à l'aide de la fonctionnalité dlls nommée forte

J'ai déjà essayé de regarder le StrongNameIdentityPermissionAttribute qui a un bon exemple here mais il ne semble pas fonctionner pour moi, le code fonctionne sans jeter des exceptions de sécurité ..

Toutes les idées?

Source

2009-08-27 Anonymous

Une méthode qui peut fonctionner pour vous est de déclarer que les méthodes et les classes de l'assembly de filtrage sont internes et de spécifier explicitement les assemblées qui peuvent y accéder en tant qu'amis.

Vous faites cela avec une déclaration d'assemblage (ususally en AssemblyInfo) comme:

[assembly:InternalsVisibleTo("cs_friend_assemblies_2")]

voir Friend Assemblies pour plus d'informations.

Assurez-vous également d'obscurcir l'ensemble ou les gens peuvent creuser dans le code avec un réflecteur.

Source

2009-08-27 08:13:06

Notez que si vous effectuez un SN-ing sur les assemblages dépendants, internalsVisibleTo doit être un nom d'assembly complet [y compris le jeton SN]. Mais ma principale préoccupation ici serait que InternalsVisibleTo n'aide pas beaucoup sauf qu'un obfuscator sera [out of the box] généralement plus agressif avec les internes qu'avec les publics. –

Les internes empêcheront quelqu'un de référencer directement l'assemblée et comme vous le dites, les internes peuvent aussi être obscurcis, ce qui n'est pas le cas des publics.Si vous comptez sur l'obfuscation seule, votre interface publique est toujours exposée à être réutilisée. En fin de compte, si le code est déployé sur le client, vous vous battez contre une bataille perdue. –

@John: Attention, ce n'est pas ce que je disais - interne ne le rend pas obfuscatable. La plupart des obfuscateurs ont un interrupteur qui dit «ceci est mon ensemble complet d'assemblées» qui obscurcit aussi les publics. Comme la réflexion peut tout appeler privé, il y a généralement un moyen d'indiquer que quelque chose ne devrait pas être obscurci même si l'obfuscateur pense que cela a du sens - soit par ObfuscationAttribute ou par un paramètre de configuration obfuscator. La valeur de peopel contrecarrée dans les tentatives de «référencement direct» est pire qu'inutile en tant que mécanisme de protection de la propriété intellectuelle. –

Les noms forts n'ont rien à voir avec la prévention ou l'inhibition de la rétro-ingénierie. Ils servent seulement à empêcher les gens de substituer des assemblys avec des versions piratées - et seulement si les gens n'ont pas désactivé la vérification de nom fort. Il n'y a rien pour empêcher les gens de prendre votre code, ILDASMing ou Reflectoring et re-ILASMing comme ils l'entendent. InternalsVisibleTo et ses amis sont aussi sur un système d'honneur au niveau du compilateur, donc peu utilisé pour ce que vous cherchez (bien que pour certains obfuscateurs, les internes soient plus obscurément agressés que les publics par défaut - bien que cela puisse généralement être surmonter). Ma principale préoccupation ici est de souligner que jsut parce que quelque chose est «interne» ne donne aucune poussière de pixie qui empêche l'ingénierie inverse.

Most of this stuff re why these sort of approaches arent a solution for code protection is summarised very well in this article

Il y a aussi des produits de protection de code sur le marché qui vont au-delà de l'obscurcissement qui sonne comme l'outil pour le travail que vous décrivez.

Source

2009-08-27 08:18:47

Merci pour l'info, obfuscation peut (essayer de) protéger mon code contre le désassemblage ou l'ingénierie inverse, mais ne peut pas aider à être référencé et réutilisé, donc obfuscation est probablement un must mais pas suffisant. –

Ne vous préoccupez pas trop de protéger votre code .NET. Si vous le déployez sur un autre ordinateur, et que cette personne veut utiliser ou lire votre code, elle le fera.

Si votre code est suffisamment précieux, vous devez le conserver sur un ordinateur que vous contrôlez (comme un serveur Web) et vous protéger contre tout accès non autorisé.

L'obfuscation ne fera que ralentir les gens déterminés. Une dénomination et une signature strictes ne sont pas utilisées pour protéger votre code, mais plutôt pour s'assurer que l'utilisateur peut confirmer que le code provient de qui il attend de lui (c'est-à-dire qu'il n'a pas été falsifié).

Source

2009-08-27 08:27:12 Ash

N'est-ce pas aussi dire de ne pas embêter le pare-feu, si quelqu'un veut pénétrer votre ordinateur, il va .. –

@Roiy, Non. Le pare-feu de mon routeur fonctionne réellement et empêche les personnes non autorisées d'accéder à mon réseau, donc je serais un idiot pour l'éteindre. Alors que l'obscurcissement du code .NET ralentira tout au plus quelqu'un qui essaie de réutiliser/pirater son code, il ne protège que le code qui ne vaut pas le temps de se désobéir. – Ash

Je vous assure que si un pirate déterminé veut prendre le contrôle de votre ordinateur, le pare-feu Router de 100 $ ne l'arrêtera pas. ni le pare-feu de sécurité Checkpoint 1500 $ ... et étonnamment, même un serveur de terminal tampon ne le fait pas! mais ça donne un sacré combat! –

Restriction à l'aide de la fonctionnalité dlls nommée forte

Répondre

Questions connexes