(C#/C++ CLI) 是否可以保护我的 C++ CLI 程序集是否被用于其他 .NET 项目？
我为本机 C++ 代码创建了一个 C++ CLI 包装器，我又在我的 C# 应用程序中引用了该代码。是否可以以某种方式保护该程序集，以便它只能在我的应用程序中使用，而其他人不可能使用它？
我是一名微软技术开发人员，我很自私:)
I have created a C++ CLI wrapper for native C++ code, which in turn I reference in my C# application. Is it possible to somehow protect this assembly so that it may only be used in my application without the possibility of someone else using it?
I'm a Microsoft technology developer, I'm all about selfishness :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
并不完美。 LinkDemand 仅在部分信任环境中强制执行。以完全信任方式运行的代码还可以使用反射来访问私有类型，并且通常会绕过您想要讨论的任何保护。
也许您希望 C++/CLI 代码调用 Assembly::GetEntryAssembly 并根据该库所针对的已批准应用程序的白名单进行检查。
当然，您希望最大限度地减少检查中涉及的托管代码（和属性）的数量，因为托管代码确实很容易反编译。
实际上，将偶尔的检查混合到 C++ 代码的核心逻辑中是确保它不会被绕过的唯一希望。
Not perfectly. LinkDemand is only enforced in a partial trust environment. Code running with full trust can also use reflection to access private types, and generally bypass any protection you care to discuss.
Maybe you want your C++/CLI code to call Assembly::GetEntryAssembly and check it against a whitelist of approved apps for which the library is intended.
Of course, you want to minimize the amount of managed code (and attributes) involved in the checks since managed code is really easy to decompile.
Actually, mixing the occasional check into the core logic of the C++ code is the only hope you have that it won't be bypassed.
我已经使用了 这项技术取得了成功。
基本上，它是通过提出链接时安全要求并使用程序集强名称的公钥作为证据来保护程序集不被加载。只有使用您的私钥签名的程序集才能加载它。
I have used this technique with success.
Basically, it's about protecting your assembly from being loaded by placing a link-time security demand and using the assembly strong name's public key as evidence. Only assemblies signed with your private key will be able to load it.
是的，但这对于坚定的攻击者来说将是一场失败的战斗。
例如，您可以提供仅接受特定密钥的加密版本，正如某些人所建议的那样。但是，您需要在客户端上解密它，而客户端可能没有加密的内存存储，因此坚定的攻击者可以简单地读取适当的内存块并反序列化结果以获得原始程序集。
Yes, but this will be a losing battle against a determined attacker.
For example, you could provide an encrypted version that only accepts a particular key, as some people have suggested. But then you'll need to decrypt it on your clients, who may not have encrypted memory stores, so a determined attacker could simply read the appropriate block of memory and deserialize the result to get your original assembly.