I want to protect a solution for a period of 3 months at which time if is not updated I need it to fail, even though the Servoy license is still active.
Of course I could put an If(… statement in but would like someway that would be real hard to crack.
I was thinking about looking at a remote database and pulling a code or using a hash to Authenticate timeline or something stronger.
Any idea would be greatly appreciated.
You can store an encrypted expiry date in a table and check that on solution opening, easy to implement and difficult for the users to crack.
And to prevent the users to simply put the server clock back in time you could setup a simple webpage on a trusted server to return the correct date and retrieve that using the http plugin:
Thanks Nicola,
What algorythm would you suggest I use for the encryption.
I can see ecrypting the date but I am not sure on how to decrypt it.
Take a look at the Cryptor plugin from IT2Be, it’s perfect for the job. And don’t forget to say thanks to Marcel…
Thanks I really appreciated the help,
I not only put the real date on a remote server but the activation date as well.
The code was real simple on the server, 5 lines each, 2-php files!
<?php
// return time stamp (real date)
// e.g. 2008.04.21
$today = date("Y.m.d");
echo $today;
?>
<?php
// return (activation date)
// e.g. 2008.07.21
$today = "2008.07.21"
echo $today;
?>
Nicola thanks again for the hint and of course Marcel for the http: plugin.
Coorection the first php code should be
<?php
// return time stamp (real date)
// e.g. 2008.04.21
$today = date("Y.m.d", time());
echo $today;
?>
Briggsy-is-back!:
Nicola thanks again for the hint and of course Marcel for the http: plugin.
You’re welcome!
But Marcel wrote the Cryptor plugin, not the HTTP. The HTTP plugin is a default Servoy plugin.
Just to be fair…
Note that it is really easy to modify the method that does the check even if you locked your solution. Methods are plain text in the repository database.
So this approach will keep your honest clients honest but pretty weak otherwise.
David, as you know I am the list of beta testers for Frameworks and have been following its development quite closely.
I know that the security enhancements with Frameworks really make it easy to use. Will Frameworks provide the type of security I need?
What recommendations do you suggest?
david:
Note that it is really easy to modify the method that does the check even if you locked your solution. Methods are plain text in the repository database.So this approach will keep your honest clients honest but pretty weak otherwise.
That’s true.
But there’s no way to put in place a better security cause anyway you do it (external server check, custom plugin, etc.) you will have to run some javascript code in one of your methods to perform the check and that code is always stored in the repo in clear form.
The point here is that a basic security measure is worth to be put in place to discourage the basic users but there’s no point in setting up complex security measures cause all of them will fail when attacked by someone with a good knowledge.
I think that if you need to put in place very tight security checks the problem is not with you software but with your customers.
Don’t change the software, change the customers.
Briggsy-is-back!:
I know that the security enhancements with Frameworks really make it easy to use. Will Frameworks provide the type of security I need??
Yes. And if you’re an ISV or a developer that wants to sell a Servoy module I would recommend using the same technology we developed to lock down our frameworks.
ISSUES
1- Servoy default lock
you can import a locked module but you can’t export it. this makes transferring a solution that includes a locked module from a 3rd party fairly difficult
can’t go into design mode. developing with an included locked module is aggravating
it’s an all or nothing lock. very difficult to make a locked module extensible
you can unlock a locked solution if you know a few things
2- Servoy methods in plain text in repository
impossible to implement a robust license system
makes it easy to do all kinds of modifications to your code
Basically, you can’t sell a servoy module/solution with Servoy’s default lock to other Servoy developers. A vertical market solution is about all it’s good for. Even then I would not be comfortable with this approach.
SOLUTION
optional:
4. Add license code check to any number of methods before obfuscating
BENEFITS
IMPLEMENTATION
We created a Servoy solution for this process. It gives you a list of all methods for any solution/version in a repository database of your choosing. You then select which methods you want to obfuscate. Our obfuscation steps (off the top of my head):
EXAMPLE
/*
* TITLE : FX_actions_sub
*
* MODULE : _FRAMEWORKS_
*
* ABOUT : get requested navigation_item properties
*
* INPUT : 1) config_type value (admin/user)
* 2) navigation set ID
*
* OUTPUT : 1) itemName array
* 2) formName array
* 3) navItemID array
*
* REQUIRES :
*
* MODIFIED : Mar 24, 2008 -- Troy Elliott, Data Mosaic
*
*/
var searchValue = arguments[0]
var navID = arguments[1]
var navigationSets = new Array()
var valueList = new Array()
var formList = new Array()
//get [searchValue] modes
var navItem = databaseManager.getFoundSet(controller.getServerName(),'mosaic_navigation_item')
navItem.clear()
navItem.find()
navItem.id_navigation = navID
navItem.row_status_show = 1
navItem.config_type = searchValue
var results = navItem.search()
if (results) {
navItem.sort('node_1 asc')
for (var j = 1; j <= navItem.getSize() ; j++) {
var record = navItem.getRecord(j)
navigationSets[navigationSets.length] = record.id_navigation_item
valueList[valueList.length] = record.item_name
formList[formList.length] = record.form_to_load
}
}
return {itemName:valueList,formName:formList,navItemID:navigationSets}
(See attached pic – forum wouldn’t upload due to the weird characters)
/*
* TITLE : FX_actions_sub
*
* MODULE : _FRAMEWORKS_
*
* ABOUT : get requested navigation_item properties
*
* INPUT : 1) config_type value (admin/user)
* 2) navigation set ID
*
* OUTPUT : 1) itemName array
* 2) formName array
* 3) navItemID array
*
* REQUIRES :
*
* MODIFIED : Mar 24, 2008 -- Troy Elliott, Data Mosaic
*
*/
var args = new Array(arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5], arguments[6])
return plugins.Frameworks.performFunction(forms.FRAMEWORKS_0F_solution.FX_actions_sub,args,"86376305-082c-459f-ab37-ae4708e15239")
SUMMARY
We’ve been posting all of our frameworks builds to our beta testers for the last four months with this technique. They can go into design mode, integrate their modules with ours, export the entirety – with no hassle to them. Our modules are completely extensible and modifiable and yet our code is protected.
If you want to test this out for yourself, email me a solution (nothing proprietary please, but as complicated as you want). We’ll obfuscate it for you and send you back an export of a “locked” solution along with the plugin to make it run.
Cheers -
David
As a beta tester I can attest that the obfuscation works well. I can also debug ok. I can also insert my own code either before or after the Frameworks code to “extend” or “pre-extend” (is that a word?) their method. Prior to their obfuscation approach I was one of the testers who was VERY frustrated at not being able to debug properly.
Cheers,
Tom