Many software vendors use subscription model when a user purchases a year of updates and then he decides wheather to prolong.
By not purchasing a prolongation a user still able to continue to use his current version but not able to use newer updates downloaded from the vendor website. I guess Enigma uses similar model.
Please let me know, how it is possible at the same time (I know how to achieve most items individually with Enigma):
1) Lock to the hardware, even free trials shall be locked.
I guess a solution would be not using Enigma trial feature at all and automate my website to issue general hardware locked licenses but for $0 zero price valid for a short period of time or with a very limited feature set.
2) Allow users to continue to use their version forever but reject them to use updates without new registration (free or paid depending on the feature set)
Expected solution: shall we constantly change program key pair for each release?
But in such case a license will become invalidated even for nearest updates even during subscription period and a user will need to register each update again. It is the most unclear thing to me, how to make updates valid for subscriber and invalid for users with already expired subscription having the same setup.exe and still each license shall be lifetime duration for old versions?
How to make lifetime license still able to expire updates?
How to make lifetime license still able to expire updates?
Last edited by sanyock on Thu Oct 31, 2013 2:46 am, edited 1 time in total.
Re: How to make lifetime license still able to expire update
I guess a solution could be changing a key pair each year for each major release like: 2013, 2014, etc.
But in such case subscription periods will not be precise and a user will be able to get newer updates even after his subscription expired for the rest of the year.
For example:
Users subscription expires at: July 1, 2013 for a release like "Some Software 2013"
Since we provide him a lifetime license he is able to use any update of "Some Software 2013" even in the Augest, 2013, and next months until we stop provide updates with key pair for the "Some Software 2013".
When we release a new version with a new key pair like "Some Software 2014", his lifetime license will become not suitable anymore for new major version 2014 and any of its update having a new key pair.
Is there any way to reject a user from "Some Software 2013" updates since his subscription expires but still allow him to use any minor release of "Some Software 2013" built in the first half of the 2013 year?
But in such case subscription periods will not be precise and a user will be able to get newer updates even after his subscription expired for the rest of the year.
For example:
Users subscription expires at: July 1, 2013 for a release like "Some Software 2013"
Since we provide him a lifetime license he is able to use any update of "Some Software 2013" even in the Augest, 2013, and next months until we stop provide updates with key pair for the "Some Software 2013".
When we release a new version with a new key pair like "Some Software 2014", his lifetime license will become not suitable anymore for new major version 2014 and any of its update having a new key pair.
Is there any way to reject a user from "Some Software 2013" updates since his subscription expires but still allow him to use any minor release of "Some Software 2013" built in the first half of the 2013 year?
Re: How to make lifetime license still able to expire update
Hi sanyock,
This question had been answered me many times.
I usually advise two following ways:
1. Most good to my mind. Hardcode the expiration year (month/day/version number etc) using decrypted sections. For example, user purchases version 2.3.4 and you are allowing to use all versions below 3.0.0. Imagine 2.3.4 is a number 234 (you store it inside your program), version 3.0.0 is a number 300 and you have hardcode it into license key.
The number 300 is a decimal number, you may convert it into binary form and in bin it is 100101100.
When you generate a key, you have 16 decrypt sections there. Imagine that each section is a bit value, so you have 16 bit of information you may hardcode into the key. 16 bit can hardcode in maximum decimal number 65535 (which is enough in our case).
We have to hardcode the number 100101100 (300 dec), so the following sections should be enabled (if 1) or disabled (of 0): 0000000100101100
Then, inside the program, use the function EP_RegKeyInformationA/EP_RegKeyInformationW to extract the sections that the current key decrypts and using this information build a hardcoded number.
Seems elegant solution.
2. You may just add an expiration date/version information into reg. name field, then get it using EP_RegLoadKey and parse the information to extract necessary values.
This question had been answered me many times.
I usually advise two following ways:
1. Most good to my mind. Hardcode the expiration year (month/day/version number etc) using decrypted sections. For example, user purchases version 2.3.4 and you are allowing to use all versions below 3.0.0. Imagine 2.3.4 is a number 234 (you store it inside your program), version 3.0.0 is a number 300 and you have hardcode it into license key.
The number 300 is a decimal number, you may convert it into binary form and in bin it is 100101100.
When you generate a key, you have 16 decrypt sections there. Imagine that each section is a bit value, so you have 16 bit of information you may hardcode into the key. 16 bit can hardcode in maximum decimal number 65535 (which is enough in our case).
We have to hardcode the number 100101100 (300 dec), so the following sections should be enabled (if 1) or disabled (of 0): 0000000100101100
Then, inside the program, use the function EP_RegKeyInformationA/EP_RegKeyInformationW to extract the sections that the current key decrypts and using this information build a hardcoded number.
Seems elegant solution.
2. You may just add an expiration date/version information into reg. name field, then get it using EP_RegLoadKey and parse the information to extract necessary values.
Re: How to make lifetime license still able to expire update
It would be very good method for me, I can add any sensible amount of information into the name field as a suffix for example a string of keys/values, or just positional values encoded in 64base or like this.Enigma wrote: 2. You may just add an expiration date/version information into reg. name field, then get it using EP_RegLoadKey and parse the information to extract necessary values.
Very good idea, could not guess by myself
Is it possible to do a customized registration dialog by means of Enigma IDE where name would be divided into two visual fields: actual name and a suffix like "more info" or "key part 1", though it is not a key?
So in total 3 fields: name, key part1, key part2 (which is an actual response key from developer)
Re: How to make lifetime license still able to expire update
another idea, most likely would not work:
Can we use an existing date field of a key like expiration date for a purpose different from its direct meaning by disabling its main purpose depending on a feature bit?
For example:
For trials we would NOT set "paid" bit and use expiration date by its direct purpose to expire in some short period of time and even use hardware binding
For paid version we would set "paid" bit and somehow disable direct meaning of expiration still using hardware binding, so that the program would not expire anymore, but we would still use expiration date field of the key to control expiration of updates comparing it to the build date of the executable? Is it possible?
Can we use an existing date field of a key like expiration date for a purpose different from its direct meaning by disabling its main purpose depending on a feature bit?
For example:
For trials we would NOT set "paid" bit and use expiration date by its direct purpose to expire in some short period of time and even use hardware binding
For paid version we would set "paid" bit and somehow disable direct meaning of expiration still using hardware binding, so that the program would not expire anymore, but we would still use expiration date field of the key to control expiration of updates comparing it to the build date of the executable? Is it possible?
Re: How to make lifetime license still able to expire update
Sure, that's possible, why not. You can make own registration dialog, with any fields you would like, and just call a function EP_RegCheckAndSave key to check if the license is valid. So before calling of this function you can merge Reg name from multiple input fields.sanyock wrote:Is it possible to do a customized registration dialog by means of Enigma IDE where name would be divided into two visual fields: actual name and a suffix like "more info" or "key part 1", though it is not a key?So in total 3 fields: name, key part1, key part2 (which is an actual response key from developer)
No, unfortunately this is not possible. Protection rejects the key if it is expired.sanyock wrote:For paid version we would set "paid" bit and somehow disable direct meaning of expiration still using hardware binding, so that the program would not expire anymore, but we would still use expiration date field of the key to control expiration of updates comparing it to the build date of the executable? Is it possible?
The only case you may use such way - if you will handle license checking/saving/loading yourself (you will save and load key yourself in your custom location), and to check the key you may use the function EP_RegKeyInformation. Note, the functions like EP_RegCheckKey may not work in this case, because key may be expired. So protection will think that there is no valid key. For example, trial will not reset in this case, and you will have to handle such "license dependent" features yourself.
Re: How to make lifetime license still able to expire update
1) What do you think about adding such a feature of dual meaning for the Expiration Date depending on such additional option which would dedicate one of feature bits?Enigma wrote: No, unfortunately this is not possible. Protection rejects the key if it is expired.
The only case you may use such way - if you will handle license checking/saving/loading yourself (you will save and load key yourself in your custom location), and to check the key you may use the function EP_RegKeyInformation. Note, the functions like EP_RegCheckKey may not work in this case, because key may be expired. So protection will think that there is no valid key. For example, trial will not reset in this case, and you will have to handle such "license dependent" features yourself.
2) What do you think about using a "register before" already right now giving it a value of the date of issuance of a key + 1 year (or another duration of subscription), then extract it and use as an indication of subscription expiration while "expiration date" can be set to for example 100 years ahead to allow an old version to work semi-indefinitely?
In addition to Enigma we could add a simple online or even phone activation like MS activation if ready outsourcer is available as a SAS. It could be a simple handshake just to indicate an user has registered the software and the date of registration. Then a user who was not able to register in time could ask for a newer license to register even after "register before" date.
Re: How to make lifetime license still able to expire update
Just decline this idea, it's too complicated...sanyock wrote:1) What do you think about adding such a feature of dual meaning for the Expiration Date depending on such additional option which would dedicate one of feature bits?
Yes, that's would be possible to do, agree. Register before value would be the best choice. And you may just not use expiration date at all, because it loses the sense in this case.sanyock wrote:2) What do you think about using a "register before" already right now giving it a value of the date of issuance of a key + 1 year (or another duration of subscription), then extract it and use as an indication of subscription expiration while "expiration date" can be set to for example 100 years ahead to allow an old version to work semi-indefinitely?