IsDateValid() not working

Hey Philippe,

We're making this particular brand of fraud detection better in the next version (the version coming with the other bug fix you're waiting for). However, there's no perfect solution to this problem. That is, it's inherent with client-side date verification that there are only a few reliable date-time sources.

So if you want 100% accuracy (something no possible with client-side only verification) then you'll have to ping your servers and get a signed date-time.

Does that make sense?

Hello,

Ok, my example was the best to explain the problem. Here is a new one : 1. My clock is set automatically by OSX via internet 2. The call IsDateValid("2013-01-01 10:00:00", TA_HAS_NOT_EXPIRED) return TA_FAIL (normal) 3. I change manually my clock to 2012 (computer still connected to internet) 4. The call IsDateValid("2013-01-01 10:00:00", TA_HAS_NOT_EXPIRED) return TA_OK (not normal)

I did the test a few months ago, and there wasn't such a problem. Indeed, I think it's new bug (if not, what the use of IsDateValid(), there are already a lot of date comparator ...).How could I protect my product ? I'm not looking for a 100% perfect solution, 90% is enough.

Best. Philippe

I did the test a few months ago, and there wasn't such a problem.

We changed the behavior on the Mac because there was a bug in the kernel. So we were forced to make it weaker (otherwise a fraction of the end-user would get "TA_FAIL" on valid date/times).

How could I protect my product ? I'm not looking for a 100% perfect solution, 90% is enough.

We're making things marginally better on the Mac in the upcoming bugfix release.

To get an even better result then, like I said above, ping your sever for the current date/time. (Obviously you should cryptographically sign this result to prevent "false responses").

Ok, if I understand it correctly :

- The behavior on the Mac was changed without explaining this IsDateValid() change : I'm selling rental licenses, so I've to worry now about customers changing the date and using my product forever ...

- The method for rental licenses that Wyatt told me to use is not relevant any more (https://wyday.com/forum/t/1775/settings-trial-days-to-zero-rental-license/#post-9298), as IsDateValid() became just a date comparator.

- In brief : LimeLM is not suitable for rental licenses any more. At least on Mac.

Am I right ?- first reply you said : "We're making this particular brand of fraud detection better in the next version"- second reply : "We're making things marginally better on the Mac"

It puzzles me ...

- The behavior on the Mac was changed without explaining this IsDateValid() change : I'm selling rental licenses, so I've to worry now about customers changing the date and using my product forever ...

It was a necessary and unavoidable bugfix because the Mac OS X kernel has a bug. Trust me, I wish it didn't have the bug.

- The method for rental licenses that Wyatt told me to use is not relevant any more (https://wyday.com/forum/t/1775/settings-trial-days-to-zero-rental-license/#post-9298), as IsDateValid() became just a date comparator.

We do some fraud detection, so no it's not a straight date comparator. And as I've said a couple times in this thread we're replacing that removed fraud detection code with other fraud detection code that is actually reliable and doesn't depend on buggy Mac OS X behavior.

- In brief : LimeLM is not suitable for rental licenses any more. At least on Mac.

I don't think that's a fair summary. Fraud detection that's entirely client-side (like IsDateValid() does) has always been inherently fraud prone. We do our best to find reliable sources for the date/time on the client system.

If you want 100% accuracy then we recommend pinging your servers.

- first reply you said : "We're making this particular brand of fraud detection better in the next version"- second reply : "We're making things marginally better on the Mac"

It puzzles me ...

They're both accurate. We're fixing this in the next version. And this will be a marginal improvement bringing it back to where it was before (but without the Mac OS X kernel buggy behavior). In other words, good but not great.

If you want great, then you'll have to ping your servers.

Thank you for your reply. We all run software companies, with similar support system, and I knwo what it is to reply to user questions.But there is still something not clear for me. Sorry.

I described a scenario, where the date could be "easily" changed (directly via OSX Preferences), so the IsDateValid() doesn't return TA_FAIL any more.My main question : is this problem gonna be fixed in the next release ?

If yes, I will stick to LimeLM for rental license.If no, I'd need to find another way (ping my own servers, or whatever). As said earlier, I'm not looking for 100% accuracy, but to my mind, changing the date from OSX Preferences is far too easy !

My main question : is this problem gonna be fixed in the next release ?

Yes, the specific rollback behavior you listed will return TA_FAIL like it previously did.

Ok perfect. Thank you.

Hello,

Any release date about the update ?Knowing this flaw, I cannot sell rental licenses any more.

Thank you. Philippe

We've been tracking down a crashing bug that 2 separate end-users have encountered and we wanted to get that in the next release first. We might have to make an intermediate release with this bug fix first if we don't find the cause of the other bug soon.

TA 3.4 is now out, and among the other improvements is better client-side fraud detection.

Hello,

The problem I described is not solve.To reproduce it :- use Mac OSX Mountain Lion (it's probably the case on other OSX)- check IsDateValid("2013-06-01 10:00:00", TA_HAS_NOT_EXPIRED) return TA_FAIL- change the date to 2013-01-01 from the System Preferences- IsDateValid("2013-06-01 10:00:00", TA_HAS_NOT_EXPIRED) return TA_OK

I think it's a major flaw for rental licenses, as it's too easy for the user to "hack" the product.Let me know if I missed something. Thank you.

Best. Philippe

The improvements we made to the date checking were tied to the new IsGenuineEx() functionality. Are you using that? And if so what "days between checks" date are you putting?

No, as said in my message (and all the previous ones), I'm using IsDateValid() not IsGenuineEx().

For rental license, I'm using the method you described in this post : https://wyday.com/forum/t/1775/settings-trial-days-to-zero-rental-license/#post-9298So using a feature called "rental_expires" and calling IsDateValid() to check if the product must be deactivated.

On Mac OSX, IsDateValid() is just a date comparator and doesn't check if the date was changed (but it was before version 3.3). Is it gone forever ? Should I code my own "date checking" system ?

PS : I'm wondering why you put this thread as "[solved]", if you didn't make a fix for IsDateValid() in version 3.4 ?

No, as said in my message (and all the previous ones), I'm using IsDateValid() not IsGenuineEx().

Right, I know you're using IsDateValid(). I'm saying that if you're also using IsGenuineEx() (elsewhere -- in place of IsActivated() ) then this improves the fraud detection in IsDateValid().

On Mac OSX, IsDateValid() is just a date comparator and doesn't check if the date was changed (but it was before version 3.3). Is it gone forever ?

There was a critical Mac OS X Kernel level bug that forced us to drop 1 of the more aggressive fraud detection techniques. Unfortunately that bug is all Apple's fault. I wish we could fix it.

However 3.4 added another fraud detection technique that relies upon the cryptographically signed data that comes from IsGenuineEx().

So, short answer: use IsGenuineEx() instead of IsActivated() and then IsDateValid will be more accurate.

Otherwise design you own fraud detection and use GetFeatureValue() to pass that to your own function.

PS : I'm wondering why you put this thread as "[solved]", if you didn't make a fix for IsDateValid() in version 3.4 ?

We didn't "revert" to the pre TA 3.3 behavior, because there was an Apple kernel-level bug. We did improve the fraud detection in the IsDateValid() function for those customers using IsGenuineEx().

Hello Wyatt,

Ok this is something I didn't know (I guess it's not writtent in the documentation).Here is how I understand it :- IsGenuineEx() get the current date from the servers (or the computer itself maybe)- IsGenuineEx() allows the product to "remind" the last date it was run- IsDateValid() uses the "reminded" date- So if the user modifies the date back in time, the comparaison with this "reminded" date fails through IsDateValid()

Am I all right ?I tested on my development computer both online and offline, and it's working (at least enough to cover 90% of the fraud cases).

To be honnest, I'm a bit afraid by IsGenuineEx(), especially by "nGraceDaysOnInetErr" : a user could have been activating the product online, then putting the machine offline for the long term. In my industry, this case is very possible.Can I use IsGenuineEx() only to "remind" the last date, and be sure that the product won't never be deactivated ? Maybe by setting "nGraceDaysOnInetErr" with a value 365*10 ?

Thank you. Philippe

(I guess it's not writtent in the documentation).

We're working to fix that. 🙂

Am I all right ?

Yep, that's basically it.

Can I use IsGenuineEx() only to "remind" the last date, and be sure that the product won't never be deactivated ? Maybe by setting "nGraceDaysOnInetErr" with a value 365*10 ?

That's one way to handle things. Another is, when IsGenuineEx() returns TA_FAIL, check IsActivated(). In other words, if IsGenuineEx() is past the grace period then check if you're activated, and if so let the users continue to use your app.

Does that make sense?

Yes, I understand.

When IsGenuineEx() is deactivating automatically the machine :- when the machine was deactivated from LimeLM's website ? (it is as I tested)- when the grace period is finished ? (it shouldn't as I understand)

Thank you. Philippe

- when the machine was deactivated from LimeLM's website ? (it is as I tested)

Yes.

- when the grace period is finished ? (it shouldn't as I understand)

IsGenuineEx() won't deactivate the machine, but it will return TA_FAIL. Meaning you're still activated, but IsGenuineEx() is treating it as if you weren't activated (because daysBetweenChecks + graceDays has elapsed without successfully contacting the LimeLM servers).

Thus when IsGenuineEx() returns TA_FAIL, and you want the users to still be able to use your app if TA fails to contact your servers after N days, then you can check IsActivated() to see if you're activated.

Ok thanx. Much clearer now.

Hello,

If I call IsGenuineEx() then IsDateValid() just after, it can return TA_FAIL sometimes.I think it's because IsGenuineEx() is executed asynchrously, so IsDateValid() can be in conflict : as I understand, IsGenuineEx() changes the "reminded date" every 4 hours at max, and the problem seems to happen every 4 hours.

Am I clear ? How to deal with this problem ?

Thank you. Philippe

First of all, what are you passing to IsGenuinEx(). Secondly what's the "it" you're referencing in your first sentence (which function is returning TA_FAIL)?

I think it's because IsGenuineEx() is executed asynchrously

TurboActivate executes them synchronously. If *you're* executing them asynchronously then, yes, there could be problems.

I execute IsGenuineEx() and IsDateValid() in the same thread, one after the other.IsDateValid() can return sometimes TA_FAIL where it shouldn't (apparently every 4 or 8 hours).

Here are my options for IsGenuineEx() : GENUINE_OPTIONS opts; opts.nLength = sizeof(GENUINE_OPTIONS); opts.nDaysBetweenChecks = 0; opts.nGraceDaysOnInetErr = 365*10; opts.flags = TA_SKIP_OFFLINE;

I want to check as often as possible, and infinite grace period (if always offline for example).

Thank you for your help.

As you currently have it, this is excessive. Only check every 90 days (nDaysBetweenChecks = 90).

Also, the reason IsDateValid is returning TA_FAIL is because the universal time of the computer doing the checking is behind the universal time of our servers. Part of this problem will be solved if you only check every 90 days.

Ok this makes sense (despite I'd be happy to have a 24 hours approximation).

However, "Part of this problem will be solved if ..." makes me nervous : does it solve tha whole problem, or not ?If I set "nDaysBetweenChecks" to 1, it should be ok right ?

By the way : why let people set "nDaysBetweenChecks" to zero if it causes problem ? I really don't understand this ...