如何使用CD密钥/序列号保护我的游戏?


25

因此,我决定通过断开与错误或生成的,重复的或被禁止的CD的客户端的连接,以防止我的XNA游戏的盗版副本访问官方游戏服务器(经过审核,因此为游戏付费的人将获得最好的体验)。键(或序列号,因为游戏是数字游戏,没有CD)。

如何将序列号保护系统(包括客户端和主身份验证服务器)放入我的游戏,因此不容易被黑客入侵?


请注意,我没有为软件提供良好保护的经验。

我以前从未做过,但是我了解基本知识。我知道为什么我不能在客户端上进行密钥检查,所以我可以将登录/通过身份验证与一次性密钥输入结合使用。

当前,此保护的目标是防止潜在的作弊者,并破坏玩家的行为,使其脱离官方服务器。任何人都可以在带有或不带有钥匙的私人服务器上玩游戏,但是他们获得与其他玩家的不愉快体验的机会更大。我想购买玩家很容易,因为他们必须在线才能在官方服务器上玩。

因为黑客客户端太容易了,所以我将只保护初始注册(可能还有服务器端身份验证)过程,因此在传输密钥时没有人可以窃取密钥。


也可以看看:

多人游戏应如何处理身份验证?


如果有人投票反对,我希望至少对此问题有何评论。伙计们,真的,我希望我的问题很好,并能帮助更多的人,而不仅仅是我。
user1306322

4
我猜这是对添加DRM的自动反应。这种类型并不是特别糟糕,但是我们中的许多人对此都有不好的经验-例如,当Spore使Windows安装失败时。
2013年

您是否考虑过使用类似MMO / Minecraft的方法来代替CD密钥,该方法要求用户名/密码登录并使用它来验证用户身份?
Tetrad

4
想要在.NET应用程序上使用DRM !?最终将无法使用Reflector之类的工具。看看Terraria。由于盗版(和大量收入...),开发已停止。我喜欢@Tetrad基于身份验证的想法,因为它可以防止人们只需要修补验证功能。将所有数据保留在您的服务器上,并在他们成功登录后,将数据提供给他们。如果将数据保留在本地,则它们可以修补身份验证功能。

2
@Anko引用了著名的名言“我们需要更多的矿物质”。我的意思是事实和专业知识。甚至细节。我不知道什么时候一个重要的问题会引起足够的重视,只是感觉好像需要添加一些东西,网站的访问者可能会发现这个主题很有趣(并有可能成为新用户),所以我提出了很多建议。
user1306322 2013年

Answers:


24

基本上,您有三个要求:

  1. 在多个客户端实例中使用相同的密钥并不容易,
  2. 生成新的有效密钥应该不容易,并且
  3. 窃取合法客户的钥匙应该不容易。

第一部分应该非常简单:只是不要让两个玩家同时使用相同的密钥登录到同一服务器。您还可以让服务器交换有关已登录用户的信息,或与共享的身份验证服务器联系,这样即使在不同服务器上同时为不同播放器使用相同密钥也将失败。您可能还需要查找可疑的密钥使用方式,如果确定密钥已泄漏,请将其添加到禁用密钥列表中。


对于第二部分,一种方法是简单地维护所有有效已发行密钥的数据库。只要密钥足够长(例如128位或更多)并被随机选择(使用安全RNG),任何人设法猜出有效密钥的几率就基本上为零。(如果对失败的登录尝试使用某种速率限制,以阻止通过蛮力找到有效密钥的尝试,那么即使短得多的密钥也可以安全。)

或者,您可以通过获取任何唯一标识符并添加消息身份验证代码来生成密钥。使用秘密主密钥计算(例如HMAC)来生成密钥。同样,只要MAC足够长,任何不知道主密钥就能猜测任何ID的有效MAC的人的几率就可以忽略不计。除了不需要密钥数据库之外,此方法的一个优点是标识符可以是任何唯一的字符串,并且可以对有关为其颁发密钥的客户端的信息进行编码。

使用MAC的一个问题是,官方游戏服务器(或至少是身份验证服务器)需要知道主密钥才能验证MAC,这意味着,如果服务器被黑客攻击,则主密钥可能会泄漏。减轻这种风险的一种方法是,使用不同的主密钥为每个ID计算多个MAC,但仅将其中一个主密钥存储在游戏服务器上。这样,如果该主密钥曾经泄漏并用于生成伪造的ID,则可以将其吊销并切换到另一个主密钥。或者,您可以用数字签名替换MAC。,仅可以使用主密钥的公共一半来验证。


对于第三部分,一种方法是确保客户端在不验证接收者确实是合法的官方服务器的情况下不会将其密钥发送给任何人。例如,您可以使用SSL / TLS(或在登录过程中 DTLS),为游戏服务器颁发自定义证书,并且仅由您颁发客户端信任证书。方便地,使用TLS还可以保护客户端密钥(以及任何其他身份验证数据)免受窃听,例如在公共WLAN上。

不幸的是,即使第三方服务器愿意,这种方法也无法让第三方服务器验证客户端密钥。您可以通过设置第三方游戏服务器可以使用的官方身份验证服务器来解决此问题,例如,通过让客户端登录到身份验证服务器并获得随机的一次性令牌,他们可以使用该令牌登录到游戏服务器(然后将令牌提交给身份验证服务器以进行验证)。

或者,您可以向客户颁发实际的客户证书或类似的证书。您可以使用支持客户端证书认证(推荐)的现有协议(例如TLS),也可以实现自己的协议,例如:

  • 客户端证书由任意ID字符串,公共/专用密钥对以及使用主密钥的ID和公共密钥的数字签名组成。
  • 要登录,客户端发送其ID,公钥和签名。服务器用唯一的质询字符串(最好包括服务器ID和时间戳,客户端应验证该字符串)进行答复,客户端用私钥对其进行签名(以证明他们知道密钥)并将签名发送给服务器。
  • 服务器检查两个签名,以证明ID +公钥构成合法的客户端密钥(因为它们是用主密钥签名的),并且该客户端密钥实际上属于客户端(因为客户端可以用私有签名服务器的质询)键)。

(可以通过使客户端生成由服务器ID和时间戳组成的“挑战”并对其进行签名来进一步简化此协议。当然,然后服务器需要验证ID和时间戳是否有效。也请注意,这个简单的协议本身不会阻止中间人攻击者劫持客户端的会话,尽管它将阻止他们获取将来登录所需的客户端私钥。)


2
一个小问题-虽然完全随机的密钥提供了最大的密钥空间(并且如果您要对发布的密钥的数据库进行验证,这是完全可行的),但它并不友好。在密钥本身中进行一些验证,以便在尝试访问服务器之前捕获大多数错误类型。
罗伦·佩希特尔

我确实认为,@ LorenPechtel对密钥的用户友好性有一个强项,并且付费用户无意中键入并向服务器发送“错误键入/拼写错误”(typo)密钥总是可能的。
Vishnu

@Vishnu我知道作为输入密钥的用户,我更希望每个组都有一些检查信息,即使那意味着要键入更长的密钥。
罗伦·佩希特尔

16

没有100%的节省,但是您可以从一个相当简单的方法开始:

  • 您需要某种方式来验证生成的密钥,例如包含的校验和。当然,这一定不太容易弄清楚。

  • 可选(但建议),服务器端数据库将使用所有给出的密钥的数据库来验证密钥,因此即使您碰巧拥有算法,也无法生成密钥(让我们忽略暴力破解)。

从那里开始,您可以有两种不同的方法,但是无论哪种方式,都很重要:

  • 不要在客户端验证密钥。这非常重要,因为反编译用.net / XNA编写的内容实际上相当容易。如果您需要询问密钥或将其传递(登录或注册),则对密钥进行哈希处理(添加盐等)并将其发送到服务器。

至于实际路径:

  • 要求在认证/登录过程中发送散列密钥(请参见上文)。

  • 作为替代方法(IMO更好,尽管许多人不喜欢这种“ DRM”):根本不要在客户端中使用密钥。相反,要求用户登录到帐户并需要有效的CD密钥(这需要上述数据库)才能创建帐户。这就是现代游戏(例如任何付费MMORPG)如何处理此问题的方式。

就个人而言,我会采用帐户方法,原因很简单:最后,您不能阻止人们窃取CD密钥(强制,反向工程或欺诈)。这样,人们可以只创建一个新键来继续玩或将其他人拒之门外。使用帐户绑定密钥,任何人都无法使用已在使用的密钥进行任何操作。如果有人购买了他人生成的密钥,那么只要有足够的证据,您仍然可以转移帐户所有权。


2
代替标准校验和,应使用加密安全的哈希算法。您可以将私钥保留在服务器上,并为客户端提供公钥,然后您将知道,无需访问服务器,系统是安全的。
亚当

@Adam:使用密码安全的哈希算法将确保攻击者无法生成有效密钥,但是由负责分发合法密钥的机构同样无法解决该问题。虽然确实简单的校验和不是很安全,但是在这种情况下单向功能不可行。
Marcks Thomas

好吧,您可以将两者结合起来,例如,使密钥的第一部分成为字符的随机组合,而使后半部分成为哈希。任何销售游戏的人都无法使用密钥生成器(除非有某种方法可以确保不发生冲突/冲突,例如作为密钥一部分的“供应商ID”)。
马里奥

1

Pangea Software(几个Mac游戏的创造者)在其(现在免费的)游戏开发书中写了一个有关版权保护的主题。该书还介绍了如何处理盗版密钥和人们使用的其他黑客。该书着重于Mac游戏的开发,但是这些想法对于其他平台可能仍然有用。随书附带的是每一章的源代码,下面是下载的一部分。还包括与复制保护相关的源代码(用C编写)。

这本书可以在这里下载


我在那本书中找不到任何有用的东西。
user1306322 2013年

我个人虽然第16章有一些不错的技巧,但YMMV。
Wolfgang Schreurs,
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.