Comment

you missed out on bcompiler - http://pecl.php.net/bcompiler seems to work quite well ;)

  Posted by: Alan Knowles Mar 1st, 2005 @ 12:05 AM MST

Comment

A code encrypting extension should feed decrypted source to PHP interpreter.

PHP is open source, so in theory we may add few lines somewhere (i.e. zend_compile_string() ?) to store the text into a file, compile new binary and get the source without any problem.

  Posted by: su1d Mar 1st, 2005 @ 3:24 AM MST

Comment

Don't forget http://www.coggeshall.org/oss/blenc/ BLENC made by John Coggeshall. It's IMHO the simplest extension for code encryption and really doesn't do anything else, which is a good thing.

b4n

  Posted by: Nico Edtinger Mar 1st, 2005 @ 4:47 AM MST

Comment

I've always wondered how to do closed source PHP. I guess I should check these links out a little more.

  Posted by: charmedlover from lowter.com Mar 1st, 2005 @ 5:06 AM MST

Comment

Thanks for the link to bcompiler, Alan. This one works as a PHP extension, and fits into the same category as Zend Encoder, PHP Encoder and the encoder in MMCache. Looks like the extension does the compiling as well as the interpreting.

Nico, I had a look at BLENC, and it looks like it uses source code encryption, which means it is relatively easy (as su1d's point, above, illustrates) to decrypt the source code.

  Posted by: mmj from sitepoint.com Mar 1st, 2005 @ 5:52 AM MST

Comment

Turck MMCache hasn't been updated for a long time since 2003-11-04, now eAccelerator (based on mmcache) is active.

  Posted by: Data Mar 1st, 2005 @ 6:42 AM MST

Comment

While PHP is indeed an open source language, it's not to say that the work put in by web developers who decide to use it becomes, morally or otherwise - open source.

I've seen articles and read some comments about how "encrypting PHP is a whole hypocritical thing" but I think that's takin' it too far.

Web developers do put in years to perfect the way they code, they do the work and do it well. Then some cheaper, quick and dirty wannabe - like I once was, and most probably still am ;) - comes in and says "hey! this is easy, I'll just copy and paste parts of his code here and there... PAY DAY" *tap* *tap* *tapping on the keyboard to the tune of CTRL C, CTRL V*

Now the web developer has lost his/her client to some guy who's charging to copy and paste his/her code!

I think the scenario is more like "Use open-source technology to provide a specialised service - which you work hard at and get paid for". Rather than - use open source, make open source".

Bottomline - it's not a hobby, it's a job.

The encryption is more like an insurance that you don't get ripped off.

Regards,

'cholic

  Posted by: melancholic Mar 1st, 2005 @ 6:55 AM MST

Comment

Might as well point out that MMCache is very old and seems to have major problems with PHP 4.3.10. I have just had a beta tester of my new (PHP) product report problems because his host was using MMCache with PHP 4.3.10, when it was actually last tested with 4.3.4 (Nov 2003). If you're interested, here is a description of the problem on the MMCache forums: http://sourceforge.net/forum/forum.php?thread_id=1197147&forum_id=236228

  Posted by: Olate from olate.co.uk Mar 1st, 2005 @ 7:39 AM MST

Comment

As Olate mentioned, work on turck mmcache stopped some time ago. The latest incarnation is a spinoff project called eAccelerator http://eaccelerator.net/HomeUk.

  Posted by: cholmon Mar 1st, 2005 @ 8:18 AM MST

Comment

A good post, and we appreciate the mention. A minor correction though, for ionCube encoded files you need the Loader (which is free of course), not the Accelerator.

We'd also like to comment on availability of PHP engine extensions, i.e. the ones loaded with zend_extension/zend_extension_ts as opposed to module extensions, as these actually aren't that common in installations, and certainly not as popular as some will suggest. From phpinfo pages of end user installations, we rarely see either ZO installed or our Loader for that matter, and it's been suggested to us that as few as 1 in 10 hosts may install ZO, and we assume the Loader similarly. This is no indication though that either ZO or the Loader don't work in their role of executing encoded files. Hosts often prefer to have standard installations, and most hosts will be receptive if being asked to install support for encoded files on behalf of their customers, and particularly if it's from one of the major providers.

Not having to ask the host to add support is even better though, and with ionCube and also some other systems, there is an alternative to a php.ini install that allows the Loader component to be installed from user space on demand by the scripts themselves. This requires dl() and cannot work on all systems, but for many servers where php.ini access is an issue, it's often possible. This significantly increases the probability that encoded scripts will work "out of the box", making life easier for the end user, and reducing the potential support burden on the script provider.

Another issue to be aware of with protection solutions is file format. ionCube started out by offering a binary file format; it was after all the obvious choice, looks the most "impressive" if someone examines a file, and performs very well at runtime. However, a major downside that we didn't forsee is that file corruption when end users install files between Windows and Unix systems is a real problem. Unfortunately this is the most common install scenario, and happens when so-called CR/LF (line break format) conversion is applied by some software components, including FTP and WinZIP - the two components tyically used by an end user when installing files. This can be because a client, e.g. DreamWeaver, only support ASCII ftp transfer and not binary, or because programs attempt to be clever and autodetect whether a file is ASCII or binary, and get it wrong. With good instructions and patience, an end user can deal with this, but a solution was required in the form of an ASCII file format. An ASCII encoded file may not look as impressive, and unlike a binary file it won't mess with your xterm settings if you accidentally "cat" the file, but would be no less secure than binary format and perform nearly as well (ionCube ASCII files actually wrap the underlying binary format and so is an extra layer of encoding). Unless installation of files is taken away from the end user, e.g. by you providing a human install service or using an installer, support for ASCII format files is very much a feature to look for in a solution.

This last point in particular is often not thought of by people starting out, and perhaps without experience yet of end users installing binary files, so I hope this adds something useful.

ionCube

  Posted by: ionCube Mar 1st, 2005 @ 9:15 AM MST

Comment

Note that small businesses can get Zend Studio + Zend Encoder for only $450 through their small business package: http://www.zend.com/store/products/zend-smallbiz.php

  Posted by: DLyon Mar 1st, 2005 @ 10:59 AM MST

Comment

Has anyone used the zend studion package. I also saw the small business package and was wondering if it is worth the price

  Posted by: hdsol Mar 1st, 2005 @ 11:44 AM MST

Comment

Then some cheaper, quick and dirty wannabe - [...]PAY DAY" *tap* *tap* *tapping on the keyboard to the tune of CTRL C, CTRL V*

Come on guys! This is a joke. If you copy and paste code that is far beyond your abilities you'll simply end up messing it up. And you will steal no money to anyone. We all know it. Plus I doubt there is so much original code around that deserve to be encrypted. Finally, I think we all learnt mainly from reading someonelse's code. More encrypted apps will only mean less popularity for PHP and less chances for all of us to learn. As far as I know, none of the PHP gurus give a damn about encrypting her/his work. This thing alone should make people reflect.

  Posted by: Anonymous Mar 1st, 2005 @ 12:08 PM MST

Comment

Wow, the Zend Small Business package has gone up heaps (nearly double). I purchased a copy of it a few years back and it worked perfectly. Problem being that because I wasn't willing to pay for ongoing support, I dont get any upgrades for it. So while I can encrypt PHP4 scripts really well, not so for PHP5.

So yes, its worth the price, you just have to bear in mind that there is the ongoing cost drawback if you want it. Then again, most commericial software has this problem.

I'm all for developers and software houses protecting their code and intelectual property through code encryption. Its not going against the concept of open source, its called business and having the ability to compete in a very competive field.

  Posted by: mrsmiley from realityedge.com.au Mar 1st, 2005 @ 2:51 PM MST

Comment

Come on guys! This is a joke. If you copy and paste code that is far beyond your abilities you'll simply end up messing it up. And you will steal no money to anyone. We all know it. Plus I doubt there is so much original code around that deserve to be encrypted. Finally, I think we all learnt mainly from reading someonelse's code. More encrypted apps will only mean less popularity for PHP and less chances for all of us to learn. As far as I know, none of the PHP gurus give a damn about encrypting her/his work. This thing alone should make people reflect.

If you had spent several years working on an application for a specific industry and had built up a business, that paid you mortgage, around that application. Would you take the risk that one of your clients gives another developer access to your code?

Sure PHP gurus share code, develop open source projects and frameworks. That doesn’t mean that they share the commercial projects that hey work on.

  Posted by: petersj from uxmal.co.uk Mar 1st, 2005 @ 4:46 PM MST

Comment

If you had spent several years working on an application for a specific industry and had built up a business, that paid you mortgage, around that application. Would you take the risk that one of your clients gives another developer access to your code?

Sure PHP gurus share code, develop open source projects and frameworks. That doesn’t mean that they share the commercial projects that hey work on.

My sentiments exactly.

Come on guys! This is a joke. If you copy and paste code that is far beyond your abilities you'll simply end up messing it up. And you will steal no money to anyone. We all know it. Plus I doubt there is so much original code around that deserve to be encrypted. Finally, I think we all learnt mainly from reading someonelse's code. More encrypted apps will only mean less popularity for PHP and less chances for all of us to learn. As far as I know, none of the PHP gurus give a damn about encrypting her/his work. This thing alone should make people reflect.

I think you've taken my attempt at painting an exaggerated example a little too literally and somewhat out of context.

Come on guys! This is a joke. "No, I was not joking, I was being serious" ;P - ok now that we've both had our turns to warp each others words out of context, allow me to retort -

No, you cannot make code work simply by copying and pasting. That's not what I was suggesting. I was referring more to someone hacking at a web developer's (or any developer's for that matter) hard work.

Anyone who has basic knowledge of the syntax can change code. Of course, it'll take 'em a while, but not as long as it took the developer to write up libraries and helper functions from scratch.

"What's wrong with that?" I can hear you sayin' "It's open source and that's how it's supposed to be!"

I'm sayin' it's a commercial project using open source technology. The technology IS in fact open source and the developer HAS downloaded some - and learned examples from - open source code, BUT the service, the time spent coding, the code design etc IS NOT open source.

It's not about encrypting patent "original code", it's about protecting your work that you put into the project - If a developer takes the client from you, you don't want him or her taking bits of your code - they can start from scratch! (VVVV) < they're supposed to be claws BTW

IF a web developer/team releases code as an open source project, then that's a different story, people can hack away at it, learn all they can from it, offer it as a snap in application and slap on a "website configuration/setup/initialisation/buzzword fee" for setting it up for them - whatever.

People can take the ideas provided in the opensource application and develop them further - then maybe down the track they themselves will start an opensource project of their own.

'gards,

melan'

  Posted by: melancholic Mar 1st, 2005 @ 7:12 PM MST

Comment

1) eAccelerator / Turck mmcache

While there is an encoder available, it should not be confused with an encrypter. The encoder allows you to save actual byte-code instead of source code so that compilation is not required. It should still be possible to reverse the byte-code back to source code. An encrypter (which is not available with this product) would make reverse-engineering less feasible.

2) Is this technology needed? I don't think so, but it would be nice if licenses would start in the million dollar range to prevent people from using them widely. The whole cut-and-paste situation is to laugh. BTW, if you develop for an in-house project that will never be released out-of-house, you aren't even bound by most licensing terms, as-far-as-I-know. It is only when you want to sell outside of your organisation (or sell custom code you developed for someone else to a 3rd party, thereby keeping the rights yourself) that they become an issue. From what I have seen, very few products fall into that realm and of them, many require an "expert" to maintain them. If your job isn't secure without encryption it is probably because you don't have any real services to offer anymore but instead intend to live off the laurels of your (or others) past efforts.

  Posted by: jayboots Mar 1st, 2005 @ 8:06 PM MST

Comment

BTW, if you develop for an in-house project that will never be released out-of-house, you aren't even bound by most licensing terms, as-far-as-I-know. I wasn't talking about "inhouse projects never to be released out of house projects" or developing of course you wouldn't want to encrypt it, it's common sense.

I'm talking about a web developer. by him/herself. not on a contract. not acting on anyone elses behalf but his/her own. Making custom online applications like a Content Management System or an online Shopping Cart, tailoring it to the need of a client. Then using encryption to ensure that no one else can modify the code. IF someone undercuts them and needs to change the way the code works, then they can write their own code.

Businesses out there are in fact cash conscious and there's nothing you can do to secure that if you're undercut in quotes.

I strongly disagree with your last statement saying: If your job isn't secure without encryption it is probably because you don't have any real services to offer anymore but instead intend to live off the laurels of your (or others) past efforts. For most, it's far from that.

I found it unnecessarily negative and ignorant.

  Posted by: melancholic Mar 1st, 2005 @ 8:53 PM MST

Comment

Source Guardian - Priced around $250 USD has been around for a while with a proven track record http://www.sourceguardian.com/

  Posted by: JJM Mar 1st, 2005 @ 10:27 PM MST

Comment

While there is an encoder available, it should not be confused with an encrypter. The encoder allows you to save actual byte-code instead of source code so that compilation is not required. It should still be possible to reverse the byte-code back to source code. An encrypter (which is not available with this product) would make reverse-engineering less feasible.

Actually, this is the other way around. Converting from bytecode form back to source code is not possible, as the compilation process involves many optimizations that essentially discard the original structure and form of the source code. The bytecode only stores its low-level behaviour.

However, when using encryption, it is possible to go back to source by decrypting it, which is relatively easy to do. The encryption process is two-way: it is possible to faithfully decrypt that which has been encrypted using the decryptor provided with the application.

  Posted by: mmj from sitepoint.com Mar 2nd, 2005 @ 12:29 AM MST

Comment

[q]It's not about encrypting patent "original code", ...[/q]

When I think my code is worth the value, I host the application on my own server so that the customer can't steal anything. If he insists on having the source files, I charge him much more. So I don't really understand what this topic is about.

[q]Sure PHP gurus share code, develop open source projects and frameworks. That doesn’t mean that they share the commercial projects that hey work on[/q]

In fact they are PHP gurus not angels.

[q]then maybe down the track they themselves will start an opensource project of their own.[/q]

oh well, I already do help in a couple of open source projects..

Anyway the right attitude is PHP Group's one, encrypt whatever you like.

  Posted by: Anonymous Mar 2nd, 2005 @ 3:34 AM MST

Comment

The main use I can see for producing binary code is accountability. I've often delivered projects which have been hacked at by in-house staff who think they know PHP. I get a call saying the system is producing error messages, a quick diff on their source code with my original shows up the problem.

I'd like to be able to deliver a solution which couldn't be changed by the client. We need to start thinking like this with web technologies, could you imagine if there was a dreamweaver type app for java or C++, you'd have Johnny from accounting making a few ammends to your payroll system! It wouldn't be acceptable, it shouldn't be in the web industry either.

  Posted by: andrewtayloruk Mar 2nd, 2005 @ 4:04 AM MST

Comment

Source Guardian has been cracked... so how can you call that a proven track record?

  Posted by: Eric.Coleman Mar 2nd, 2005 @ 7:53 AM MST

Comment

@melancholic: dang...sorry guy...my comments were meant only in general and were certainly not directed at your situation or at you. I really don't want to try to tell anyone how they should conduct their affairs and I do think there could be situations that warrant closed-sources (not that I can really think of any). I'll ignore the fact that you imply that I am negative and ignorant because I don't think either of us cares for a flame here.

I respond because the way I read it, your suggestion seems to be that the only recourse of an independant contractor (like myself) is to essentially hold the client at ransom. I wonder what you think of a similar situation: suppose a building contracter is replaced on an on-going construction project by a homeowner. Should the next contracter have to restart the entire project and rebuild the home from scratch? There has to be a point where the client has ownership of the "thing" you are building for them -- after all, they are paying for it. Moreso, open-software makes you accountable to your client instead of the other-way-around.

If you ask me CMS's are fairly much commodity now and some of the best ones are open sourced. This is the type of thing that prompts my earlier statement: if this is the type of work you are meaning to protect, then you have nothing to protect anyhow. I really think that.

It is no revelation that many small developers increasingly rely on OSS to cover at least some of their projects. Much of that software is GPL'd or LGPL'd so the project will either endup being GPL'd itself (meaning all sources would have to be released) but at least the OSS portions will need to have their sources made available. One fear I have is that many custom, closed projects will inappropriately close sources and violate licences simply because they can. That really ticks me off.

@mmj: actually, while encryption is symetric, assuming a suitable encyption method it will only be decryptable by someone with the proper keys. On the other hand, while you are right that you can't reverse byte-code to original sources, little stops you from decompiling it into a source form. The point I was getting at was that encoding is far less "safe" or obscure than encryption and eAccelerator only does the former.

  Posted by: jayboots Mar 2nd, 2005 @ 9:44 AM MST

Comment

actually, while encryption is symetric, assuming a suitable encyption method it will only be decryptable by someone with the proper keys. When you distribute 'encrypted' source code, it is also necessary to distribute, along with it, the key that decrypts it. The end user can easily decrypt the source (please read su1d's comment above), and will end up with a perfect reproduction of the source code. That source code encryption provides more protection for your source code than encoding in binary form is a myth perpetrated by makers of source code encryption software. Much source code encryption software also obfuscates the code, and the obfuscation provides more protection than the encryption.

  Posted by: mmj from sitepoint.com Mar 2nd, 2005 @ 4:23 PM MST

Comment

No probs JayBoots ;)

I understood that you were not referring to me alone and that you were making a general statement, I didn't take it personally at all. I wasn't calling you ignorant, or negative. I was saying what you said was ignorant and unnecessarily negative. - I agree that this indeed is not the forum to flame.

Besides, there's no need. I understand completely what you're saying, but I think you're distorting or misunderstood what I've said into a general "this is what you should do all the time" scenario in which case, yes you would be correct and I would be wrong - encryption should not be applied or taken up as common practice with everything.

I am not saying "encrypting your files is the way of the future and this is how you HAVE TO do it for every project". What I am saying is that it has it's place and that people who use encryption should not be scoffed at as opportunists or "holding clients in ransom".

If a developer was on contract, then of course he/she would leave the code for someone else to work on. It's common sense. That's what they were hired to do - for instance, going to elance and taking a job does not warrant that the developer provide the source code in it's encrypted form. Give the client the sourcecode. It's what they've paid for.

Content Management Systems come in many forms and I agree that they are indeed a commodity. Even Online Shopping carts are a common thing now - PHPNuke(although it's $10 to get the latest source) and osCommerce are a big hit!

But just because these are available, it does not mean that it's pointless to secure your sourcecode - time was still put into development. If the client chooses someone new to work on the site, then the new developers can apply their favourite opensource app onto the site if they like. I really think that.

It is no revelation that many small developers increasingly rely on OSS to cover at least some of their projects. Much of that software is GPL'd or LGPL'd so the project will either endup being GPL'd itself (meaning all sources would have to be released) but at least the OSS portions will need to have their sources made available. One fear I have is that many custom, closed projects will inappropriately close sources and violate licences simply because they can. That really ticks me off.

I understand your fears and it really is unfair. I guess we'd just have to hope that people will stick to the same goodwill that the licenses were made with and not violate the agreement.

  Posted by: melancholic Mar 2nd, 2005 @ 5:34 PM MST

Comment

hi!

Yes, I've used Zend Studio and I can tell you that it's my favourite IDE. Zend I would actually recommend everyone Zend Encoder and Optimizer as they are really doing a great job. There are several more things I will have to note in this post.

One of them is that it is actually a good idea to be able to encrypt some files in your project. For instance if you have developed a unique class or something simmilar. However I still belive that your code should stay opensource in most of the cases. The second thing is that PHP development really is a job like some people already mentioned here.. It's not some hobby as it ways a while ago. PHP Aces are making their living with it and so do I, even thou I'm not an ace yet.

So why do you guys even question the possibility of making some important parts of the code closed-source?

  Posted by: Alexei Koubarev Mar 5th, 2005 @ 11:18 AM MST