保护装配?

发布于 2024-08-20 23:20:47 字数 91 浏览 5 评论 0 原文

我有一个 .NET DLL (C#/VB),带有自定义控件、扩展和其他内容。

我希望它只能供我使用。 有什么方法可以限制对 DLL 的未经授权的访问吗?

I have a .NET DLL (C#/VB) with custom controls, extension and other stuff.

I want that it should be available for me only.
Is there any way to restrict unauthorized access to a DLL?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

温馨耳语 2024-08-27 23:20:47

好吧,首先不要重新分发程序集。一旦组装在野外出现,任何人都可以使用它。您可以通过混淆来使其变得更加困难,但“入口点”仍然存在并且可用。

从理论上讲,您可以使用 CAS 执行某些操作,但我不太确定这是完全正确的可能的。

Well, do not redistribute the assembly in the first place. As soon as assembly is out in the wild, anybody can use it. You can make this harder by obfuscating it, but "entry points" will still be there and usable.

Theoretically, you can do something with CAS, but I'm not particularly sure this is at all possible.

棒棒糖 2024-08-27 23:20:47

正如 Anton 指出的那样,最好的选择是打包/加密/混淆 DLL。然后祈祷没有人会经历拆包的所有麻烦。

通常的术语就是“打包”。

这就是游戏开发人员使用 f.ex Sony 的 SecuROM 所做的事情。

但所有打包程序都有相同的缺点:

  1. 它们可以被逆向工程,并且加密密钥必须嵌入到二进制文件中
  2. 它们通常需要花钱,而那些不需要的(UPX)很容易解压。
  3. 解包过程可能会引入平台不兼容问题。
  4. 加壳的二进制文件往往会吓坏防病毒软件。

使用加壳器的公司通常会提供必须能够在每台可以想象的计算机上运行的二进制文件。如果你真的这么想,我想你可以用唯一的密钥加密每个 dll,然后要求它在解密阶段通过互联网访问运行,以实现一些挑战-响应魔法。无论如何,都太过分了。

您也可以制作自己的打包机,但请相信我:您不想去那里;)

简而言之,即使对于大玩家来说,您想要的东西也不容易实现。 SecuROM 游戏需要多长时间才能出现在 Piratebay 上?所以你唯一能做的就是“提高标准”并希望不被优秀的逆向工程师注意到。

最后,知道你要做什么:这对你来说值得吗?假设您将未打包的 DLL 发送出去 - 就这样。人们仍然需要对其进行逆向工程才能使用它。到底谁使用未记录的第三方库?我只在精神错乱的时候做过一两次这样的事。

Your best option is to pack/encrypt/obfuscate the DLL as Anton pointed out. And then pray that nobody will go through all the hassle of unpacking it.

The usual term for this is simply "packing".

This is what game developers do with f.ex Sony's SecuROM.

But all packing programs have the same drawbacks:

  1. They can be reverse-engineered and the encryption key must be embedded in the binary
  2. They usually cost money, and those that don't (UPX) are easily unpacked.
  3. Platform incompatability issues can be introduced by the unpacking process.
  4. Packed binaries tend to freak Anti-viruses out.

Companies that use packers usually ship binaries that must be able to run on every thinkable computer. If you really meant it, I guess you could encrypt every single dll shipped with a unique key and then require it be ran with internet access for some challenge-response magic during the decryption phase. Overkill at any rate.

You could also make your own packer, but believe me when I say it: You don't want to go there ;)

In short, what you want is not simple to achieve even for the big players. How long does it take for a SecuROM game to show up on piratebay? So the only thing you can do is "raise the bar" and hope to go unnoticed by the good reverse-engineers.

Lastly, knowing what you're getting yourself into: Will it be worth it for you? Let's say you shipped the DLL unpacked - as it is. People will still need to reverse-engineer it to use it. Who uses undocumented 3rd-party libraries anyway? I've only done that once or twice in moments of insanity.

紫南 2024-08-27 23:20:47

也许您可以使用许可/复制保护工具来更改您的 dll。在调用者内部,您提供所需的许可证号。

Perhaps you can use licensing/copy protection tools to alter your dll. And inside the caller, you supply the required license number.

海夕 2024-08-27 23:20:47

这并不完全可能。如果您希望代码运行,它必须是可执行的。您可以添加检查、打包、加密密钥、看门狗、监视器、管理员和各种许可方案,但最终,如果您的代码有效,则必须以某种方式解锁才能使用。

这就是 DRM 不起作用的原因。您想要保护 X,但希望其他人查看它。问题是您不希望查看/使用 X 的人与您希望使用 X 的人在某种程度上是同一个人

我厌倦了处理第 3 方许可代码(破坏/取消注册/认为我应该是合法用户),因此我成为了 FSF 会员。不值得我花时间去解决别人的限制,也不值得我花时间去处理它们。他们的代码并没有那么特别。

This is not completely possible. If you want your code to run, it has to be executable. You can put in checks, packing, encryption keys, watchdogs, monitors, wardens, and various licensing schemes but at the end of the day if your code works it has to be unlocked somehow so that it can be used.

This is why DRM doesn't work. You want to protect X, but you want someone else to view it. The problem is the person you don't want viewing/using X and the person you do want using X are, at some level, the same person.

I got so fed up with dealing with 3rd party licensing code (breaking / unregistering / thinking I wasn't a legit user when I was supposed to be) that I became an FSF member. It's not worth my time to work around someone else's restrictions, and it's not worth my time to deal with them. Their code wasn't all that special.

所有深爱都是秘密 2024-08-27 23:20:47

如果您对程序集进行强命名,请考虑使用 PublisherIdentityPermissionAttribute 。您可以将其添加到 DLL 中,并且只有使用正确的发布者密钥签名的程序集才能调用该方法或类。

这是免费的并内置于 .NET 框架中。如果您需要其他功能(例如将 DLL 许可给其他开发人员的能力),请考虑使用专业级别的复制保护工具,例如我们的工具 部署LX 许可

If you're strong naming your assemblies, consider using the PublisherIdentityPermissionAttribute. You can add this to your DLL and only assemblies signed with the right publisher key will be able to call into that method or class.

This is free and built into the .NET framework. If you need additional features (like the ability to license the DLL to other developers) consider a professional level copy protection tool like our tool DeployLX Licensing.

被你宠の有点坏 2024-08-27 23:20:47

您必须在 DLL 中添加检查以验证调用者是否是您。但这带来了其他挑战:

如何向 DLL 证明您就是您。 (您可以检查一些更简单的内容,例如当前用户名,但这可能并不完美)。

您可能要求 exe 文件由您的证书签名。

You have to add checks in the DLL to verify that the caller is you. But that raises other challenges:

How do you prove that you are you to a DLL. (You could check for something simpler like the current username, but that may not be perfect).

You could require that the exe file is signed by your certificate.

旧竹 2024-08-27 23:20:47

您应该检查许可基础设施。我不知道如何实现它,但是您可以通过创建 .licx 文件来使用它,然后我认为构建过程使用 lc.exe 工具来执行一些操作来嵌入许可证。

You should check out the licensing infrastructure. I have no idea how to implement it, but you use it by creating a .licx file and then, I think, the build process uses the lc.exe tool to do something to embed the license.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文