复制保护静态库

时间:2010-01-10 22:15:51

标签: c++ linker copy-protection

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

理想情况下,我想阻止库被链接到可执行文件中,如果(并且只有!)库被非法复制到开发人员的机器上。这可能吗?

或者,如果链接到图书馆的非法副本的申请根本不起作用,则可以接受;但是,这对于这些应用程序的用户(例如输入许可证密钥,使用加密狗,甚至需要Internet连接)都没有负担,这一点非常重要。

该库是用C ++编写的,目标是许多平台,包括Windows和Mac。

我有任何选择吗?

9 个答案:

答案 0 :(得分:8)

我同意其他答案,即傻瓜式保护根本不可能。但是,作为一个轻柔的推动 ......

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

更改以下功能:

jeastsy_lib::init()

为:

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

第一个参数标识客户,第二个参数是第一个参数 MD5 hash或其他salt

购买图书馆后,您可以向客户提供这两个参数。

要明确,这对于聪明且充满野心的人来说是一种轻松避免的保护。考虑到这是盗版道路上的减速带。这可能会让潜在客户相信购买软件是最简单的前进道路。

答案 1 :(得分:7)

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

这是机器人切线,但这里应该提到IMO。有许多编译器选项需要与调用者匹配:

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

最多64个配置!

即使您的C ++代码与平台无关,它们也无法跨平台移植 - 它们甚至可能无法在同一平台上使用未来的编译器版本! LTCG创建巨大的 .lib文件。因此,即使您可以省略一些选择,您也拥有庞大的构建和分发大小,以及用户的通用PITA。

这是我不会考虑购买静态库附带的任何东西的主要原因,更不用说添加任何类型的复制保护了。


实施建议

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

您还可以对您的版本进行“水印”,这样,如果您“在野外”检测到某个库,您就可以确定将该图书馆出售给谁。 (但是,你打算做什么?给可能无辜的客户写愤怒的电子邮件?)另外,这需要一些努力,使用一个不易影响执行的易于定位的字节序列也无济于事。

你需要再次保护自己的LIB“拆包工具”。但是,链接器仍应能够删除未使用的函数。


一般性想法

实施一个体面的保护机制需要非常谨慎和一些创造力,我还没有看到一个不会产生额外支持成本并需要艰难的社交决策的单一机制。花在复制保护上的每小时花费一小时不用于改进您的产品。 C ++代码的市场并不是很大,我看到了很多客户必须付出的代价。

当我购买代码时,我很乐意支付文档,支持,源代码和其他“未来证明”的迹象。许可证并非如此。

答案 2 :(得分:4)

  

理想情况下,我想阻止库被链接到可执行文件中,如果(并且只有!)库被非法复制到开发人员的机器上。这可能吗?

您如何确定您的图书馆是否在链接时被“非法复制”?

请记住,当链接器工作时,您的代码都没有运行。

因此,鉴于您的代码都没有运行,我们无法在编译或链接时执行任何操作。这样就试图从完全不相关的目标机器中确定库是否被非法复制到链接机器上。即使你愿意在终端用户身上施加“需要互联网访问”这样的负担,我仍然没有看到任何使这两种情况可以区分的方法。

我的结论是,模糊棒棒糖的建议是“让人们想要购买它的东西非常有用”,这是“复制保护”你的代码库的最好方法。

答案 3 :(得分:2)

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

答案 4 :(得分:0)

你不能做你想做的事情(完美的复制保护,除了非法复制作品的人以外,不给任何人带来负担)。

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

这会留下运行时间,这意味着要求最终用户以某种方式进行验证,而您已经确定这是非启动性的。

你唯一的选择是:按原样出货,并希望开发人员不要复制太多,或者编写自己的链接器并尝试让人们使用它(以防万一它不明显:那不是没有正确思考的开发人员会购买需要特殊链接器的库。

答案 5 :(得分:0)

如果您计划发布昂贵的框架,可以考虑使用FLEXlm

我没有与他们联系,但他们已经在各种昂贵的框架中看到它,通常是针对Silicon Graphics硬件的。

答案 6 :(得分:0)

一些想法......(这些有一些主要的缺点虽然应该是显而易见的)

在编译时:将库文件放在共享上,并仅为您已将其出售的开发人员授予其文件权限。

对于运行时:编译库以仅在某些计算机上工作,例如。检查UID或MAC ID或其他东西

答案 7 :(得分:0)

  

我很快将发送一个付费的静态库

您问题的正确答案是:在您证明自己需要复制保护之前,请不要理会。

你说你“很快就会收到付费的静态库”。除非您已经证明您有人愿意窃取您的技术,否则实施版权保护无关紧要。一种不安的感觉“有人会偷走它”并不能证明它会被盗。

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

我不是说你的产品没有价值。我说,直到你试图出售它,你才会知道它是否有价值。

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

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

首先,证明有人想偷你的产品。然后,如果有人想要窃取它,请添加复制保护并继续改进您的产品。

答案 8 :(得分:0)

我只做过一次。这就是我使用的方法。这远非万无一失,但我认为这是一个很好的妥协。它类似于Drew Dorman的答案。

我建议提供一个初始化例程,该例程要求用户提供其电子邮件以及链接到该电子邮件的密钥。然后,使使用该产品的任何人都可以查看电子邮件信息。

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

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

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

  2. 他们可以通过签发刻录机电子邮件来规避此问题,但是随后他们没有将电子邮件与他们确实撰写的产品相关联,因此这似乎不太可能。

  3. 如果分发了带有刻录机电子邮件的版本,则人们可以尝试使用它,然后决定要使用它,但是需要与电子邮件相关联的版本,因此可以购买副本。免费广告。您甚至可能希望自己做。

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

要扩展Drew的答案-为此,您需要在用户注册时接收用户的电子邮件,在最后标记一个秘密字符集,然后对其进行哈希处理。您给用户散列。所有用户的秘密字符集都是相同的,并且对于您的库是已知的,但是电子邮件使哈希值变得唯一。当用户使用其电子邮件和哈希值初始化库时,您的库将附加字符,对其进行哈希处理,然后根据用户提供的哈希值检查结果。这样,您无需为每个用户都进行自定义构建。

最后,我觉得没有什么比这更徒劳的了,因为真正想破解我的图书馆的人可能比我捍卫它更好。这种方法只是阻止了一个随意的偷懒者轻易拿走我的图书馆。