Detecting clock skew in TurboActivate 4 [Yes]

Our product uses TurboActivate 3, and we are preparing a new version using TurboActivate 4. One of the largest sources of licensing failures for our customers is clock skew, so we're hoping that the upgrade solves this issue. A few of questions along these lines:

1) Does TurboActivate 4's improved fingerprinting increase tolerance to clock skew in any way?

2) In TurboActivate 4, is there some way to detect whether a licensing failure is due to clock skew, or divine the category of the issue which caused the failure?

As a workaround: we'd like our product to at least be able to inform customers that clock skew is the reason for their licensing failure. Looking at the API docs it seems like calling TA_IsDateValid with a valid date arbitrarily far in the future might allow us to infer whether TA thinks clock skew has occurred (as it is documented to return TA_FAIL if the TA thinks system date has been tampered with), but wasn't sure if this is an approach you'd recommend as it seems a little off-label.

Hey Jonathan,

>> "1) Does TurboActivate 4's improved fingerprinting increase tolerance to clock skew in any way?"

Yes.

>> "2) In TurboActivate 4, is there some way to detect whether a licensing failure is due to clock skew, or divine the category of the issue which caused the failure?"

Yes, TurboActivate returns different error codes depending on the type of the failure. 2 of those error codes have to do with date/time fraud (rolling back/forward time).

Let me know if you have any other questions and we'll be glad to help.

> Yes, TurboActivate returns different error codes depending on the type of the> failure. 2 of those error codes have to do with date/time fraud (rolling back/forward> time).

Which error codes are you referring to specifically?

The closest we found was TA_E_EXPIRED which could mean that the license has expired *or* that TurboActivate thinks that the system time has been tampered with. As we want to alert our customers when the latter has specifically occurred, we can't do so based on this error code, unless I'm misreading the docs.

We're using TA_IsGenuineEx().

Yes, TA_E_EXPIRED is the error code you should look at. Within the context of TA_IsGenuineEx() it has nothing to do with expiration and everything to do with the customer messing with their date/time.

Well configured machines will *never* get this error code. Only customers who either (a) setup their machine wrong to begin with or (b) are deliberately trying to trick our licensing will get this error.

Also note, a customer changing Timezones (i.e. travel, relocation, etc.) won't cause this error to be thrown. TurboActivate is built for real-world behavior.

Reply
Discard post