Scenario:
I'm looking to protect my software that is written in PHP. The nature of PHP is that it is delivered as plain text and therefore cannot be protected by itself. I don't want to install libs to the server like ZendGuard, IonCube or SourceGuardian. I want that individuals should use the software but should not interfere with the protected part of the application (licensing, sensitive parts). The software is distributed to clients as trial software.
Solution Concept:
Encrypt the payload with a blockcipher (AES) and store the key on a remote system. To software would require the key to decrypt the payload. An obfuscated part of the software should contact the key server via cURL over SSL and request the decryption key. The decryption key should only be sent back to the Server IP that holds a trial license. A checksum of the files could also be posted with the key request and if it even fails once, the key server could reject to provide the decryption key forever, which should hopefully prevent tampering.
Notes:
- The client requesting the trial will be known in advance so unauthorized copies of the software should never receive a (correct) decryption key in first place.
- The decryption keys are unique to every client and the payload parts are too.
- The code will never be stored decrypted but only decrypted at runtime and eval()'ed.
Questions:
- Is this a feasable or doomed to failure?
- Wouldn't this protect even against the tiniest tampering by anyone?
Thank you!
Best Answer
Let's see. Once your key server sends the decryption key, the hacker can monitor network activity to retrieve the key and use it to decrypt the source code. From this moment, he can do whatever he wants with it, especially:
Modify it in a way that it will either send the checksums you are expecting, and not the actual checksums of files,
Replace the part which contacts the key server, or simply remove it to avoid the check,
Post on P2P networks the decrypted source code with key checking part removed.
On the other hand, some part of the legitimate users of your product will probably prefer using the product of your competitors, because:
They'll find that your app is slow to start. Contacting the remote key server takes time, which may or may not be accepted by the end users.
Decrypting takes time too, which can waste too much resources on servers. Your competitors' products may achieve much better CPU footprint if they don't add this sort of complexity.
Banning by IP will cause additional problems. Most users have dynamic IPs, which means that a ban will affect the concerned person only for a very limited amount of time (such as one day), and then prevent other persons to access your product. In the same way, banning the whole company or a wifi spot is rather unfortunate in terms of marketing.
They won't accept to rely on a fragile product (unless you work in a very large company which guarantees that the product will be maintained for the next 5, 10 or 15 years). Not having the source code means that:
If your company stops maintaining it, your customers will be using an obsolete product which may contain known but unpatched bugs.
If a customer wants to modify it, he has no other choice than to pay you (often a lot, because of the monopoly) to do the change.
They won't accept to rely on a product which can contain malware. If you're a known company with excellent reputation, this is not an issue. If you're a startup or don't have a well-established reputation, some customers would not install your app because of the risk of malicious code. This is especially important on servers which are often more protected than desktop PCs in companies.
If you actually invented something that should be protected (and very probably, you haven't), the only way you can protect it is to move the sensitive code to the servers you own, and then provide an API to access the functionality from the outside. As soon as you give the code, no matter how well is it protected, it can be decrypted; otherwise, it wouldn't be possible to run it.
If the only goal is to have a trial version, simply host it on your own servers. Potential customers will be able to try it, and if they are interested, purchase the product. Of course, in order to convince sysadmins as well, you should also provide very detailed information about the way your app should be deployed and hosted.
Later, when your product becomes successful, you may consider evolving your offer, by providing:
The limited in time demo hosted on your server,
The pay-per-month subscription where the product is still hosted on your server. Multiple variants of subscriptions may target separately individuals, small companies and medium-sized companies. For small entities, the product may be out of charge for a year or some other long period of time (or forever).
The more expensive solution where the customer deploys your app on his own servers. This solution may target large companies.
With this model (used by many startups), encryption of source code becomes mostly irrelevant. Large companies won't try to download your product from a P2P network, because of all the compliance policies which prevent them from using unlicensed products.