使用公钥证书激活产品

发布于 2024-11-29 09:42:58 字数 157 浏览 3 评论 0原文

我需要一些如何创建激活算法的想法。例如我有演示证书。前提是应用程序在演示模式下运行。当提供完整版本证书时,应用程序以完整模式运行。 这是否可能?创建这个系统的好方法是什么?

一个简单的想法是,我想只有 2 个加密字符串,现在当使用演示公钥证书解密成功时,应用程序将以演示模式运行,等等。

I need some ideas how to create a activation algorithm. For example i have demo certificate. Providing that the application runs in demo mode. When full version certificate is provided then application runs in full mode.
Is it even possible and how would be a good way creating this system?

One simple was i was thinking would be just have a 2 encrypted strings, now when the decryption is succsessful with the demo public key certificate then the application will run in demo mode and etc..

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

め可乐爱微笑 2024-12-06 09:42:58

您可以执行以下操作:

  1. 生成公钥/私钥
  2. 对 作为私钥的所有者,您可以签署这些“激活证书”(从现在起称为 AC)
  3. 在您的应用程序中,使用公钥,您可以检查签名是否

正确Overbose 提到——你无法阻止逆向工程。一般来说,有人可以将功​​能放入他/她自己的应用程序中,从而消除任何可能的激活算法。因此,你只能假设(或认为)这已经足够困难,不值得付出努力(这与密码学相同——当你使破坏消息的成本大于获得消息的利润时,你可以说它是安全良好)。

所以你可以:

  1. 使可执行文件自我验证(由你签名,基于硬编码公钥进行自我检查(一件事:自我检查时必须跳过这个值))。
  2. 使用指针做一些技巧(指向激活函数,转到第 7 位并根据另一个指针的值更改它的值;在一些奇怪的地方将硬编码值更改为基于其他位置中某些位的出现的值代码的一部分;通常 - 比使用十六进制编辑器简单地更改可执行文件中的位更难以破解)
  3. 尝试制定一些协议,您的服务器将使用它来询问有关应用程序的问题(“给我您自己的 293 字节的值” ) ”)并检查答案。
  4. 发挥想象力,想一些以前没有人使用过的奇怪的自检方法:)

如前所述——如果切断身份验证部分,所有这些都不是安全的。但事实并非如此,这可能会让破解者的处境变得更加困难。

You could do something like:

  1. Generate public/private key pair
  2. As owner of private key, you can sign those "activation certificates" (called AC from now on)
  3. In your app, with public key, you can check if the sign is correct

As Overbose mentioned -- you can't prevent reverse engineering. In general someone could take functionality and put it in his/hers own app and thus eliminate any possible activation algorithm. So you can only assume (or make) this is hard enough not to be worth the effort (this is the same as for cryptography -- when you make the cost of breaking the message greater then the profit of gaining it you can say it is well secured).

So you could:

  1. Make executable self-verifying (signed by you, self-checking based on hard-coded public key (one thing: you must skip this value when self-checking)).
  2. Do some tricks with pointers (point to the activation function, go to 7th bit and change value of it for something based on value of another pointer; in some weird places change hard-coded values to those based on occurrence of some bits in other places of the code; generally -- make it more difficult to break than by simply changing bits in executable with hex editor)
  3. Try to make some protocol that your server would use to ask questions about the app ("gimme the value of 293 byte of yourself") and check answers.
  4. Use imagination and think of some weird self-checking method nobody used before :)

As mentioned -- none of this is secure from cutting the authentication part off. But nothing is and this could make it harder for crackers.

森末i 2024-12-06 09:42:58

背景:我部署了一个基于激活的系统,该系统构建在第三方许可系统之上,即服务器、数据库、电子商务集成。我还单独编写了一个使用 RSA 密钥的 C# 激活系统,但从未部署过。

产品激活通常意味着必须在给定计算机上激活软件。我想这就是你的意思。如果您想要做的只是拥有两个表示“演示”和“购买”的字符串,那么它们将在数小时内被解密并分发(假设您的产品有价值)。毫无意义。

所以。假设您想要“激活”,那么当用户购买您的软件时,需要发生以下过​​程:

  1. 订单履行软件告诉服务器生成“购买密钥”并发送给用户
  2. 用户在软件中输入“购买密钥”
  3. 软件发送购买密钥以及服务器的唯一机器 ID。
  4. 服务器将购买密钥和机器 ID 组合成一个字符串,并使用其证书对其进行签名并将其返回给用户。
  5. 软件使用服务器公钥检查签名是否有效。
  6. 软件可以检查很多地方:在很多地方加载签名,在其他地方检查它。

生成购买密钥时,服务器不仅可以存储购买的产品,还可以存储产品的级别。您还可以拥有有时间限制的“免费”产品,因此用户可以试用该软件的完整版本 30 天。

您使用的是 C#,因此请确保使用 dotfuscator 或等效工具对二进制文件进行混淆。然而,即便如此,你也无法对抗坚定的黑客。我认为,你的目标是迫使非付费用户要么自己成为黑客,要么不得不冒险使用破解版本:孩子们不会在意,公司可能会在意。 YMMV。

执行检查的代码需要位于每个需要保护的程序集中,否则攻击者可以通过替换执行检查的程序集轻松删除保护。如果需要,可以剪切并粘贴代码。

或者只是买点东西。

另一种选择是让服务器预先生成“购买密钥”并将其提供给订单履行服务,但随后您无法将密钥链接到客户详细信息(至少在他们注册之前不会)。最好让电子商务服务器在购买后访问您的服务器,然后让您的服务器将其发送出去。

困难的部分并不是激活密钥的生成,而是服务器、数据库的创建以及与电子商务软件的集成,最重要的是人为问题:您是否允许每个购买密钥进行无限安装?只有1个?如果只有 1,那么您必须拥有客户支持以及允许用户将其安装在新计算机上的方法。这只是一个问题。各种乐趣。

Background: I've deployed an activation based system built on top of a third-party license system, i.e. server, database, e-commerce integrations. I've also separately written a C# activation system using RSA keys, but never deployed it.

Product Activation commonly means that the software must be activated on a given machine. I assume that's what you mean. If all you want to do is have two strings that mean "demo" and "purchased", then they will be decrypted and distributed within hours (assuming your product is valuable). There is just no point.

So. assuming you want "activation", then when the user purchases your software, the following process needs to happen:

  1. Order-fulfillment software tells Server to generate "Purchase Key" and send to user
  2. User enters "Purchase Key" into software
  3. Software sends Purchase Key and unique Machine ID to server.
  4. Server combines Purchase Key and Machine ID into a string and signs it with its certificate and returns it to user.
  5. Software checks that signature is valid using Servers public key.
  6. Software could check in lots of places: loading the sig in lots of places, checking it in others.

When generating Purchase Keys, the server can store not only what produce was purchased, but what level of product. You can also have "free" products that are time limited, so the user can try the full version of the software for 30 days.

You are using C#, so make sure you obfuscate the binaries, using dotfuscator or equivalent. However, even with that there is nothing you can do against a determined hacker. Your goal, I assume, is to force non-paying users to either be hackers themselves, or to have to risk using a cracked version: kids wont care, corporations might. YMMV.

The code that does the checking needs to be in every assembly that needs protecting, otherwise an attacker can trivially remove protection by replacing the assembly that does the checking. Cut and paste the code if you have to.

Or just buy something.

Another option is to have the server pre-generate "Purchase Keys" and give them to the Order fulfillment service, but then you dont get to link the key to the customers details (at least not until they register). Better to have the ecommerce server hit your server when a purchase has been made, and have your server send it out.

The hard part isn't so much the generation of activation keys as it is the creation of the server, database, and the integration with e-commerce software, and most of all, human issues: do you allow unlimited installs per Purchase Key? Only 1? If only 1 then you have to have customer-support and a way to allow a user to install it on a new machine. That's just one issue. All sorts of fun.

平定天下 2024-12-06 09:42:58

这个人写了一篇关于类似想法的博客文章,解释了他做了什么拥有自己的商业软件。还写了关于最明显的破解技术的建议列表。希望有帮助。

This guy wrote a blog post about a similar idea, explaining what he did with their own commercial software. Also wrote a list of recommendations about the most obvious cracking techniques. Hope it helps.

悲喜皆因你 2024-12-06 09:42:58

一个简单的事情是我想只要有一个 2 加密
字符串,现在当演示公开成功解密时
密钥证书,然后应用程序将以演示模式等运行。

可能是一个简单的解决方案。但这样你就不会阻止有人对你的二进制文件进行逆向工程并使执行跳转到正确的行。每个人都有你的程序,都有它的完整版本,所以只需找到如何打破这个简单机制的问题。

也许更好的解决方案是加密使用完整应用程序版本所需的部分二进制文件,而不是简单的字符串。通过这种方式执行应用程序完整版本,有人需要解密这些二进制文件才能执行它们。

请考虑到即使该解决方案也还不够。还有其他问题:

  1. 您的工具的所有版本是否都会共享相同的加密密钥?破坏其中一个就破坏了所有。
  2. 即使您为每个发布的二进制应用程序使用不同的密钥,加密的二进制文件是否相同?一旦破解,您就可以将未加密的二进制文件重复用于所有分布式应用程序。

如何解决这些问题呢?没有简单的解决方案。大多数更重要的商业软件,甚至具有复杂的保护系统,在发布后的几小时或几天内就被破坏了。

One simple was i was thinking would be just have a 2 encrypted
strings, now when the decryption is succsessful with the demo public
key certificate then the application will run in demo mode and etc..

Could be a simple solution. But this way you won't prevent someone to reverse engineer your binaries and make the execution jump to the correct line. Everyone has your program, has a complete version of it, so it's only a matter of find how to break this simple mechanism.

Maybe a better solution is encrypt a part of the binaries needed to use the full application version, instead of a simple string. This way to execute the application complete version someone need to decrypt those binaries in order to execute them.

Please take in consideration that even that solution isn't enough. There are other problems with that:

  1. Does all the version of your tool will share the same encryption key? Breaking one of them for breaking all..
  2. Even if you use a different key for each binary application released, does the encrypted binary are identical? Once cracked one, you can reuse the unencrypted binaries for all distributed applications.

How to solve these problems? There's no simple solution. Most of the more important commercial software with even sophisticated protection systems are broken just few hours or days after they have been released.

耀眼的星火 2024-12-06 09:42:58

产品激活不是非对称密码能够解决的问题。非对称密码学的目的是向对手保守秘密。问题是你无法保守存储在对手机器上的秘密,即 尽管默默无闻但安全

产品激活的正确方法。是生成一个存储在服务器数据库中的加密随机数。当客户购买产品时,您将这个 Nonce 提供给他们,然后他们在线激活它。此激活过程可以下载新材料,这将使攻击者更难以修改他们拥有的副本“解锁”新功能。

但即使 DRM 系统 要求您在使用该产品时保持在线。就像“From Dust”等新游戏中的那些仍然损坏 释放后数小时内。

Product activation is not a problem that asymmetric cryptography can solve. Asymmetric cryptography is about keeping secrets from your adversary. The problem is that you can't keep a secret that is stored on you're adversaries machine, that would be security though obscurity.

The correct way to do product activation. Is to generate a Cryptographic Nonce that is stored in a database on your server. You give this Nonce to the customer when they buy the product, and then they activate it online. This activation process could download new material, which would make it more difficult for the attacker to modify the copy they have to "unlock" new features.

But even with DRM systems that require you to be online while using the product. Like the ones found in new games like "From Dust" are still broken within hours of their release.

自此以后,行同陌路 2024-12-06 09:42:58

公钥加密的好处之一是您可以 验证给定数据的来源。因此,如果您将公钥存储在程序集中,然后签署给定的数据(例如授权码或序列号),您的程序集可以验证您是创建该数据的人,而不是黑客。实际数据本身并不那么重要——它可以是一个简单的通过/失败值。

实际上,使用 .NET 可以很容易地做到这一点。您可以使用 x509 证书或像我们在 DeployLX 许可 中使用的 RSACryptoServiceProvider

我强烈建议您购买商业产品(哪个并不重要,尽管 DeployLX 非常出色)并且不要自己这样做,原因有两个:

  1. 即使您是一位出色的开发人员,您也可能第一次就会出错。而你自己通过自己的努力所获得的任何节省都将因从错误中恢复而损失殆尽。
  2. 您将花费更多的时间在自己的系统上工作——您应该花费这些时间来使您的产品变得更好。

保护软件的第二阶段是确保它按照您创建它的方式运行 - 并且没有被黑客修改。如果黑客可以检查 if( Licensed )if( true ),那么您使用什么加密方式实际上并不重要。

One of the benefits of public key encryption is that you can verify the origin of a given piece of data. So if you store the public key in your assembly, then sign a given piece of data (say an authorization code or serial number) your assembly can verifiably determine that you were the one that created that data - and not a hacker. The actual data itself isn't all that important - it can be a simple pass/fail value.

This is actually pretty easy to do with .NET. You can use an x509 certificates or like we use in DeployLX Licensing the RSACryptoServiceProvider.

I would highly recommend buying a commercial product (doesn't really matter which one, though DeployLX is excellent) and not doing this yourself for 2 reasons

  1. Even if you're a great developer, you'll probably get it wrong the first time. And any savings you might have enjoyed by rolling your own will be lost to recovering from that mistake.
  2. You'll spend far more time working on your own system - time that you should spend making your product great.

The second phase in protecting the software is to make sure that it runs the way you created it - and hasn't been modified by a hacker. It really doesn't matter what encryption you use if hackers can check if( licensed ) to if( true ).

烟若柳尘 2024-12-06 09:42:58

您可以使用 AsProtect 来解决此问题。这是一个很好的起点。

You can use AsProtect to solve this problem. This is good staring point.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文