Trial issues with TurboActivate and LimeLMSolved

Hi Wyatt,

I am writing you here because I never received a reply to my emails on Feb 29, Mar 1 and Mar 6 when I emailed you directly about various issues I encountered in TurboActivate and LimeLM.

Test Environment:Turbo Activate v4.3.0.0Win10 x64 v1909Visual Studio 2017WinForms C# .NET 4.0 modified sample project: https://mega.nz/#!TjZDjajR!Ho20kyoJokNOBv4riNi1JF3RBrtOESi2luxDC2RLJk0

Issues:

1)Test Case: Trial Extension with an invalid key: 26I5-GVQU-HNSG-THIT-USGF-6GJK-ESXT

Expected Behavior: TurboActivate.ExtendTrial should throw a TurboActivateException. Better yet, create a new type of exception called InvalidTrialExtensionKeyException and throw it (this would be consistent with InvalidProductKeyException)

Actual Behavior: The exception below is thrown and subsequent calls to the TurboActivate dll hang and the process needs to be restarted.

System.Runtime.InteropServices.SEHException: External component has thrown an exception. at wyDay.TurboActivate.TurboActivate.Native64.TA_ExtendTrial(UInt32 handle, TA_Flags flags, String trialExtension) at wyDay.TurboActivate.TurboActivate.ExtendTrial(String trialExtension, TA_Flags useTrialFlags)2) Test Case: Start a verified trial on a computer with Win10 v1909Expected Behavior: The 'OS Version' field in LimeLM for the trial shows that the computer is Windows 10 (1909)Actual Behavior: instead it shows 'Windows 10 (1903), build 18362.329 (64-bit)'

3)Test Case: Generating a TrialResponse.xml file from a TrialExtensionRequest.xml file in LimeLM 'Manual activation / deactivation' screen

Expected Behavior: When the TrialResponse.xml file is created, the activation count on the TrialExtension key should be incremented by 1. This should mirror the same behavior of what happens when we create an ActivationResponse.xml file from an ActivationRequest.xml file using a Product Key. When doing this with a Product Key, everything works as expected.

Actual Behavior: The Trial Extension key activation count is left unchanged.

4)Test Case: Extend a trial using offline activation (TrialResponse.xml) file

Expected Behavior: The trial is extended by the number of days specified in the Trial Extension key

Actual Behavior: The function calls complete successfully but nothing happens (ie. the trial is not extended and remains with its previous count)

5)Test Case: Try performing an offline trial extension (TA_UseTrialVerifiedFromFile) or offline product key activation(TA_ActivateFromFile) when the system clock has been manipulated

Expected Behavior: Expect a DateTimeException. This would be consistent with the online trial extension (TA_ExtendTrial) and online product key activation (TA_Activate) functions which throw a DateTimeException on system clock manipulation.

Actual Behavior: A TurboActivateException is thrown so it is hard to give a descriptive error message to the user since we don't know if the system clock was manipulated or if some other issue happened.

>> "I am writing you here because I never received a reply to my emails on Feb 29, Mar 1 and Mar 6 when I emailed you directly about various issues I encountered in TurboActivate and LimeLM."

We don't see anything about this in support@wyday.com. If you're sending them directly to my email address you might get an answer eventually (if I answer it, or forward it to the support email). But you're bypassing the support mechanisms we have in place (hence, no response from our support team).

#1.

Thank you. That was a bug. We've fixed it and the next version will have the fix.

#2.

We don't update the OS version on every reverification. We might in the future. Right now we use the last version for that machine that started a new trial.

#3. Expected Behavior: When the TrialResponse.xml file is created, the activation count on the TrialExtension key should be incremented by 1.

This does happen. We don't use the trial extension key the customer provide. We generate one internally and show it.

#4. Huh?

I think you're doing something wrong in #3 and #4. If you're doing offline trial activations, don't provide a trial extension. It's ignored.

#5. This is expected behavior. Messing with the date/time/timezone, and all forms of client-side fraud will return any number of error codes. You might get DateTimeException. You might get something else.

If the customer is doing this: tell them not to.

Hi Wyatt, apologies for emailing you directly instead of the support address. I have forwarded my original email thread as well as my responses to your reply to your support email for follow up.

Hi Wyatt, I followed up with you privately On March 12 by emailing support@wyday.com but have not received a response. Can you please confirm whether or not you received my email and are investigating the issues I mentioned? The email subject is TurboActivate system date manipulation issue since my initial email to you was about a different issue.

Hi Wyatt,

It is very troubling to me as a paying customer that I have still not received so much as a response from you regarding the issues that I have pointed out.

I have been very detailed about the issues that I pointed out and believe to be bugs, and have even gone so far as to setup sample projects to replicate the issues as well as video screen recordings describing the issues. I prefer to discuss these issues privately via email and have contacted you multiple times at support@wyday.com and still have not received a response. The video screenshare that I posted in the email shows my IP address in the LimeLM interface which is why I dont want to share the video in this public forum and prefer to have contact via email.

I understand that these are troubling times for everyone, but I have been extremely patient waiting for a reply. Even just a simple thanks for bringing these issues to my attention, I am looking into it type reply, but instead I have not received a single word of contact. I see that you continue to reply to other peoples requests in this forum while my questions and the issues that I have raised have remained unanswered for weeks.

Can you please look for my emails and dignify me with a response so that I know that you are looking into the issues that I brought up instead of simply ignoring them?

We havent been able to reproduce what youre reporting as problems. But rather than just say that again (I said it here already) weve been trying to actually engineer a set of circumstances to reproduce what youre saying youre seeing.

Regarding the time fraud returning different error codes, thats not a bug. Different fraud detection methods will return different errors. Solution? Dont try to trick our software. Legitimate errors in date/time will return the date/time error. Fraud will be detected as such and youll get what you get as far as errors go.

All of the bugs reported have been fixed in TA 4.3.2, out now.

Reply
Discard post