I remember seeing a discussion on this forum about this... a year ago or so...
The keypoint of this discussion as I remember it, was that there is no such thing you can do, that can't be decifered. There was some software mentioned to do some encryption (commercial) and some other guy tried to develop one of his own (but failed if I remember well).
What you can do to make it harder to read is to remove all spaces and line breaks, rename varibles and functions to some random strings etc.(it's called obfuscation and there are some scripts to do that).

Iocube is very good. Obsfucation is the key as well and both Zend and Iocube do it. The Iocube basic version only does compilation not server licensing but that is tied to from your machines licence or by a key you can give the process as well. These things you have to pay for though as the loaders used to do these things are closed source and custom developed. If the source was open it would make it easier to decompile what they loaded ( internal slight of hand techniques ).

Supposedley the source does not exist anymore and what can only be gotten out is what the machine thinks is the source. Bit beyond me but involves opcode decompilation and other voodoo.

I just sent a file to zenddecode and got an email saying it would be ready in 1-7 days which sounds like they are going to try and rewrite it by hand using watched opcodes.

Interesting to see the file diff if I do get something and whether I have just been added to the big spam list somewhere.

I would go to ioncube forums as they are very active and I always got a response in an hour. The zend ones are pretty quiet but you could try them well. Obviously you are going to get biased responses but the guy in change of Ioncube has quite an active web presence so you do not get the usual canned answers.

Also by decompiling it if they could then it is also a greater legal breach as they made an active attempt to hack it so that fact alone is worth doing it. You can actually download both trial versions, encode something and see if you can find somewhere that can crack a file. If you can't they probably can't.

At the end of the day it is about putting an intelligence/time barrier there more than anything.

I'll respond if I get something back that is interesting.

I remember a bit of code I went over here on the forums - somebody'd cracked a member's site with a phpBB exploit and one of the guys here came across a php file the attacker had left on his server. It used base64, str_rot13, and eval to obfuscate the code. The attacker basically took all his code, base64_encoded it, put it inside base64_decode, then did that over and over again with str_rot13 thrown in occasionally at random intervals to stop automated decoding of it. That may work if all you need is a simple-ish solution.

Just break down and use Zend Encoder or Ioncube and install the extension on their server. Both encoders essentially turn your PHP code into byte-code so that when someone opens the application all they see is a garbled mess, except for the top few lines which states that they need the Zend Encoder to run it.

Now, this brings up the question of legality. Who owns the code? Is it the contractor or the supplier? If you didn't write a contract out, what does your state, country, county, province say is correct? I bring this up because if you encode the files (or remove them from the server) and they retaliate with a legal battle, are you in the clear or is it their code? And when does that transfer of ownership take place? The second it's on their server or after payment?

An idea to help you stay away from this type of situation is to employ a new model for doing business. You develop the code, and give them access to a private area of your server. They can go in, see how it's progressing, add comments and make changes as needed, but they never see the code. Then when it's time to deploy, you ask them to pay you. If they don't pay you, you remove their access to the "demo" so they can't use it anymore (or just take it down). Also, in your written contracts explicitly define who gets what when. For example if I contracted with you to have a time management app written, I would pay you 1/2 up front, 1/2 at the end, and once I paid you, I would get all open-source code and rights to that code would transfer to me. You can set it up however you want. But just remember to get it in writing with a few signatures

Personally, in your situation, I'd remove the entire site until they paid. Otherwise, later on down the road they'll come back and say hey, you did X for us, now do Y for $Z. Then when it comes time to pay, they'll remember they stiffed you before, they can do it again. If they don't want to pay, they don't want the product. It's essentially stealing (although the question of who owns what when still comes up).

Well, you could do something like http://sls.web.psi.ch/goto.php/duo/obfuscate.php to obfuscate your code, but what you want is to make it licensed, so they cannot move your code to another website and reuse it.

When I create a very complicated website, I create several license keys and create various checks throughout the code in critical function areas. If the code determines it isn't licensed, it disables itself, oftentimes in ways that makes it look like it's simply broke. I also have a "delicensing" login built into my high dollar sites, so if the user closes off all my permissions, all I need is the login box to disable the site.

It's a bit drastic, but when it's a matter of getting paid or not, I want to have my ace in the hole.

Normally, if I take on a big project, I break the contract into "deliverables". Each deliverable gets me paid so much money. Once I get my check, I work on the next deliverable. That way, the client can't stiff me completely.

I agree with bpat1434: consider if the law is on your side.

If it is, do not bother with any kind of encryption/obfuscation and just remove it from the client's website until payment. If this is no longer possible, you may even want to threaten legal recourse.

If it is not on your side, just bite the bullet, accept the payment, add the work to your portfolio and/or resume and move on. Next time come up with a better contract.