protecting your PHP code
By Justin Silverton
Introduction
A client of mine approached me today and was interested in releasing a PHP based product, but didn’t want his source code to be viewed, in plaintext, by the people purchasing it (mainly because competitors can could easily just purchase a copy and integrate his source code into their product). So, I researched the different options available to protect source code.
What doesn’t work
The various encoders available do not work. These companies/products should just release these products as accelerators (which can improve speed by up to 10X) and not a secure and reliable way of hiding source code.
http://www.phprecovery.com is a website that charges money to decode the following types of encoded files (it is just an example site that I found. There are many more just like it):
- Zend
- Ioncube
- SourceGuardian
- TurckMM
- SourceCop
- ScopBin
- Zend (Gaspra)
- Ioncube (last)
- CodeLock
This site has been tested and it does work. Most people would not bother with the hassle of paying someone to decode your application, but if you offer a more expensive version that includes the full source (and the price is more than it would cost to decode it), then it might just be a better solution.
What works
The best solution is code obfuscation. It may not be perfect, and in some instances, you may have to change your code around a little bit, but it will make it very difficult to re-use your source code.
I prefer a free program called POBS, available Here
How it works:
Replace namesPOBS replaces user-defined (NOT predefined) functions, constants and variables with a MD5 key of 8 characters. (It doesn’t use MD5 keys of 32 bytes, which is standard, since that would increase the size of your sourcecode). 8 bytes seems enough to give each functions or variable its unique name. MD5 is not reversible.POBS replaces user-defined (NOT predefined) functions, constants and variables with a MD5 key of 8 characters. (It doesn’t use MD5 keys of 32 bytes, which is standard, since that would increase the size of your sourcecode). 8 bytes seems enough to give each functions or variable its unique name. MD5 is not reversible.The first letter of the new functionname is a “F”, of a variable a “V” and of a constant a “C”POBS replaces user-defined (NOT predefined) functions, constants and variables with a MD5 key of 8 characters. (It doesn’t use MD5 keys of 32 bytes, which is standard, since that would increase the size of your sourcecode). 8 bytes seems enough to give each functions or variable its unique name. MD5 is not reversible.The first letter of the new functionname is a “F”, of a variable a “V” and of a constant a “C”The function with name MakeImageHtml is replaced by Fee2c1bdc
The variable $ImgText is replaced by $V1d9d94a6
The constant USERDIR is replaced by C389a367e
POBS replaces user-defined (NOT predefined) functions, constants and variables with a MD5 key of 8 characters. (It doesn’t use MD5 keys of 32 bytes, which is standard, since that would increase the size of your sourcecode). 8 bytes seems enough to give each functions or variable its unique name. MD5 is not reversible.The first letter of the new functionname is a “F”, of a variable a “V” and of a constant a “C”The function with name MakeImageHtml is replaced by Fee2c1bdcThe variable $ImgText is replaced by $V1d9d94a6The constant USERDIR is replaced by C389a367eFuther obscuring
In addition, POBS can be instructed to concatenate lines and remove comments and indents. These are not irreversible since a person can write a program to add indents and returns. But it really makes a mess of your code and therefore furtherly discourages many wouldbe hackers from trying to reverse-engineer your code.
Exclude stuff
POBS allows you to indicate which user-defined variables, constants and functions need to be excluded from replacing. In the settings file “pobs-ini.inc” you can add these names to the arrays $UdExVarArray, $UdExcConstArray and $UdExcFuncArray. Do NOT use dollarsigns here.
In $UdExVarArray you are allowed to use wildcards in the form of an asterix (*) at the end of each variablename. I.e. params_* will exclude params_type, params_address and params_name. So if you name your variables to a certain convention you can easily and securely exclude them by group. This way you don’t have to be afraid you forgot to add it to the array in case you added a new variable to your code.
ProcessPOBS consists of 2 major processes.POBS consists of 2 major processes.1. POBS first scans all the files with the file-extensions allowed in the sourcedirectory. While scanning, it makes a list of userdefined variables, functions and constants it has located in your sourcecodePOBS consists of 2 major processes.1. POBS first scans all the files with the file-extensions allowed in the sourcedirectory. While scanning, it makes a list of userdefined variables, functions and constants it has located in your sourcecode2. POBS now knows which ones it should replace and starts writing new files in the target directory
POBS consists of 2 major processes.1. POBS first scans all the files with the file-extensions allowed in the sourcedirectory. While scanning, it makes a list of userdefined variables, functions and constants it has located in your sourcecode2. POBS now knows which ones it should replace and starts writing new files in the target directory
10 Comments so far
Leave a reply
yes nice application but alredy decode
regards
phpRecovery
Really?
okay, I have an encoded function name: a0b1dd848414a1423e556a26a7f3b45a
tell me what the original name is.
obfuscation doesn’t completly hide your code. It just makes it damn hard to do anything useful with it (besides its intended application)
someday nobody will believe in this stupid and useless security through obscurity.
I suggest serious people shoudl read this
http://blog.php-security.org/archives/14-PHP-Encoders-Protection-where-are-you.html
Im sorry to say, any kind of code protection can be defeated, and sometimes ina very easy way…
what should I do to protect my code ?
Well use licences and lawyers, and fix your business model…
your code is too bad and that’s the reason you wnat to hide it right ?
did you really believe that kind of funny protection, gives you real security ?
Your article is just a rant about encoders. It really doesn’t offer any more information that what I have posted here.
lawyers and licenses did not stop music from being copied and shared across the Internet (the record industry may have scared many people into not sharing, , but any song or album can pretty much still be found on right p2p network).
The main problem with commercializing anything written in a scripting language is that it executes in source form. Anyone purchasing it can easily take all of your code and re-implement it in their own application (a programmer can easily change code around to make it different than yours). It’s not an issue with good or bad code.
From an open source perspective, this is fine. As a software developer trying to sell their product, it is something to think about.
sure, it is nearly impossible to stop copyright infringment, but some protection is better than no protection. Some people will still be able to get to your code, but it will keep the casual observer out.
I sell code too, customers won’t buy me the code if encripted,obsfuscated,whatever, and I persuade them to buy any encripted code, is a really bad investement.smart people will not buy it.
1. You can’t modify it, to suit some specific need of you business,
2. you have to load third party PHP/Zend extensions,this extensions modifies the PHP beahviour and sometimes results is nasty bugs.
3. If somebody found a security hole on it, you have to wait until the vendor release a patch, and you can’t patch it, even if you know how to do it, that produces vendor-lock/in security.
the reasons why music is still illeaglly traded in the internet, is due the fact the music industry busniess model is broken, they have not adapted well to the technology,a dn they are trying to invent silyy copy protection systems..like a the sony trojan horse..
The funny thing is that will never work,since it’s totally breakeable.
I think it really depends on the application you are selling and the type of client that will be purchasing it. Most commercial apps on windows are closed source, and people still buy them. There is room in this world for both closed and open source software.
I might use zend or the ioncube encoder (I think you can include a special loader with an ion cube encoded file that doesn’t require an extension load) for a trial version of an application, but probably not with a purchased product.
The music industry went wrong when they destroyed napster. They should have embraced it as a new distribution/business model and probably would have made even more money than they are making now.
There will always be illegally traded software, movies, and music on the Internet. It was around before p2p and will still be around after. It has more to do with people wanting free stuff than a flawed business model.
“okay, I have an encoded function name: a0b1dd848414a1423e556a26a7f3b45a
tell me what the original name is.”
Who cares? Just search for that key in all the files, and rename it to whatever you want.
Who cares? Just search for that key in all the files, and rename it to whatever you want. ”
you may be able to do this, but most programs have lots of functions and files and it becomes a big pain after awhile. Like I said, the method is not perfect and if someone really wanted to get around it they could, with a lot of effort. But, it is better than using an encoding system that can be easily cracked (if you do a search on google..you can find a lot more services for cracking zend, ion cube, and the other encoding solutions than the site that I mentioned above).
Despite what most people say, security through obscurity IS security, and it works great as a FIRST line of defense. This is a deterrant, not a holy grail. Paired with the threat of litigation, exposure, etc. this makes stealing source much less attractive. The work has to be done to figure out the code and figure out every function, then rename it, etc. until you have something workable. The more barriers to entry the better.
A paper door won’t stop anybody, but if they know there’s a steel door behind it, chances are the paper door will do the trick.
> Paired with the threat of litigation, exposure, etc. this makes stealing source much less attractive.
Au contraire, it makes it more attractive!
With the DMCA in place “cracking” such “encryption” would be a criminal act. If you can’t proof–”beyond a reasonable doubt” because it’s a criminal act!–that I “cracked” your “encryption” I have not “cracked” your “encryption” which means that you can’t proof that all of the similar lines of code are the result of a copyright infringement.
> The work has to be done to figure out the code and figure out every function, then rename it, etc. until you have something workable.
That’s about half a dozen lines of perl because you don’t have to figure out every function, just rename it.
A much bigger problem and a more realistic one is the need of extra software at runtime, e.g. the Zend-obfuscator. The first time I had met Zend (the optimiser) it smashed the stack randomly and it took me nearly one day to find the appropriate entry in the buglist and it took Zend AFAIR nearly 4 month to repair it.
So, I should risk my business because you fear that I, your paying customer, might steal some lines of your precious code? And you won’t give me some warranty in exchange? Your licence says in big, bold and uppercase letters that your are not liable for anything? You won’t even guarantee me that your bunch of bytes works as described? You don’t care because the clients pay anyways even for the fixation of the bugs in your software?
*sigh*
Way over 90% of all software written is produced in-house. You can’t expect to make much money with one-size-fits-all-COTS-software if you are not very large already. It’s not a sound busines-plan anymore, the money is in services now. So, if your business model depends on closed sources (that’s different from “ClosedSOurce ™”, it’s general and includes a lot more than mere code) and your are not a multi -billion-dollar company expect a mid to long term failure (but it’s quite good for the “quick buck” of course). At least I as a prospective customer do, and I will think twice if I need the program a bit longer than some two or three years.
There are companies which offer warranties, take the liability, write almost bugfree software in the first place and all for the same price and in the same time (if you include the number of bugs in the calculation it’s even cheaper and faster!).
Apparent rari, nantes in gurgite vastos, but they are out there.
I wouldn’t even ask for the code, when I don’t need it (there are exceptions of course, e.g. encryption, very sensible data etc.): if I find a bug it will be repaired if it’s in guarantee and if I don’t find the virus included in the product the company takes it and the insurane company pays it and if I need a new feature the company can do it better and faster and probably even cheaper. The single risc left is a bancrupt company, but the gastric ulcer is just a common cost of doing business and you can even hire the loose developers.
CZ