I would like to ask those of you who use one of these about which you think is the better option. I’ve finally broken in to freelance work, instead of just creating internal PHP for my company, and I want to protect my work. Originally I was looking to ‘compile’ my code and then I was told about Zend Guard and [URL=“http://www.ioncube.com/sa_encoder.php”]Ion Cube PHP Encoder.
What I want to do more than anything is to protect my code. Partially because I don’t want my hard work copying and being reused (for free or for a fee) but mainly because I don’t want people who think they know what they’re doing tampering and breaking things. I also want the client to need to get me back in to do any future work
Things like time-limited samples etc are things that I’d like to look in to in the future, as are license keys, but at this point I’m not needing those features. Having them ready for when I need it would be very handy though. The bespoke nature of my work means that I’m not terribly worried about the client installing the system on numerous machines at this point, hence why I’m not worried about license keys etc.
I hate to break it to you, but there is no protection scheme that works when the intended recipient of your product is also the entity from which you need to protect it. (See movie/videogame DRM for a great example of this)
You might slow them down, but someone smarter than you will crack it eventually. Just charge good money for your work and keep the work coming. There’s not a lot you can do about dishonest people.
Hmm, thanks, but that’s not the kind of answer I’m looking for. I’m not naive enough to think that you can protect something against everyone. My question is exactly as originally asked; which would you recommend. And I’m asking people who have experience of at least one of them please
system admin privilege is not a requirement (for the recipient of the encoded scripts), you can distribute the loader with your files
cons:
bulky bundle for different php versions (loader)
a few php functions (dl?) are required to load the loader if it is not installed system-wide. for security reasons, most shared hosting provider disable such functions.
Thanks for that Simon, that is very helpful, yet opens up more questions
I work primarily in web-apps for business, rather than web-sites, so usually there is someone on site who has full admin privileges to the server. In fact, it’s me in some cases, so that requirement is dealt with. The others I guess give something more to consider. Thanks
I sell my developed products to the masses and, therefore, I offer both. Both products have ways to limit their use (IP, time, etc.). However, since I offer both, I wrote my own licensing system that has a demo feature which allows a demo license to be used by code encoded with either product.
Both products are simple to use (IMO). If you have total control over the production environment (meaning you can configure PHP to use either), then I would recommend going with the cheaper of the two, IonCube.
Interestingly, on my two sites, the IonCube version is downloaded more often than the Zend version, even though I have the Zend version listed at the top.
Some notes from my experiences:
It took me just a few releases to figure out the best way to manage the encoding process. I create a directory for the release and copy the source into a subdirectory. I also create a zend and an ioncube directory at this same level. I encode into those two directories (using a subdirectory). If you know the platform you are going to distribute IonCube into, then you can drastically reduce the size by only distributing the one library file that supports your version of PHP/environment.
jondolar, thank you, that is exactly the kind of information I’m looking for. I was already siding with Ion Cube I must admit but maybe I should buy that now and look at Zend for a later project where required? Thanks a lot
Good thread, but just to pick simon up on these points:
ionCube has been on the market since 2002, was the first PHP Encoder for the mass market, and is very well and widely known. A quick compare of the reach graph at alexa will show a similar reach (with the ionCube website recently having higher reach than Zend, but it swings either way as you’d expect), and the awareness of both solutions is probably about the same.
This is doubtful but do create a ticket on our site if you ever had any problems and hadn’t done so already. In practice there could be occasional problems with any of the complex compiled code solutions, and Zend are not immune to their fair share as, for example, thread 19124 at the Zend forums shows where users were complaining that 64 bit support did not work for Zend Optimiser and that they would have to use ionCube instead. The Zend and ionCube encoding solutions are both highly complex, and the PHP group tinker with PHP internals constantly such that encoding solutions may occasionally need revising. In general though and on average you shouldn’t find any difference between either in terms of reliability, nor any problem with either solution.
Both ionCube and Zend offer the same or similar back compatibility. Up until recently ionCube supported PHP 4 back to 4.0.6, which was the first feasible release of PHP 4, and PHP 5 back to 5.0.3 which was the first feasible version of PHP 5. It’s also possible to run ionCube encoded files on PHP 5.0 that unencoded would only run on PHP 5.1 or higher. Some ionCube Loaders are no longer built for the very early versions of PHP 4, but could be if required. You’ll also find that by special request and arrangement, ionCube Loaders can generally be built for platforms that are not officially supported, such as ARM processors and various embedded systems, and support for Mac 32 and 64 bit was provided long before Zend. ionCube Loaders for PHP 5.2 were also ready several weeks before Zend Optimiser for PHP 5.2.
While there are differences, both solutions should do the job.
