Quote Originally Posted by bgardner333
Ah, but the zend encoder can be cracked as well (and as far as the whole
encoding thing, I realize that there is no way to be really secure using a PHP include, as the PHP include is just gzipped/base64'd 20+ times.

That is why I am writing a PHP extension module (dynamically loadable, of course) to address these issues. People can then customize their encryption methods.
Actually zend encoder cannot be cracked...sorta Since it is converted into bytecode, php doesn't need to interpret and compile it. PHP directly runs that code. You will never be able to reverse engineer the code to the way it was first written...ever... its simply not possible. It is possible to product some code that would work the same but it would be highly cryptic and unreadable. You wouldn't be able to feed it directly into php... you would have to be able to interpret php's high level constructs.

Your method can easily be reverse engineered to produce the original source code without any advanced programming knowlege. It can be done directly with a 1 line php statement. It may deter noob php programmers but isn't suitable for the professional world because:

1) Easily reverse engineered. No way to truly protect it using your method.
2) Increases runtime significantly. Probably over 100% in most cases. Zend optimizer actually speeds execution up over 7 times

It is a cool experiment in php but you should warn users that it can be bypassed and professional solutions should utilize zend encoder.

The php module could help but not if you use the same method as you are doing now. You would have to convert it to some type of proprietary binary format. Problem is, your project is open source... so that makes it easier to reverse engineer.

The only way to make it hard to reverse engineer is to bypass the php interpreter and feed it bytcode directly.

Cool experiment... just put a notice on the site that it can be reverse engineered and shouldn't be used in a professional environment