如何让我的产品成为 30 天的试用版?

发布于 2024-08-07 01:15:52 字数 155 浏览 5 评论 0原文

我已经创建了我的产品并为其生成了许可证密钥,但我想在 30 天后询问该密钥。我已经使用存储日期的注册表值添加了 30 天来做到这一点。但我发现,如果用户在 30 天之前更改系统日期,我的逻辑就不起作用。

那么对于试用版软件,不检查系统日期,只允许试用30天,有没有什么解决办法呢?

I have created my product and also generated license key for that but I want to ask that key after 30 days. I have do it with registry value storing the date with adding 30 days in that. But I found that if the user change the system date with 30 days before my logic not work.

So is there any solution for the trial version software without checking system date and allow only 30 days of trial?

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

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

发布评论

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

评论(11

夢归不見 2024-08-14 01:15:52

您可以拥有另一个注册表项,每天使用后都会增加该注册表项。这样,即使他们更改了计算机的日期,此键也会向您的程序表明它已经运行了 > > 。 30天。

此外,该值可以被加密,这样,如果用户尝试手动更改它,程序可能会拒绝运行,因为它无法解密该值并从中获取有效的数字。

为了避免重新安装,您可以将一些信息添加到与应用程序的试用版一起保存的任何文件中,这些信息对于该特定版本的应用程序是唯一的(可能是安装时的时间戳)。当您的应用程序的试用版尝试打开文件时,它将检查此签名并确保它是使用同一实例创建的,否则拒绝打开该文件。这本质上削弱了简单地重新安装应用程序并继续使用它的能力。

但归根结底,用户可以完全控制他们的机器,并且可能找到一种方法来解决您想做的任何事情(在您让用户使用应用程序之前访问保存这些详细信息的网络服务) )。您可能不应该花费太多精力试图阻止那些愿意经历这种额外麻烦的人,而应该花费额外的时间/金钱/精力为那些愿意付费的人改进应用程序。

You could have another registry key that you increment after every day's use. That way, even if they change the computer's date, this key would indicate to your program that it's been running for > 30 days.

Additionally, this value could be encrypted so that if the user tries to manually change it, the program can refuse to run because it was unable to decrypt the value and get a valid number out of it.

To get around reinstalls, you could add some information to any file saved with the trial version of your app which is unique to that specific version of the app (perhaps a timestamp from when it was installed). When a trial version of your app tries to open a file, it will check this signature and ensure that it was created with that same instance, otherwise refuse to open the file. This essentially neuters the ability to simply reinstall the app and continue using it.

At the end of the day though, the user has complete control over their machine and can probably find a way around whatever it is you want to do (short of accessing a web service where these details are kept before you let the user use the app). You probably shouldn't expend so much energy trying to stop the guys who are willing to go through this extra trouble, but instead spend that extra time/money/energy improving the app for those who are willing to pay.

时光暖心i 2024-08-14 01:15:52

我为你提供了一个简单的解决方案。

为注册表取两个变量:
1. 日期
2. 计数器

步骤:

  1. 设置计数器 = 1

  2. 将系统日期复制到日期

  3. 每次检查日期是否不同比当前日期,然后将该日期复制到注册表日期,同时将计数器加 1。如果日期相同,则不执行任何操作。

  4. 现在您可以检查计数器是否有试用天到期

通过使用这些技巧,如果用户将系统日期更改为以前的日期,它也可以工作。

对于注册表,您可以加密日期和日期。计数器,让技术人员无法识别你的逻辑!

干杯...

添加

仅当用户不更改每天的日期时,此逻辑才会失败!我们再次提供了解决方案!

我不知道这是否可能,但你总是可以有一些解决方案:

  1. 计算试用期和试用期的总时间。将其存储在注册表中。
  2. 现在计算每次运行的总时间并将其添加到另一个变量中。 (我希望可以通过定时器来完成)
  3. 比较以上两个值来决定是否过期。

I have one simple solution for you.

Take 2 variables for registry:
1. date
2. counter

steps:

  1. Set a counter = 1

  2. Copy system date to date

  3. Check each time if the date is different than the current date, than copy that date to the registry date, also increment the counter by 1. If the date is same, don't do anything.

  4. Now you can check you counter for trial days expiration

By using these trick, if user change the system date to previous date than also it works.

For registry you can encrypt the date & counter so that technical person would not recognize your logic!

cheers...

ADDED

This logic fails only when user doesn't change the date for each day! Again we have the solution for that!

I don't know whether it is possible or not but you can always have some solution:

  1. count the total time for trial period & store it in registry.
  2. Now count the total time for each run and add it in another variable. (I hope that it can be done by timer)
  3. Compare above two values for taking decision for expiration.
与之呼应 2024-08-14 01:15:52

您可以使用许可组件。您可以自己制作一个(请参阅 LicenseManager 类 ),或从供应商处购买(例如 CryptoLicensing)。

You could use a licensing component. You can make one yourself (see the LicenseManager class), or buy one from a vendor (for example CryptoLicensing).

一绘本一梦想 2024-08-14 01:15:52

您需要有一种方法来检测用户是否更改了您首次开始试用的日期。在我之前使用过的解决方案中,我们保存了“最后执行”日期和“首次执行”日期,如果时钟更改超过“最后执行”两天,我们就会使试用期到期。您还需要一个“执行天数”计数器,这样他们就不能继续将日期向后移动两天(忘记提及那部分) - 计数器在每次执行时都会增加。

当然,通过卸载并重新安装并适当刷新注册表,这样的软件许可系统总是可以避免的 - 技巧是混淆和复制您的许可证信息,足以使这变得困难,但最终,它会被发现(特别是如果您使用未混淆的 .NET 代码库)。

You need to have a way of detecting if the user changes the date from when you first started the trial. In solutions I've used before, we have saved the "last executed" date and the "first executed" date and if the clock changes to anything more than two days of "last executed" we expire the trial. You also need a "days executed" counter so that they can't keep moving the date two days back (forgot to mention that part) - the counter gets incremented on each execution.

Of course, software licensing systems like this are always avoidable by uninstalling and reinstalling with appropriate refreshing of the registry - the trick is obfuscating and duplicating your license information enough to make this difficult, but eventually, it will get found (especially if you're using an unobfuscated .NET codebase).

喜爱皱眉﹌ 2024-08-14 01:15:52

如果不参考系统日期/时钟,很难处理 30 天。您始终可以保留应用程序启动日期的列表,并在每次与上次不同时计数 1。这样,您的用户每次启动您的应用程序时都必须设置相同的日期。

除此之外,只要有互联网接入,您就可以查询已知的良好时间服务器以获取当前日期。这可以通过断开连接来避免,但您始终可以在应用程序启动之前要求互联网连接。

最后,通过硬件加密狗或类似的外部本地时间源,但我认为您已经进入极端,最好亲自直接管理试验。

Hard to process 30 days without reference to the system date/clock. You could always keep a list of the dates on which the app was started and count 1 for every time it was different from the last time. This way your user would have to set the same date each time they fired up your app.

Other than that, you could, providing there were internet access, query a known good time server for the current date. This could be circumvented by disconnecting but you could always demand an internet connection before your app will start.

Lastly, an external, local time source via a hardware dongle or similar but I think you are getting into the extreme where you'd be better off directly managing the trials in person.

人事已非 2024-08-14 01:15:52

您可以使用免费项目 Libprot。该站点是 https://github.com/libprot/trunk

我们的想法是它应该简单且易于使用。您可以花费 $$$ 进行保护,但它可能会在一周内遭到黑客攻击。如果有人想对您的代码进行逆向工程,那么没有人可以阻止它。我的建议是使用有效的简单方法。

编写如下字符串:

Company X|10.2.2014|1.12.2015

,其中 10.2.2014 是当前日期,如果系统时间小于则有人更改了系统时钟 =>我们不应该运行

为止

1.12.2015 - 直到密钥有效以及购买/下载它的公司名称

。例如,该字符串应该使用带有私钥/公钥的非对称算法进行混淆,并编码为您可以通过电子邮件发送的字符串。

您可能还需要一些网络服务来进行验证。当互联网连接打开时,您可以验证密钥,如果它被黑客攻击并可在互联网上公开,您可以禁止它。或者,如果有人编写密钥生成器,您可以验证该密钥是真实的。

您可以在站点中添加一些 PHP/java 脚本来自动发送试用代码。

You can use free project Libprot. The site is https://github.com/libprot/trunk.

The idea is that it should be simple and easy to use. You can spend $$$ on protection but it may be hacked in one week. If someone wants to do reverse engineering of your code then no one can stop it. My advice to use simple methods that works.

Write a string like:

Company X|10.2.2014|1.12.2015

where 10.2.2014 is current date and if the system time is less then someone changed system clock => we should not run

1.12.2015 - until what time the key is valid

and name of company who bought/downloaded it.

that string should be obfuscated with asymmetric algorithm with private/public key and encoded into string that you may send by e-mail, for example.

you may also want to have some web service for validation. when internet connection is on you may validate the key, if it's hacked and available for public in internet you may ban it. Or if someone would write key generator you may validate that key is real.

you can add some PHP/java script in your site to automatically send trial codes.

自由如风 2024-08-14 01:15:52

如果您可以保证互联网连接,您可以实施在线方案(检查时间服务器或您自己的身份验证服务器)。当然,这引入了另一个依赖性 - 如果互联网消失,您的用户将无法工作。

最终我会说购买第三方许可解决方案 - 它仍然不是牢不可破的,但它可能比您无需花费大量时间和精力就可以自己完成的事情更强大。

IF you can guarantee an internet connection you could implement an online scheme (check a time server or your own authentication server). Of course that introduces another dependency - if the internet goes away, your users can't work.

Ultimately I'd say buy a third party licensing solution - it's still not unbreakable but it will probably be more robust than something you can do yourself without a lot of time and effort.

眼前雾蒙蒙 2024-08-14 01:15:52

存储上次运行日期,只要系统日期早于该日期,试用期就会过期。

唯一的故障安全方法是根据您托管的服务验证应用程序,假设没有人破解您的连接代码;)

只要他们可以清除注册表值/隔离存储文件/保存的设置:他们就可以重新启动试用版。对此你无能为力。这就是为什么除了基于时间的试用期之外,人们还选择减少试用软件的功能。

Store the last run date, and whenever the system date is before that, expire the trial.

The only fail-safe method is to validate the app against a service that you host, assuming no one cracked your connection code ;)

As long as they can clear the registry value/isolated storage file/saved settings: they can just restart the trial. There's not much you can do about that. That's why people opt for reduced functionality in trial software, in addition to a time-based trial period.

童话里做英雄 2024-08-14 01:15:52

如果可以接受 8 小时的试用(而不是 30 天的试用),那么消除对系统日期时间依赖的一种方法是在应用程序中使用一个计时器,该计时器每分钟触发一次。对这些进行计数,以便每次应用程序运行时,它都会累积总使用分钟数。然后,您可以将此计数值存储在某处,例如注册表中。

If its acceptable to allow say 8 hours of trial usage (instead of a 30 day trial), then one way to remove the dependence on the System DateTime is by using a timer in your app which is fired say every minute. Count these and so every time the app gets run, it will accumulate a total usage minute count. You can then store this count value somewhere, such as in the registry.

难得心□动 2024-08-14 01:15:52

这是简单的商店评估结束日期并每天检查。为了避免因日期操作而延长使用时间,请在应用程序中维护小时计数;继续递增并将其写入注册表。应根据评估结束日期和不超过 24 小时的小时数进行检查(在某些情况下可能为 30 小时)。

It's simple store evaluation end date and check for it every day. To avoid extended usage by date manipulation, maintain an hour count in the application; keep incrementing and writing it to registry. Check should be done against both the evaluation end date and the hour count not to exceed 24 (may be 30 with some teolrence).

爱要勇敢去追 2024-08-14 01:15:52

另请考虑:

保存应用程序关闭的日期时间,下次午餐时您的应用程序将能够检测日期时间设置是否已更改(至少他们不能将其更改为关闭时间之前的某些内容) 。
示例:

申请关闭时:

节省时间=> 2014 年 3 月 31 日 15:34(已保存)

下次启动应用程序:

检查 Datime.Now > 2014 年 3 月 31 日 15:34。 (所以他们不能低于...)

添加:

尝试以某种方式将系统的日期时间设置集成到您的应用程序使用中:生成发票、票据、收据...无论如何!

Think Also About :

Saving the DateTime of the closing of the application, next time it's lunched your application will be able to detect if the Datetime setting was changed or not (at least they can't change it before to something before the closing time).
Example :

On Application Closing :

Saving The Time => 15:34 03/31/2014 (Saved)

Next Starting Of The Application :

Check Datime.Now > 15:34 03/31/2014. (so they can't go bellow that...)

ADDED :

Try somehow to integrate the datetime settings of the system into your application use : Generating Invoices, Tickets, Receipts... whatever !

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