【问题标题】:How to protect application against duplication of a virtual machine如何保护应用程序免受虚拟机的复制
【发布时间】:2010-09-13 09:03:41
【问题描述】:

我们使用硬盘和 CPU ID 等标准项目将我们的软件许可锁定到物理硬件。我们如何降低客户安装到虚拟机然后克隆虚拟机、绕过我们的许可的风险?

【问题讨论】:

  • 正如下面提到的,基于硬件的锁定即使对于付费用户来说也是一种痛苦。我宁愿以某种方式检查另一台计算机是否在网络上的其他地方使用相同的许可证(许可证还表明允许有多少用户使用它)并且如果许可证被否决,则会默默地失败:只是让你的程序崩溃,而不是那么明确例如错误信息。如果发生这种情况,付费客户会与您联系,盗版者只会转移到另一个软件...

标签: licensing virtual-machine


【解决方案1】:

如果您的软件需要在虚拟机上运行,​​那么这个概念如何:

  • 在主机上创建一个编译的程序,例如运行。每半小时读取一次硬盘和 CPU ID,然后将其与当前时间戳以及所有这些信息的加盐哈希一起存储在一个文件中。
  • 然后,您需要与 VM 共享包含该文件的文件夹。
  • 然后,您可以在 VM 中的已编译软件中读取此文件并检查时间戳是否为最新且哈希是否有效。

或者更好的是,让主机程序以某种方式直接与 VM 中的软件通信。

这不是一个好的解决方案吗?不如使用硬件密钥(如 Yubikey)安全,但您必须非常精通技术才能破解它...?

【讨论】:

    【解决方案2】:

    您需要计算机“硬件”之外的东西来进行身份验证。大多数公司选择硬件密钥(加密狗)来购买成本高的软件,用户会忍受它。

    其他公司使用在线方法 - 如果多个具有 CPUID 和其他硬件的用户同时使用给定许可证,则禁止另一个实例化,或关闭现有实例化。

    您必须根据您的需求和消费者愿意跳过您的反盗版圈来选择保护。

    -亚当

    【讨论】:

    • 如果加密狗可以在一个虚拟机上运行,​​它可以在多个虚拟机上运行。因此,除非您打算禁止虚拟化(这是目前限制销售的举措),否则我认为加密狗不会起作用。
    • @david - 加密狗设备,尤其是 USB,不能被克隆的虚拟机同时共享,这就是 OP 所指的。
    • 如果您可以检测到重复的 CPUID,那么无论如何都没有理由来阻止具有相同 CPUID 的两个实例:只需将其视为两个实例并完成它!跨度>
    【解决方案3】:

    一种方法是拥有一个许可服务器。当您将许可证代码输入客户端(在 VM 上)时,它会联系服务器并将其许可证代码和其他信息发送给它。它反复联系它(您定义间隔 - 可能每隔几个小时一次)询问“我仍然有效吗”?随着这个请求,它发送一个唯一的 ID。服务器回复“是的,你是有效的”,并发送一个新的唯一 ID 发回给客户端。客户端将这个唯一 ID 连同其下一个请求一起发回给服务器。服务器验证这是它为该许可证发送给客户端的相同 ID,即上一个请求。

    如果虚拟机是重复的,下次它询问服务器“我有效吗?”时,它或其他虚拟机的唯一 ID 将不正确。两者都不会继续工作。

    您需要确定如果服务器出现故障或网络出现故障,客户端无法与服务器通信时该怎么做。您是否立即禁用您的软件?馊主意!不要让你的客户生气。你会想给他们一个宽限期。这应该多长时间?几天?几周?

    假设您给他们 1 个月的宽限期。理论上,他们可以在输入许可证密钥后克隆父虚拟机,然后在其他虚拟机的宽限期到期之前将其恢复到该克隆,从而禁用对它们的网络访问。但是,这对您的客户来说会很麻烦,只是盗版了您的软件的其他副本。您必须确定什么样的宽限期不会给您的合法客户带来麻烦,同时希望能够为您提供所需的保护。

    可以通过验证虚拟机的时钟设置是否正确来实现额外的保护。这将防止上述盗版方法。

    另一个考虑因素是,精明的用户可以编写自己的许可服务器来与 VM 实例通信,并告诉他们所有人“你很好”——因此加密通信可以帮助阻止这种情况。您想在这里走多远实际上取决于您认为盗版确实可能对您的客户造成多大的问题。最终,您将无法阻止真正的盗版者,但您可以让诚实的用户保持诚实。

    【讨论】:

    • 如何处理回滚到快照、恢复备份或重新启动 docker 映像?在所有这些情况下,旧的唯一 ID 都应该是无效的。
    • 是的,您必须构建管理功能,让用户可以“重置”他们的机器。重置它会为服务器和客户端提供一个全新的唯一 ID,并再次开始同步过程。
    • 我可以知道该唯一 ID 将保存在客户端的什么位置。如果该唯一 ID 保存在文件或内存中,它会再次复制到新克隆的虚拟机,对吗?
    • @KalyanKumar 是否将其复制到新虚拟机并不重要。无论哪个客户端下一次与服务器通信,该客户端将成为“授权”客户端,当下一个客户端尝试通信时,唯一 ID 将不同,它将被取消授权。
    【解决方案4】:

    “不要打扰”是简短的版本。对于您的客户而言,这样做并非易事收取太多费用(就像您在欺诈一样。)

    “真正的”客户通常会为这些东西买单。据我所知,像企业这样的地方通常会认为不值得付出努力。

    【讨论】:

    • 不正确。存在三种不同类型的用户: a) 那些永远不会盗版软件的人,要么是出于道德考虑,要么是因为它不值得费心。 b)如果很容易盗版(即仅克隆您的软件已获得许可的快照虚拟机),就会盗版的人。 c) 那些有能力破解您想要实施的任何反盗版机制的人。为“B”类用户提供基本保护是有意义的。不要太担心 C —— 他们总会找到办法的。
    • 我断言,无论您的技能如何,克隆虚拟机都不会构成“容易做到”,因为运行应用程序最终会很痛苦。其他“容易”的门槛可能不同,但我认为(没有证据)足够重要。
    【解决方案5】:

    没有充分的理由锁定到物理机。最后我检查了计算机可能会发生故障,然后用户可能不仅会因为计算机死机而感到不便,而且不得不打电话给您将软件锁定到新机器上。如果您必须进行严格的许可证管理,请使用(本地)管理服务器并运行副本,每隔几分钟验证他们是否拥有许可证。只要意识到,如果有人真的想在不付钱的情况下使用您的软件,那么无论您做什么,他们都会找到方法。

    【讨论】:

      【解决方案6】:

      这是一个问题,任何精明的用户都可以击败你所做的任何事情。不精通的用户可能会被诸如 VmWare 播放器之类的行为所吸引,当您移动它时,它会更改虚拟机的 MAC 和其他 ID,大概是为了解决这类问题。

      最好的解决方案可能是使用许可证服务器,因为该服务器会计算活动许可证的数量。节点锁定更容易被击败,并且使用服务器也倾向于将责任推给 IT 部门,与只想尽快完成工作的个人用户相比,IT 部门对不违反许可协议更为敏感。

      但最后,我同意这一切都归结为正确的许可语言,并让客户在一定程度上得到信任。如果您认为人们以这种方式愚弄您,那么您一开始就不应该向他们出售您的软件......

      【讨论】:

      • 我认为 MAC 更改是出于更实际的原因,实际上:如果两个具有相同 MAC 地址的 VM 连接到相同的(虚拟)以太网会发生什么?跨度>
      【解决方案7】:

      许可证。告诉您的用户,他们不得运行未经许可的副本。

      实际上,我们目前未能购买软件许可证,因为供应商害怕虚拟机:我们部门的基础架构正在迁移到集中式虚拟化解决方案,我们已经争取让供应商允许为其软件购买许可证!

      不要害怕付费用户。

      太便宜购买许可证的人会寻找另一种解决方案,无论如何都会太麻烦。

      (祝你好运告诉你的老板,不过……)

      【讨论】:

      • 我同意,盗版者就是盗版者——严厉的许可安排只会伤害真正的最终用户。
      • 不完全——良好的许可方案有助于保持诚实的客户诚实,因为它有助于管理层评估使用情况,从而适当地支付给您。
      • @jake:同上,许可服务器允许拥有更多许可的工作站。
      【解决方案8】:

      如果您的软件在虚拟机下运行,那么它将在任意数量的克隆虚拟机下运行。因此,唯一的选择似乎是完全阻止它在 VM 下运行。这是一篇关于虚拟机检测的文章:Detect if your program is running inside a Virtual Machine 和一篇关于 thwarting 的文章。

      顺便说一句,克隆虚拟机通常足以阻止临时用户绕过您的许可,而那些一心想破解的人可能会找到绕过它的方法。

      【讨论】:

        【解决方案9】:

        我知道一些虚拟机软件(至少是 VMware)具有允许软件检测虚拟化的功能。但是没有万无一失的方法,无论如何都可以修补这些功能。还可以使用神秘的性能变化(由于主机中的 CPU 峰值),可靠性值得怀疑。有很多“被虚拟化的迹象”,但它们往往不是 100% 可靠的。

        【讨论】:

          【解决方案10】:

          除了需要定期在线激活之外,您可以做的 AFAIK 并不多。

          我们遇到了诺顿重影物理机器的问题。显然 HDD 序列号也是幻影。

          【讨论】:

            猜你喜欢
            • 2015-11-13
            • 1970-01-01
            • 2012-01-26
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2011-06-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多