secure transport and the code in the repository are not the same thing
they serve different purposes…
secure transport is that you trust the sender and the receiver but nothing in between, This can be solved right now by using file encrypt tools.
But if you only trust the sender, and the receiver shouldn’t have your code visible at all then the only way to really do it is to compile the scripts (so that there is really no source code at all in the export) or somehow obfuscate the code.
Both things need to be investigated and we have to look which one works.
Johan,
Not to be difficult but the Servoy uses code as part of the server executable that grants licenses permitting the server to be used as well as a limited number of clients to be available. That same premise can be used to decrypt the source code when the proper password (password #2 in my example) is supplied. The Servoy licensing scheme is secure, the source code encryption on export (password 2) supplied and decryption on import (password 2 supplied) is just another public and private key pair method used to hide the source code. I would be more than happy to work with you to get this type of functionality into Servoy. The method I outlined would help prevent unauthorized deployment of ISV applications (password 1) and protect the ISV source code (password 2).
but still that will not solve anything…
still the source code would be in the repository for everybody to read.
Because we just need the code, so that we can run it…
And as long as it is (none obfuscated) plain text code that we run it is always readable for everybody that really wants that.
If we just encrypt it based on the password2 why would we need some kind private/public keypair? Again that encryption is purely a transport encryption, nothing more.
That is what I am trying to say : Servoy could decrypt at run-time just before execution. (Other systems can do that).
still the source code would be in the repository for everybody to read.
Another angle on this : We can set our own password for the repository database connection and fill it in servoy.properties file by hand, can’t we ?
How secure is data in databases on disk without knowledge of the proper database user credentials ? I think it is more secure then with a working database connection but how much ?
So maybe with a secret password on the repository database we’re back to the secure solution import ?
i completely don’t understand what you guys are trying to solve here.
The database is of your customer, so he has full control over it and can read it just fine.
If you decrypt it at runtime then anybody can make/patch a client that asks for the code and that one will get it (servoy clients are open source)
so who shouldn’t be able to see your code?
Are you guys making modules? That other developers can use in there solutions? Or do you have just some solutions that you deploy at your customers server?
Maybe there are some assumptions we are making which are not reality so let’s verify some principles so we all have the same common understanding.
The solution javascript code is embedded in .servoy file and is readable as plain text by unarchiving the file.
The javascript code is stored in the application server repository as plain text javascript code when the .servoy file is imported into the application server.
The application reads the plain text javascript from the application server repository and runs the application using the Rhino javascript interpreter.
If the above is true then it is possible to encrypt the javascript code upon export using a developer supplied public key. The private key can be located in the application server code or the public key is sent encrypted to the Servoy license server but in either case the public and private keys are combined to make a third key that is used to encrypt the javascript code when the solution is exported. When the solution is deployed to whatever environment, the developer supplies the public key. The public key is entered when importing the solution and is stored as a hash in the respository amongst multiple other hashed values generated randomly by the application server. The application server uses the private key known only to it to generate the hashed values. When the solution is invoked, the application server decrypts the solution on the fly by finding the hashed public key, combining it with the private key to generate the third key which was used to encrypt the javascript code. The unencrypted javascript code is in application server’s memory (physical, virtual or temporary data table as need be) but is not re-stored in the repository. Each time the solution is run, the solution must be decrypted from the repository using the aforementioned process. This public key is password #1 used to protect ISV applications from unauthorized deployments. The ISV would know which public ley was given to which customer and could track usage by a “call home” function built into their code that could either notify the developer’s system of the usage or remotely authenticate a license. (Continued)
A second set of private-public key pairs could be used to prevent another party with a Servoy developer system from reading a solution. This second public key (password #2) would prevent the unauthorized reading of the source code by a party who has authorized use of the solution via password #1. Password #2 would be given to co-developers and used to allow the application server in devloper mode to store the solution 's javascript code unencrypted in the repository.
Below is a partial slice of an example 32 block of randomly generated hash values that can hide a public key in the repository. Very simple strings were used in this example. They are much more complicated in actual use.
66f65f20c7632857a5c52a04244e4e56
66f65f20c7632857536d4ef262b021b4
66f65f20c76328572362d008b0f6db24
66f65f20c76328578828fdf41226ba1f
66f65f20c7632857cc78dd3102e67e6e
66f65f20c76328576682474160ed3902
66f65f20c763285749dd4bb33c1784b6
66f65f20c7632857bc7bb0b5df14d884
66f65f20c7632857a8375dd245f38a82
None of the above has anything to do with the customer’s database. The javascript code is encrypted in the .servoy file and remains encrypted when stored in the application server repository. The javascript code is only decrypted for the extend of the user session that requires it and not stored in such a way that the end user can access it from the solution.
ngervasi:
If I remember correctly David Workman did something like that in the past, you could ask him.
Three years later and this is finally brought up again
Pretty obvious why there are basically no 3rd party Servoy modules available to developers 8 years after Servoy has been on the market…
We’ve tweaked the process quite a bit but this is basically how we’ve been doing it. Took Troy and I some serious sit-down sessions back in the day to figure it all out but it has proven worth it. End result is that anyone’s code modules can be plugged into our application platform in Servoy Developer and they are good to go.
Catch me at Servoy World next week or send me an email. We’ll be releasing an open source CMS at a session there and one of the options will be to install it with our application platform.
you didn’t answer my question
for who are you protecting your code?
Your solution doesn’t protect any code. I have your code completely in plain side within in hour.
Why? Because all the clients code are open source… those clients get the unencrypted files so if you customer (if that is the one that shouldn’t have access) really wants to see your code
it will be easy, just some java know how is needed.
For me the only way to really do it is using this:
jcompagner:
you didn’t answer my question
for who are you protecting your code?
I’m intrested in this possibility because I want to make my Servoy Framework available for other software companies, that want to build applications on top of my framework.
jcompagner:
For me the only way to really do it is using this:
you didn’t answer my question
for who are you protecting your code?
We want to protect our source code from anyone who runs our solution through smart and web client in Servoy application server mode.
Sounds logical or not ?
But that still doesn’t say anything…
If you are the only one that controls the application server then there is no problem.
But i guess you mean that a customer of yours does have full control over the application server and its databases…
So you only give him your solution file.
This scenario can only be solved by somehow compiling or obfuscating the js code
This scenario can only be solved by somehow compiling or obfuscating the js code
Yes I figured that one out.
Is there a possibility to only import and keep compiled js code (no decompilation possible) in the repository ? (Saves compilation time also on run-time…)
As a former Turbo Assembler Pro I can confirm that if source code can run on a CPU you can also reverse engineer it. It may take some time (just like it would do to re-piece a servoy solution together) but any application can be looked inside, a CPU can and so can you. Take a look at Adobe Photoshop, Adobe spends millions in protecting it and even before they launch their product the cracks are out: you want us to spend millions in providing you with false security? I’d rather spend it on further enhancing Servoy for you (and writing some more docs).
There is also no 3GL or 4GL on the planet for which no decompilers/code steppers/password removers (Access/FMP) readily exist. You can obfuscate code but that it false security, as I have mentioned many times before the only way to protect your source code is to not give it out at all: SaaS (browser-based) is an ideal model for this. Even Oracle, a week after they claimed to be unbreakable had +100 ways to get into so-called secure/obfuscated PL/SQL code. And this list goes on and on.
Keep in mind that if anybody would ever use your source code (been there) you have an extremely good case against them to claim very large sums of money: the best prize you can perhaps get being a software developer is that somebody steals your code. I’m happy to help anybody out that is in this situation. As a developer you have very strong international IP protection, it’s probably the last thing you should be worried about.
So back to practical examples: I’m curious who here as lost boatloads of money because your source code was stolen. To start off: My code has been stolen in a few occasions, it was annoying but I ended up making more money.
Note: none of the above means that we don’t do as much as reasonable to secure your applications.
1- Selling to developers: The value of a reasonable level of obfuscation is that we can control licensing and developers can evaluate our products. Getting nagged every hour to restart and not being able to deploy is just one of those things that helps keep your developers motivated to buy your product if they find themselves using it a lot. So in my opinion it’s not an issue of honesty or getting your solution reverse engineered – we just want to remind developers to buy our stuff when they find themselves getting out of evaluation mode and actually wanting to get some real work done.
2- Deploying on premise: Servoy’s solution “lock” is about as strong as locking a car door but leaving the window open. Building a workspace from a repository is not a big deal. If we were an ISV with a large app that we spent several years developing – on premise deployment would make me think twice.
Removing all of the js code in our solutions and replacing with calls to a plugin that has the code obfuscated has worked well for us on both points. Of course someone could reverse engineer it, but you just can’t come along and copy/paste our code. End result is a good balance point that I can live with and stay awake at night.
I think it would be quite valuable for Servoy to build something of this nature into their product and this is not the first time this has come up. It’s not a matter of making it uncrackable – it’s a matter of finding a level where developers are comfortable enough to start spreading their solutions around.
Thanks for your contribution. I know every software is hackable.
In my opinion it’s all about the amount of effort one must make to crack / hack something technical in relation to the gained value.
I agree with David that the level of source code protection is too low now / the effort level to hack is low.
Servoy has the unique possibility thanks through the existence of an app.server and maybe online license activation the means to deliver a protection / encryption that is unique at each app.server site.
Solution updates through import at the app.server is also a good possibility to ensure an app.server bound (higher) level of source protection.
I’m curious who here as lost boatloads of money because your source code was stolen.
We sold our ARM product to a well-known university in northern California (USA). The university hired an independent programmer to interface our product with the university’s exising software. Within a couple of months, this independent programmer started competing against us with his own version of a product that suspiciously looked like ours. We ended up taking him (and the university) to court, and the court found that the programmer had copied our code and used it to create a derivative product. Although we won the court case, collecting damages has been difficult and futile. We estimate that lost sales to this programmer has cost us several millions of dollars over the years. I don’t know about you, but that is enough to sink our boat!
SaaS is not an option for us. The universities, pharmaceutical companies, and research institutions that we deal with do not want their data going over the public Internet…ever!
Understandably, we are very sensitive to software theft; we know it cannot be stopped. All we advocate is that Servoy do their best to minimize this from happening.