Users Finding Intrusive

How common are you finding this problem amongst your users?I am about to release an update that includes T4 and verified trials, and I am nervous about this issue. My user base is - let's just say - not very "sophisticated".Does this issue affect verified trials, or just activating a purchased license? If it affects running the trial, then I could see it losing me customers. People who have already paid will likely do whatever it takes to get it working.

TurboActivate needs to be able to read all the components of the computer to actually generate a "fingerprint" of the computer that is accurate. Namely, a fingerprint that doesn't cause false-positives or false-negatives down the line.

Previous to version TA 4.0, we let customers disable network adapters, and then those customer inevitable ran into false-negatives ("your app says my computer is not activated / different even though it's exactly the same"). Then, after digging into the problem, it's inevitably the case that either the customer was using your software on another computer and lying about it OR they were disabling network adapters and thus changing the fingerprint.

So, for these customers that are upset about having to enable their network adapter *temporarily* are the same customers that would complain about being deactivated when disable one adapter and enable another (thus causing a false negatives). Read on for possible solutions for these particular type of customers.

Side note: network adapters aren't the only part of the computer used for the fingerprint. They're a tiny fraction. But they are necessary to make an accurate unique ID of the computer.

So how did we handle these customers? In TA 4.0 we now use all real network adapters (i.e. we exclude fake adapters, VM adapters, bluetooth adapters, other junk, and just use real hardware WiFi and Ethernet adapters). And we also make TurboActivate smart enough that the following cases are true:

1. If the customer is on Windows 8 / Windows 2012 or newer then they can continue to disable network adapters and TurboActivate 4.0+ will be able to read the network adapters without needing admin permissions.

2. If the customer is on an old version of Windows (Windows 7 or older) then TurboActivate will require the network adapter be enabled *temporarily* to read the adapter. The adapter *does not* need to be enabled all of the time. Yes, that's the best practice, but we don't force users to do logical things. See the FAQ about how you can automate this: https://wyday.com/limelm/help/faq/#disabled-adapters

Solutions:

1. Have them upgrade to a modern version of Windows (Windows 8 / Windows 2012 or newer). And then they can continue to use insecure methods for "securing" their network. (See this FAQ for actual secure ways of preventing internet access: https://wyday.com/limelm/help/faq/#disabled-adapters )

2. If they're on old versions of Windows, see the methods here: https://wyday.com/limelm/help/faq/#disabled-adapters

3. One last possible solution that we're considering is make a small standalone Windows Service for Windows 7 and older that will be smart enough to enable any disabled adapters temporarily, read the components, and then disable any disabled adapters.

If the 3rd solution sounds like it will work for you we'll put it together. Shoot me an email at wyatt@wyday.com. This is something we're considering putting in a future TurboActivate release as a "helper tool" for stubborn end-users.

To sum up, even for non-technical users, you can make "one-click" solutions to the problem of the customer running on old versions of Windows with some or all of their adapters disabled. Namely, when you get TA_E_ENABLE_NETWORK_ADAPTERS, just run the TurboActivate Wizard as admin. They click "Yes" and everything magically works.

And please email me if you think you would like to use the 3rd solution I posted here.

I think your solution is clear. I have close to 2-3k users. so I may find more bugs than the next guy. Typically users are NOT techie in the least and are very computer non-literate. Asking a suer to enable their network adapters...I get a response like: "How do I do that?" or "I didn't even know that I disabled it." Then after that, it comes to: "If it takes this much to use your product then I want a refund." Then you start asking the user to dig into dll files, and it all goes down hill for your $99.99 product you just sold them.

I would definitely like the solution you gave, but to be fair, let me do more research on digging into the issues. If you could direct me, as I'm not the developer, on how to fine tune our logging, so we can track the exact issues.

One possible solution might involve a special flag being set in the product key which changes the algorithm used to fingerprint the client machine. Based on that setting, you could either enable the network cards to be used in generating fingerprints or not.

I find myself in a similar situation as GSound. I have a few less than technical users who see disabling a network adapter as a primary solution to a lot of technical problems. And yes, quite a few are still running Windows 7. I think it might be better to give us the option of doing an end run around the entire problem as opposed to forcing exactly one machine fingerprinting algorithm.

Well doing that "solves" one problem but re-creates problems of the TA 3.x algorithm (namely, false positives and false negatives).

Options 3 is what we believe is the best option (small standalone Windows Sevice). Do you think you would like that? If so we'll prioritize it.

> Wyatt wrote:> Options 3 is what we believe is the best option (small standalone Windows> Sevice). Do you think you would like that? If so we'll prioritize it.

A difficult question. As you know, Windows 7 is a dying platform. And by forcing installation and uninstallation of a separate service into an old PC with my product, I wonder whether we might be merely making two problems out of one. In any case, I'd have to detect Windows 7 during installation and require administrator access to install and uninstall the service; my current app runs fine in user mode during installs and execution. I wonder what your thoughts are about a special administrator-mode TA_* function that encapsulates the desired behavior, like this: https://answers.microsoft.com/en-us/windows/forum/windows8_1-networking/script-to-disable-enable-network-interface/8eb15e24-7d85-4a16-b42a-a874b9bb3a28

As much as we know that disabling network adapters isn't a real security policy, we also don't want to go in making changes to the way end-users (and administrators for the end-users) configure their devices.

So, creating a separate function that enables network adapters regardless of the end-user's wishes (no matter how misplaced) is a non-starter.

If you run your app as an admin (or run the TA Wizard as admin) it temporarily enables any disabled adapters TurboActivate needs to read -- just long enough to read the info it needs to read, and then it disables them again if they were disabled to start with.

This is covered here: https://wyday.com/limelm/help/faq/#disabled-adapters

If we make a separate Windows Service it will be as easy as possible to install (calling it with a simple -i commandline switch) and make it possible to just plain old ignore new-Windows. If you're interested we'll put a beta together for you, and likely include it in our packages for other customers.

I've been able to dynamically enable adapters and then disable them from a program using the netsh command from a batch file. The commands of interest are:

netsh interface show interface : Generates a list of interfaces .. use > to redirect to a file.

netsh interface set interface <interface name> ENABLED|DISABLED - can be used to enable/disable an interface.

If the program encouters a TA_E_ENABLE_NETWORK_ADAPTERS error I use the "show interface" to generate a list of adapters redirected to a file. The program then finds interfaces that are disabled and enables them. After enabling the interfaces the program runs activation again. After activation the adapters are set back to their original state.

Getting the batch files to execute is a bit tricky - I used the following:

SHELLEXECUTEINFO shExInfo = {0}; shExInfo.cbSize = sizeof(shExInfo); shExInfo.fMask = SEE_MASK_NOCLOSEPROCESS; shExInfo.hwnd = 0; shExInfo.lpVerb = _T("runas"); // Operation to perform shExInfo.lpFile = sCmdFile.c_str(); // Application to start shExInfo.lpParameters = _T(""); // Additional parameters shExInfo.lpDirectory = 0; shExInfo.nShow = SW_HIDE; shExInfo.hInstApp = 0;

if (ShellExecuteEx(&shExInfo)) { WaitForSingleObject(shExInfo.hProcess, INFINITE); CloseHandle(shExInfo.hProcess); }

Where sCmdFile is the path to the batch file to execute.