Securing a PHP Product - btcompiler and license keys?

Question

Multi Part Question:

I am developing a php app that I plan to sell and distribute. I want to control who has access to the apps main functions and installation though some sort of call to my server, which would check to see if the script's install location (example.com) is in a database, maybe even check for a license key of some sort.

1. Anyone have any general guidelines for securing a distributed PHP program? I don't expect total security, but I would like to release the script with a trial, and would want to discourage the average person from monkey-ing around with the code to try and circumvent buying the script.

2. I had two ideas in mind - having a script "phone home" with the script server address, and checking that address against a database (simple enough), or doing that in addition to generating some sort of license key and hard-coding that key into the script, either in a file, or in the DB install queries.

   My question is, if I go the latter route (hard-coding), what is the most efficient way to hard code a key into a script at runtime and package it all into a unique zip file?

3. I would be using bcompiler to try and obfuscate the authentication functions used above. I know you need to have support for bcompiler compiled into php in order to write bytecode, but are there any special requirements to run compiled bytecode? My app will run on a variety of machines, but with the common condition that they would all be running php5, so the code needs to be able to work on restrictive hosting environments (where they can't upload external terciary php libraries, for example).

Any and all insights are strongly appreciated.

Can anyone answer my last question? Can php w/o bcompiler read and execute bcompiler generated bytecode files?

Answer 1

Hi,

Taking a look at these questions/answers might help you at least a bit :

• How to prevent resale of PHP source?
• Best solution to protect PHP code without encryption
• How does one protect a web application sold on a per license basis from piracy?
• Code obfuscator for php?

It will not fully answer your questions, but might still prove useful :-)

Still, my main thought would be that your problem is more a legal problem than anything else : if your clients want to rob you, they probably are not clients you should try to keep... The most important thing to do would probably be to have a solid contract with your clients, that define what they can, and cannot do ; there will always be people trying to go arround whatever "protection" you can set up -- and they will most likely succeed anyway...

If you want to get into that kind of business, you'll have to get a great EULA ; this is more a legal than technical business, and you'll certainly need help from someone whose job is about legal stuff.
Still, going through EULA from applications / websites you are using can give you a couple of pointers.

As a sidenote : about the "call home" idea : make sure that, if your "home" website/application is down (this will happen, one day or another), it doesn't bring down all the websites on which your application has been deployed -- I'm pretty sure your clients wouldn't like that ^^

Also : make sure the fact your software is "calling home" every now and then is clearly stated somewhere in the EULA / documentation : if your clients find out by themselves your application does network requests they didn't aggree for, it'll bad for your PR.

And : I've seen (several times) applications deployed on servers configured so they couldn't do request to the outside of a company's network (they say "security reasons" or stuff like that) -- there's not much you can do in that kind of situation, I suppose...
Another approach would be not to distribute an application, but provide a service : don't sell the application itself, but host it, and sell services -- that is what many companies do (for instance : google, with gmail or google docs ; bur there are so many other examples), and if the service is great, it can work out pretty well.

I should add that this gives you more ability for updates, to correct problems faster, for insatnce, or just add new functionnalities ... And you have control over who can use the application ;-)

Thie biggest problem with that idea is that your application must know (almost) no downtime : you have to find a great hosting service, create backups, be reactive, able to solvfe problems fast, ... Not an easy job either, actually !