使用公钥证书激活产品
我需要一些如何创建激活算法的想法。例如我有演示证书。前提是应用程序在演示模式下运行。当提供完整版本证书时,应用程序以完整模式运行。 这是否可能?创建这个系统的好方法是什么?
一个简单的想法是,我想只有 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
您可以执行以下操作:
正确Overbose 提到——你无法阻止逆向工程。一般来说,有人可以将功能放入他/她自己的应用程序中,从而消除任何可能的激活算法。因此,你只能假设(或认为)这已经足够困难,不值得付出努力(这与密码学相同——当你使破坏消息的成本大于获得消息的利润时,你可以说它是安全良好)。
所以你可以:
如前所述——如果切断身份验证部分,所有这些都不是安全的。但事实并非如此,这可能会让破解者的处境变得更加困难。
You could do something like:
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:
As mentioned -- none of this is secure from cutting the authentication part off. But nothing is and this could make it harder for crackers.
背景:我部署了一个基于激活的系统,该系统构建在第三方许可系统之上,即服务器、数据库、电子商务集成。我还单独编写了一个使用 RSA 密钥的 C# 激活系统,但从未部署过。
产品激活通常意味着必须在给定计算机上激活软件。我想这就是你的意思。如果您想要做的只是拥有两个表示“演示”和“购买”的字符串,那么它们将在数小时内被解密并分发(假设您的产品有价值)。毫无意义。
所以。假设您想要“激活”,那么当用户购买您的软件时,需要发生以下过程:
生成购买密钥时,服务器不仅可以存储购买的产品,还可以存储产品的级别。您还可以拥有有时间限制的“免费”产品,因此用户可以试用该软件的完整版本 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:
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.
这个人写了一篇关于类似想法的博客文章,解释了他做了什么拥有自己的商业软件。还写了关于最明显的破解技术的建议列表。希望有帮助。
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.
可能是一个简单的解决方案。但这样你就不会阻止有人对你的二进制文件进行逆向工程并使执行跳转到正确的行。每个人都有你的程序,都有它的完整版本,所以只需找到如何打破这个简单机制的问题。
也许更好的解决方案是加密使用完整应用程序版本所需的部分二进制文件,而不是简单的字符串。通过这种方式执行应用程序完整版本,有人需要解密这些二进制文件才能执行它们。
请考虑到即使该解决方案也还不够。还有其他问题:
如何解决这些问题呢?没有简单的解决方案。大多数更重要的商业软件,甚至具有复杂的保护系统,在发布后的几小时或几天内就被破坏了。
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:
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.
产品激活不是非对称密码能够解决的问题。非对称密码学的目的是向对手保守秘密。问题是你无法保守存储在对手机器上的秘密,即 尽管默默无闻但安全。
产品激活的正确方法。是生成一个存储在服务器数据库中的加密随机数。当客户购买产品时,您将这个 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.
公钥加密的好处之一是您可以 验证给定数据的来源。因此,如果您将公钥存储在程序集中,然后签署给定的数据(例如授权码或序列号),您的程序集可以验证您是创建该数据的人,而不是黑客。实际数据本身并不那么重要——它可以是一个简单的通过/失败值。
实际上,使用 .NET 可以很容易地做到这一点。您可以使用 x509 证书或像我们在 DeployLX 许可 中使用的 RSACryptoServiceProvider。
我强烈建议您购买商业产品(哪个并不重要,尽管 DeployLX 非常出色)并且不要自己这样做,原因有两个:
保护软件的第二阶段是确保它按照您创建它的方式运行 - 并且没有被黑客修改。如果黑客可以检查
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
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 )
toif( true )
.您可以使用 AsProtect 来解决此问题。这是一个很好的起点。
You can use AsProtect to solve this problem. This is good staring point.