3

我很快就会发布一个付费的静态库，我想知道是否可以构建任何形式的复制保护来防止开发人员复制库。

理想情况下，如果（且仅当！）该库已被非法复制到开发人员的机器上，我想完全阻止该库被链接到可执行文件中。这可能吗？

或者，如果链接到库的非法副本的应用程序根本不起作用，这可能是可以接受的；然而，重要的是，这不会给这些应用程序的用户带来负担（例如输入许可证密钥、使用加密狗，甚至需要 Internet 连接）。

该库是用 C++ 编写的，面向包括 Windows 和 Mac 在内的许多平台。

我有什么选择吗？

4

9 回答 9

9

我同意其他答案，即万无一失的保护根本不可能。然而，作为一个温和的推动...

如果您的库是预编译的，您可以通过在 API 中要求自定义许可证信息来阻止过度非法使用。

更改如下功能：

jeastsy_lib::init()

至：

jeastsy_lib::init( "Licenced to Foobar Industries", "(hex string here)" );

其中第一个参数标识客户，第二个参数是第一个参数的MD5或其他带有salt的哈希值。

购买库时，您将向客户提供这两个参数。

需要明确的是，对于足够聪明和雄心勃勃的人来说，这是一种很容易避免的保护。认为这是盗版道路上的减速带。这可能会让潜在客户相信购买您的软件是最简单的前进道路。

于 2010-01-10T22:36:49.507 回答
7

C++ 静态库是一个非常糟糕的可再发行组件。

这是一个 bot 切线，但这里应该提到 IMO。有许多编译器选项需要匹配调用者：

  • Ansi/Unicode,
  • 静态/动态 CRT 链接，
  • 启用/禁用异常处理，
  • 成员函数指针的表示
  • LTCG
  • 调试/发布

多达 64 种配置！

此外，即使您的 C++ 代码与平台无关，它们也不能跨平台移植——它们甚至可能无法与同一平台上的未来编译器版本一起使用！LTCG 创建巨大的.lib 文件。因此，即使您可以省略一些选项，您也拥有巨大的构建和分发规模，以及用户的通用 PITA。

这就是我不考虑购买任何只附带静态库的东西的主要原因，更不用说增加任何形式的复制保护的东西了。

实施思路

我想不出比 Shmoopty 的建议更好的基本机制。

您还可以为您的构建“添加水印”，这样如果您“在野外”检测到一个库，您就可以确定您将那个库卖给了谁。（但是，您要做什么？给潜在无辜的客户写愤怒的电子邮件？）此外，这需要一些努力，使用不影响执行的易于定位的字节序列不会有太大帮助。

您需要保护自己免受 LIB“解包器”工具的侵害。但是，链接器应该仍然能够删除未使用的函数。

一般想法

实施一个体面的保护机制需要非常小心和一些创造性，我还没有看到一个不产生额外支持成本并且需要艰难的社会决策的机制。花在复制保护上的每一小时都不是改进产品的一小时。C++ 代码的市场并不十分庞大，我看到您的客户需要为大量工作付费。

当我购买代码时，我很乐意为文档、支持、源代码和其他“面向未来”的迹象付费。没有那么多的许可。

于 2010-01-10T23:29:22.160 回答
4

理想情况下，如果（且仅当！）该库已被非法复制到开发人员的机器上，我想完全阻止该库被链接到可执行文件中。这可能吗？

您如何确定您的库在链接时是否被“非法复制”？

请记住，当链接器完成其工作时，您的任何代码都没有运行。

因此，鉴于您的任何代码都没有运行，我们无法在编译或链接时做任何事情。剩下的就是试图确定库是否从完全不相关的目标机器非法复制到链接机器上。而且我仍然看不到任何方法可以区分这两种情况，即使您愿意给最终用户施加诸如“需要互联网访问”之类的负担。

我的结论是，fuzzy lollipop 的建议是“制作有用的东西以至于人们想要购买它”是“复制保护”您的代码库的最佳方式。

于 2010-01-10T22:28:18.617 回答
2

复制保护，在这种情况下，根据定义，执行保护“给用户带来了负担”。没有办法解决这个问题。最好的复制保护形式是写一些有用的东西，让人们不得不购买它。

于 2010-01-10T22:22:41.810 回答
0

你不能做你想做的事（完美的复制保护，除了非法复制作品的人之外，不会给任何人带来负担）。

您无法使用标准链接器在链接时运行代码，因此此时无法确定您是否正常。

这留下了运行时间，这意味着要求最终用户以某种方式进行验证，您已经确定这是一个非首发。

您唯一的选择是：按原样发布并希望开发人员不要复制太多，或者编写自己的链接器并尝试让人们使用它（以防万一它不明显：那是行不通的。没有头脑正常的开发人员会购买需要特殊链接器的库）。

于 2010-01-10T22:35:22.177 回答
0

几个想法......（这些有一些主要缺点，但应该很明显）

在编译时：将库文件放在共享上，并仅为您出售给它的开发人员授予文件权限。

在运行时：编译库以仅在某些机器上工作，例如。检查 UID 或 MAC id 或其他东西

于 2010-01-10T23:17:09.253 回答
0

如果您打算发布一个昂贵的框架，您可能会考虑使用FLEXlm。

我与他们无关，但在各种昂贵的框架中看到了它，这些框架通常针对 Silicon Graphics 硬件。

于 2010-01-10T22:59:11.457 回答
0

我很快就会发布一个付费的静态库

您的问题的正确答案是：在证明您需要它之前，不要打扰复制保护。

您说您“即将推出付费静态库”。除非您已经证明有人愿意窃取您的技术，否则实施复制保护是无关紧要的。“有人会偷它”的不安感觉并不能证明它会被偷。

创业最困难的部分是创造人们愿意买单的产品。你还没有证明你已经做到了；ergo 复制保护是无关紧要的。

我并不是说你的产品没有价值。我的意思是，除非您尝试出售它，否则您将不知道它是否有价值。

然后，即使你卖了它，你也不知道人们是否偷了它。

这就是成为一名优秀的程序员和成为一名优秀的企业主之间的区别。

首先，证明有人想窃取你的产品。然后，如果有人想窃取它，请添加复制保护并不断改进您的产品。

于 2016-02-05T19:01:07.927 回答
0

我只做过一次。这是我使用的方法。这远非万无一失，但我觉得这是一个很好的妥协。这类似于Drew Dorman的回答。

我建议提供一个初始化例程，要求用户提供他们的电子邮件和链接到该电子邮件的密钥。然后有一种方法，任何使用该产品的人都可以查看电子邮件信息。

我在为 AfterEffects 编写插件时使用的库上使用了这种方法。初始化例程为插件构建“关于”对话框中显示的消息，我让这个消息显示给定的电子邮件。

这种方法在我眼中的优点是：

  1. 客户不太可能传递他们的电子邮件和密钥，因为他们不希望他们的电子邮件与他们没有编写的产品相关联。

  2. 他们可以通过使用刻录机电子邮件注册来规避这种情况，但随后他们的电子邮件不会与他们编写的产品相关联，因此这似乎不太可能。

  3. 如果带有刻录机电子邮件的版本被分发，那么人们可能会尝试它，然后决定他们想要使用它，但需要一个与他们的电子邮件相关联的版本，因此可能会购买一份副本。免费广告。您甚至可能希望自己执行此操作。

我还想确保当我向一家公司提供插件时，根据我多年的专业知识，他们不能将我的库提供给他们的内部程序员自己编写插件。为此，我还将插件名称链接到密钥。因此，密钥仅适用于特定的插件名称和开发人员电子邮件。

为了扩展 Drew 的答案 - 为此，您在用户注册时接收用户电子邮件，在末尾标记一组秘密字符，然后对其进行哈希处理。你给用户哈希。所有用户的秘密字符集都是相同的，并且您的图书馆知道，但电子邮件使哈希值独一无二。当用户使用他们的电子邮件和哈希初始化库时，您的库会附加字符，对其进行哈希处理并根据用户提供的哈希检查结果。这样您就不需要为每个用户定制构建。

最后，我觉得任何比这更复杂的事情都是徒劳的，因为真正想要破解我的图书馆的人可能会比我更擅长捍卫它。这种方法只是阻止一个随便的盗版者轻易地拿走我的图书馆。

于 2019-03-14T13:22:21.333 回答