Windows:了解某个日期是否已过的可靠方法?

发布于 2024-09-10 07:17:52 字数 218 浏览 10 评论 0原文

对于简单的产品密钥库,我需要可靠地检查某个日期是否已过。
我想做一些比检查系统时钟稍微不那么简单的事情,因为用户可以轻松更改系统时钟。

这样做的标准方法是什么?

有人建议的一种方法是检查是否有文件在检查日期之后被修改。这听起来不错,但是我应该检查哪些文件?显然我不想开始随机扫描用户的磁盘。

编辑 - 我想避免基于网络的解决方案。

For a simple product key library I need to reliably check if a certain date passed.
I'd like to do something slightly less trivial than checking the system clock since that can be changed easily by the user.

What are standard ways of doing this?

One way someone suggested is to check if there are files which were modified after the checked date. this sounds good but which files should I check? Obviously I don't want to start sweeping over the user's disk at random.

Edit - I'd like to avoid network based solution.

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

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

发布评论

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

评论(7

手长情犹 2024-09-17 07:17:52

我正在阅读字里行间。我想你想制作一个“试用软件”版本。尤其是你提到“破解”。

对于“试用期”日期,我能想到的最好的非网络解决方案是不用担心绝对日期的过去,而是实施一天倒计时。即使您因用户更改 CMOS/BIOS 日期时间而失败了很多天,您仍然可以存储上次启动时和下次启动时的日期和时间以及系统滴答计数如果日期似乎没有向前推进少于一天的一小部分时间,则减少“试用期剩余天数”计数器。您还可以计算应用程序处于活动状态的小时数,并进行倒计时。有人可以通过让您的应用程序远离网络并回滚时钟来无限期地延长试用版的生命周期,但如果您运行始终在后台运行的服务,您可能会发现时钟回滚,并在后台服务检测到一定数量(比方说三个)时钟回滚后停用。

我可能会想出一种方法来非常准确地锁定应用程序中使用的活动时间,比日期更准确。

事实上,如果您正在考虑该软件的“试用版”,为什么不考虑只给用户“xx小时的试用时间”,而不是“30天”。如果 30 天过去了,而您的用户没有调整日期/时间来延长它,他可能会非常恼火,因为您的试用版在他使用您的软件之前就已过期,您可能会失去销售机会。

谷歌的 sketch-up pro 使用“小时倒计时”技术,我发现评估它要容易得多。

我认为另一个问题的答案是我见过的最好的答案:
创建只能运行的程序的最佳方法是什么在预定义的试用期(评估期)内?

真正的答案是“任何你能做的事情,都有很多人会尝试击败和破解它”。严重地。您想在加密和混淆上花费多少时间?这样你就赚不到钱。

I'm reading between the lines. I think you want to make a "Trial software" version. Especially since you mention "cracking".

The best non-network solution I can imagine for "trial period" dates is to not worry about an absolute date going by, and instead, implement a day countdown. Even if you are defeated for a number of days by a user changing the CMOS/BIOS date-time, you can still store the date and time and system tick count of the last time you were booted up, and the next time you are booted up, if it appears that the date has done anything other than go forward by a small amount of time that is less than a day, then decrement your "days remaining in your trial" counter. You could also count hours that the application has been active, and count that down too. It is possible for someone to extend the lifetime of a trial version indefinitely by keeping your app away from the network, and by rolling back the clock, but if you run a service that is always running in the background, you might be able to catch the clock-rollbacks, and deactivate after some number (let's say three) clock rollbacks are detected by your background service.

I could probably come up with a way to pretty accurately lock down the active hours used in an application much more accurately than the date.

In fact, if you are contemplating a "trial version" of the software, why not consider just giving the user "xx hours of trial time", instead of "30 days". If 30 days goes by and your user doesn't fiddle with the date/time to extend it, he may be so annoyed that your trial expired before he spent any time with your software, that you may lose a sale.

Google's sketch-up pro uses the "hours countdown" technique, and I found evaluating it much easier.

I think this answer to another question is the best one I have seen:
What is the Best way to create a program which works only in the predefined trial period(evaluation period)?

The real answer is "anything you can do, there are lots of people who will try to defeat and crack it". Seriously. How much time do you want to spend on encryption and obfuscation? You won't make any money that way.

剪不断理还乱 2024-09-17 07:17:52

依靠操作系统来检查可以更改的日期 --> 你已经输掉了比赛

任何方法都可能而且将会被打破,让你从失败的位置开始雪上加霜。基于外部网络将是明智的选择,但即使这样也可能会受到阻碍。

您问题的关键词是

“可靠”

,简单的答案是,将方钉锤入圆孔是没有意义的。

编辑 1:弱解决方案

好的,理解这几乎是一场失败的战斗,如果你仍然坚持在这里有一些非常弱的解决方案,这是一种可能性:

我们知道时间应该只会向上增加,因此基于这个假设,这可以是我们的“测试”。如果违反此规则,我们可以假设有人篡改时间,从而阻止此案例。

(1) 在首次运行应用程序时,创建一个包含当前日期(时间戳)的加密文件。

(2) 每次运行应用程序时,首先检查该文件并从操作系统检查当前时间。

(3) 根据我们的基本假设,我们应该期望当前时间应该始终大于存储的时间时间。如果是,我们可以弱地假设操作系统时间是“可靠的”。

(3)如果当前时间小于存储的时间,则说明有人篡改了操作系统时间->坏人。

(5) 关闭时加密当前时间。

(6) 如果加密文件丢失,则假定也是坏人。

Relying on the OS for checking a date that can be altered --> you have already lost the game

Any method can and will be broken, to add insult to injury your starting off from a lost position. An external network based would be the sensible choice, but even that can be thwarted.

The key words to your question is

Reliable

and the simple answer is NO, there is no point in hammering a square peg into a round hole..

Edit 1: Weak solution

OK, understanding that this is pretty much a lost battle, if you still insist on having some very weak solution here is one possibility:

We know that time should only increment upwards, thus based on this assumption, this can be our 'test'. Violation of this rule we can assume someone is tampering with time and therefore block this case.

(1) On the first ever run of the application create an encrypted file with the current date (time-stamp).

(2) Every-time the application is run, first check for this file and check the current time from the OS.

(3) from our base assumption, we should expect that the current time should always be greater the stored time time. If it is we can WEAKLY assume that the OS time is 'Reliable'.

(3) If the current time is less than the stored time, then some one has been tampering the OS time -> bad guy.

(5) Upon closing encrypt the current time.

(6) If the encrypted file is missing assume also bad guy.

绝不服输 2024-09-17 07:17:52

你可以查询你公司的ntp服务器。当然,用户可能会通过防火墙阻止您的 ntp 服务器的存在,因此您必须决定要花多少工作来支持具有严格安全策略的用户或试图绕过您的许可技术的用户。

You could query your company's ntp server. Of course, users may firewall your ntp server out of existence, so you'll have to decide how much work you want to go to support users with either draconian security policies or users trying to bypass your licensing techniques.

幸福%小乖 2024-09-17 07:17:52

您可以检查时钟,还可以在注册表中存储您在任何其他检查中获得的最新日期。这样,至少一旦用户停用该程序一次,就无法再次重新激活它。我能看到的唯一选择是查询某种互联网服务来获取时间,但这不好。

You can check the clock, but also store the latest date you even got on any other checks in the registry. That way at least once the user has deactivated the program once, it can't be reactivated again. The only alternative I can see is to query some kind of internet service to get the time, but that's no good.

柏拉图鍀咏恒 2024-09-17 07:17:52

您可以请求任何公开可用的 Web 服务器(例如 www.com)并从响应标头中获取日期。

You can request any publicly available web server (say www.com) and grab date from response header.

一瞬间的火花 2024-09-17 07:17:52

如果是试用版本场景,您可以允许用户仅使用该应用程序一定次数。

You can allow the user to use the application only a certain number of times if it is a trail version scenario.

笑,眼淚并存 2024-09-17 07:17:52

我不确定“没有基于网络的解决方案”是什么意思。有一个网络服务可以获取任何位置的日期和时间。

EarthTools

应用程序可以获取以下位置的日期和时间:应用程序安装和启动时创建者的位置。

EarthTools 要求您每秒提交的请求不得超过一个,这对于大多数用途来说应该足够了。

以下是纽约的示例查询: http://www.earthtools.org/timezone/40.71417 //74.00639

这是示例响应:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<timezone xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://www.earthtools.org/timezone.xsd">
    <version>1.1</version>
    <location>
        <latitude>40.71417</latitude>
        <longitude>-74.00639</longitude>
    </location>
    <offset>-5</offset>
    <suffix>R</suffix>
    <localtime>4 Dec 2005 12:06:56</localtime>
    <isotime>2005-12-04 12:06:56 -0500</isotime>
    <utctime>2005-12-04 17:06:56</utctime>
    <dst>False</dst>
</timezone>

I'm not sure what shoosh means by no network based solutions. There's a web service available to get the date and time of any location.

EarthTools

An application can get the date and time at the creator's location when the application is installed, and when it is started.

EarthTools asks that you not submit more than one request a second, which should be adequate for most purposes.

Here's the example query for New York: http://www.earthtools.org/timezone/40.71417/-74.00639

Here's the example response:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<timezone xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://www.earthtools.org/timezone.xsd">
    <version>1.1</version>
    <location>
        <latitude>40.71417</latitude>
        <longitude>-74.00639</longitude>
    </location>
    <offset>-5</offset>
    <suffix>R</suffix>
    <localtime>4 Dec 2005 12:06:56</localtime>
    <isotime>2005-12-04 12:06:56 -0500</isotime>
    <utctime>2005-12-04 17:06:56</utctime>
    <dst>False</dst>
</timezone>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文