Run on VM - No Turbofloat - Net Lic Verification EnforcedSolved

The problems you're having with any node-locked licensing on VMs, and the solution to said problem is described here: https://wyday.com/limelm/help/vm-hypervisor-licensing/

>> "Now, I enforce checking the License every 0 (for VMs, 30 for real PC *) days on the Internet. I am trying to foresee what "loopholes" this may cause for those who want to cheat: (* 0 grace period)"

Well that doesn't really solve any problems. Cloned VMs will still validate. And VMs that are the same, but their fingerprint has changed (e.g. Amazon VMs) will still be seen as different devices.

The solution is to use TurboFloat.

In the near future we're adding a hosted TurboFloat Server version where you can give customers permission to spin-up instances of the TurboFloat Server on our infrastructure. I think that would be the best solution for you.

Sam wrote:> ........> Well that doesn't really solve any problems. Cloned VMs will still validate. And VMs> that are the same, but their fingerprint has changed (e.g. Amazon VMs) will still be> seen as different devices.> ..................

Thanks a lot for your quick reply: But what you write "Cloned VMs will still validate." is not entirely correct as I describe above, at least not for VMWare WMs: As I described, there are two ways to Clone a VMWare VM:

"I Copied it" ==> The VM gets a new fingerprint, and the LimeLM license does NOT work any more!

"I Moved it" ==> The VM keeps the fingerprint, and the LimeLM license does work.BUT, running several of these instances on the same network will cause network chaos!

I think I will document that VM activations are tested on the following platform: (<List>), and take my chances.

Q1:Do you have any idea ** when ** the WyDay hosted Turbofloat licensing will be up and running?

>> "Do you have any idea ** when ** the WyDay hosted Turbofloat licensing will be up and running?"

No, we'll update this topic when a schedule is in place. It's a priority, but no firm date right now.

Wyatt wrote:> No, we'll update this topic when a schedule is in place. It's a priority, but no firm> date right now.

Thanks Wyatt,What I said above about "network chaos" is not correct, so cloning a VM with the same fingerprint is a problem.

However, I have an idea: I can write a "Unique Session ID" (SID) to a Custom Field every time my App starts. I keep track of the previous and current SID, and on every startup check what is the last SID written this Custom Field: If it is not the Apps previous SID, I can revoke the key, because then it is obviously used by more than one user.....

What do you think of that?

I think that idea has 1 security vulnerability and a number of other flaws.

The security vulnerability is that you cannot (should not) call web API functions from within your app. Calling the web API from within your app requires an API key to your account, which is equivalent to the "master key" of your account.

Using TurbFloat is the only bullet proof solution that is designed from the ground up to handle VMs, containers, and every other form of emulation.

Wyatt wrote:> I think that idea has 1 security vulnerability and a number of other flaws.> > The security vulnerability is that you cannot (should not) call web API> functions from within your app.

Every String in my App is encrypted and code itself is heavily obfuscated. The chance of breaking it, is no higher than breaking into my site that uses the API key for License Key generation (code there is also obfuscated & strings encrypted) the way I see it.

Another way of doing this, would be to have a Web Service running at my site that I can call to get the SID: Then the API key is not in my App....

What are the other flaws you where referring to?

>> "The chance of breaking it, is no higher than breaking into my site that uses the API key for License Key generation (code there is also obfuscated & strings encrypted) the way I see it."

Well, a couple of things.

1. All "encrypted" strings in a program are symmetrically encrypted by-design (otherwise they would be useless). Meaning your app includes the key to decrypt the strings in-app. Not to mention the fact that all strings will be decrypted when they are used. So malicious person with basic debugging skills will have full access to the API key and thus full access to your LimeLM account.

2. Let's say the malicious person does not have those basic debugging skills. All they would need to do is generate a self-signed SSL cert and MITM communication from your app to the wyDay servers on that one PC. Boom, they have all data sent to the server in plain text (including your API key -- again giving them full access to your LimeLM account).

So comparing the time it would take to brute force "guess" your API key and the time it would take to extract it from your app are not even in the same ballpark (we're talking centuries to brute-force and seconds to extract it from your app).

Long story short: don't use the web API from your app. Only use it from back-office apps (apps only available to you and your developers) an/or from your actual web-servers.

The warning we put on your settings page about not using the web API from within your app is not paranoid, nor should it be ignored.

>> "Another way of doing this, would be to have a Web Service running at my site that I can call to get the SID: Then the API key is not in my App...."

I don't see how this solves the VM cloning issue (a problem, I should re-iterate, we've already solved with TurboFloat).

Hello & Thanks Wyatt,

I see; I will NOT put my API Key in my App!

However, I do think I can solve the Clone VM problem with my approach: I can store the SID on my server in a DB, and use a Web Service to communicate with it.

Bothering developers with installation of Turbofloat is not acceptable: I have spoken with quite a few: I will loose sales if I do, BUT I need to support VMs: Many developers these days use VMs!

I will test it, but **not** use the API Key from my App.

>> "I can store the SID on my server in a DB, and use a Web Service to communicate with it."

Session ID's are not globally unique. They can be cloned alongside a VM. TurboFloat does not suffer from the problem.

It sounds like the only true solution for you is us hosting the TurboFloat Servers. What's your deadline on this. We might be able to get a beta version of our hosted TFS instances out in enough time.

Wyatt wrote:

> Session ID's are not globally unique. They can be cloned alongside a VM.

You misunderstand me: As I said above, I will create my own Session Id (SID) on the fly each time my App starts: It will be unique for every VM Clone and for every time the App starts: The on the fly generated SID will be stored on my Server (SHA-256 Certified) and locally (encrypted):

When verifying the License, I will check with my server: (If that communication has been blocked, I will terminate my program). If my last SID does NOT match the SID stored on the server (for the License), it means that more than 1 VM is using the same License: I will then, using my server, revoke the License.It will work, I have done similar things before in LabView.

Hello,

For anyone interested, it is tested and this works!

I have a WCF Service running on my Server. It validates that only ONE VM is running my Program (without contacting the LimeLM Server).

If more than one is in play, I Revoke the Key, and send an Email to the original Product Key owner.