Friday, March 24, 2006

protecting your PHP code

By Justin Silverton


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 names

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

Futher 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.


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 sourcecode

2. POBS now knows which ones it should replace and starts writing new files in the target directory


  • yes nice application but alredy decode

    By Anonymous Anonymous, at 10:49 AM  

  • 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)

    By Blogger justin silverton, at 11:13 AM  

  • someday nobody will believe in this stupid and useless security through obscurity.

    I suggest serious people shoudl read this

    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 ?

    By Blogger judas_iscariote, at 10:21 AM  

  • 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.

    By Blogger justin silverton, at 12:40 PM  

  • 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.

    By Blogger judas_iscariote, at 10:54 AM  

  • 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.

    By Blogger justin silverton, at 12:19 AM  

Post a Comment

Links to this post:

Create a Link

<< Home