使用程序集作为许可证文件的优点/缺点？
我最初打算使用签名的序列化 xml 文件来存储许可证详细信息。 在规划中，越来越多的内容已转移到此“许可证文件”中，这将使我们能够分发单个应用程序并通过提供的许可证文件控制可用功能。
用户界面和打印报告与分销商徽标是联合品牌的，因此如果可以将其嵌入到许可证中就好了。我知道这可以通过序列化的 xml 文件来完成，但我想知道将此数据存储在已编译的程序集中有哪些优点和缺点？
许可证生成工具可以使用适当的属性和资源来编译程序集并对其进行签名。
更新
据我所知，使用序列化 xml 或程序集非常相似。从我的角度来看，程序集允许我添加其他资源，并为未来留下一些灵活性。一旦资源变得复杂，xml序列化就很痛苦。
更新2
该软件仅适用于我们的硬件，因此许可证安全性并不是一个大问题。主要目的是阻止临时用户启用他们未付费的功能。为了设计简单性，我会选择其中之一！
I was initially going to use a signed serialized xml file to store license details.
In planning, more and more has moved into this "license file" which will allow for us to distribute a single application and control available functions via the supplied license file.
The UI and printed reports are co-branded with distributors logos, so it would be good if this could be embedded into the license. I know this could be done with the serialized xml file but I was wondering what are the pros and cons of storing this data in a compiled assembly?
The license generation tool could compile the assembly with the appropriate properties and resources and sign it.
Update
From what I can see, using serialized xml or an assembly would be pretty similar. From my point of view, assemblies would allow me to add other resources and leaves some flexibility for the future. As soon as the resources get complicated, xml serialization is a pain.
Update2
The software only works with our hardware so licence security is not a massive concern. The main aim is to stop the casual user from enabling features that they have not paid for. I would be choosing one over the other for design simplicity!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
签名的 xml 许可证文件没有什么优点，但它们可能不适用于您的情况：
如果您没有任何这些特定需求，请选择“程序集即许可证”选项，因为它更易于实施。
更新
查看我之后出现的其他答案 - 对本地计算机上运行的软件的完美保护不存在，并且很可能在很长一段时间内不存在。不要花费太多时间来保护您的软件，因为如果有人真的非常想免费使用它，他就会找到一种方法来做到这一点。让用户有更多理由使用您的应用程序并简化购买体验。
在 dll 或外部 xml 文件中签署许可证就足够了。
A signed xml license file has few advantages, but they may not be applicaple to your situation:
If you don't have any of these specific needs, go with the assembly-as-a-license option, as it's simpler to implement.
Update
Looking at other answers that popped up after mine - a perfect protection for software running on a local computer does not exist and will likely not exist for a very long time. Don't spend too much time on protecting your software, because if anyone really, really wants to use it for free, he will find a way to do so. Give the users more reasons to use your application and simplify the buying experience.
Going with signing the license in a dll or an external xml file is good enough.
您可以使用程序集代替许可证文件，但您不应该这样做。始终可以从程序集中删除数字签名；现在使用 Reflexil 工具就很简单了。
有关更多详细信息，请参阅文章CAS 防篡改已损坏：软件许可的后果。
You could use an assembly in lieu of a licence file, but you shouldn't. It has always been possible to remove the digital signing from an assembly; now it's trivial using the Reflexil tool.
See the article CAS Tamper-Proofing is Broken: Consequences for Software Licensing for more details.
一直对我有用的一个好的解决方案是创建一个许可证类，其中包含所需的所有属性，例如名称、到期时间、徽标等。将类序列化为内存中的二进制数据，然后对其进行加密并保存到文件中。这样做不需要签名，并且文件具有防黑客能力。要读取您的许可证，只需执行相反的操作：读取文件、解密、反序列化。对此需要注意的是，如果多个程序集要读取此许可证文件，则加密/解密函数应位于单独的共享程序集中。
A good solution that has always worked for me is to create a license class with all the properties needed such as name, expiration, logos and such. Serialize the class to binary data in memory, then encrypt that and save to a file. Doing it this way doesn't require signing and the file is hack resistant. To read your license simply do the reverse, read the file, unencrypt, unserialize. One caveat to this is that if multiple assemblies are going to read this license file, then the encrypt/unencrypt functions should be in a separate shared assembly.
我不会使用程序集作为许可证文件 - 正如其他人指出的那样，破坏它相对微不足道。
我会使用一个文件（xml 或其他文件），然后将其锁定到用户计算机。这可以通过多种方式实现：
1）使用 System.Cryptography.ProtectedData - 这只是包装 Windows DPAPI 并使用 Windows 密钥存储（每个用户或每个本地计算机）。这是一种简单的方法，但您必须使用 Encoding.UTF8.GetString （或任何您的编码）从字节数组转换回来。这很简单，但不是工业强度，因为有人仍然可以挖出密钥库等。
2) 使用机器唯一 ID（例如具有对称算法（例如 Rijndael 或 Blowfish）的 SID，并提供未加密许可证文件的 SHA-256 哈希值作为 IV。这实现起来有点复杂，因为您需要使用 WMI 来查找 SID，然后使用 System.Security.Cryptography.RijndaelManaged 等来进行加密/解密。
I wouldn't go with using an assembly as a license file - as others have pointed out it's relatively trivial to break.
I would use a file ( xml or whatever ) then lock it to the users machine. This can be achieved in several ways :
1) Use System.Cryptography.ProtectedData - this just wraps the Windows DPAPI and uses the windows key store ( either per user or per local machine ). This a simple(ish) approach but you will have to using Encoding.UTF8.GetString ( or whatever your encoding is ) to convert back from a byte array. This is simple but not industrial strength as someone could still dig out the key store etc.
2) Use a machine unique ID such as the SID with a symmetric algorithm such as Rijndael or Blowfish and provide the SHA-256 hash of the unencrypted license file as the IV. This is a bit more complex to implement as you'd need to use WMI to find the SID and then use System.Security.Cryptography.RijndaelManaged etc to do the encryption/decryption.
我认为使用该程序集很有创意，但更容易进行逆向工程。使用反射器打开应用程序后，检查许可证的所有位置都可以识别为许可证类别上的属性读取。我看到的另一个问题是版本控制。当 2.0 版本到来时，您的营销团队可能会要求您接受 1.0 许可证。您的 2.0 软件可能有一个带有额外属性的新许可证类别，该许可证类别不再与该类别的 1.0 版本互换。当然，您可以为此制定解决方法，但这会破坏原始设计的简单性。
I think using the assembly is creative, but easier to reverse-engineer. After you open the application with reflector, all locations that check the licenses are recognizable as property reads on the license class. Another problem I see is versioning. When version 2.0 comes, your marketing team might require you to accept 1.0 licenses. Your 2.0 software may have a new license class with extra properties which is no longer interchangible with the 1.0 version of the class. You can make workarounds for that, sure, but it will kind of defeat the simplicity of the original design.
我更喜欢程序集版本，因为：
但请记住。这只是一个软件保护。下一步是使用加密密钥（hasp，马克思...)
I would prefer the assembly version because:
But remember. It’s just a software protection. The next step would be to use a crypto key (hasp, marx…)