Zend can not only be theohetically cracked, there have been sites for some months that have offered Zend decoding services, and there are several threads in the Zend forums from people that have tested the services and seen it to be true. e.g.

http://www.zend.com/phorum//read.php?num=8&id=538&thread=401

and surrounding threads.

What Stefan fails to mention is that most users of encoded files rarely just encode the files, as with PHP being inherently insecure from being opensource, tinkering inside PHP is possible. Instead, users generally protect files with license files, locking to MAC address and other machine parameters, and that when files are protected from even being deocded unless run on the correct target hardware, the security of Zend and ionCube systems comes into their own. There is a significant and vital difference between the real world usage that users perform with ionCube and Zend and playing with test files on a PHP system that is open to modification.

That said, there is always a level of threat, and seeing the rise in attacks on Zend from the anti Zend lobby over the last few months, ionCube have developed and tested a new security technique to prevent opcode dumping and access in the way described above. With proof of concept tests completed, this will be available in the ionCube solution soon, and an added benefit to users of the ionCube solution. It is expected that the Zend solution may likely follow suit as well.

jc

Your comments really just assert what is widely known, which is that there is ultimately no security to anything. The hardware dongles that Steinberg use have been cracked with emulating device drivers, DRM gets cracked, FlexLM, our neighbours upstairs window two days ago, and your observations do not describe any weakness in encoding solutions, but are actually just a comment on PHP. Now, if only PHP were closed source...

So, is it really all doom and gloom for code protection then, are all bets off, and should we just give up? Well, of course note. Things are rarely black and white, and "security" is a rather all encompassing and actually vague term. For one thing, in order to determine that something is insecure, it's important to establish what an end user considers to be secure from their perspective, and not just ones own. In fact, ask any true security expert whether something is secure and if they're honest you'll get the answer that no it's not, so it's not necessarily helpfui. With PHP and its runtime environment being opensource and easy to tinker with, the notion of security at all is somewhat of a difficult concept to make stick. The crucial point is that there are different degrees and types of protection, and this is where headway is made. Now, if we looked inside PHP and saw the original source code to encoded scripts then I have to agree, but claiming that there is no security at all in these encoding solutions is of course incorrect and misleading. People use these tools for a variety of reasons, and for most people, they actually provide much more than an adequate solution, and effectively are totally secure for the purpose that they require.

I'll expand, but as an aside for a moment, an interesting parallel not related to computing is with the handcuffs that Scotland Yard used in the UK for many years to secure prisoners. Whilst totally effective at their purpose, they had an interesting design flaw in that if you hit your wrists hard down on a table they would spring open and you would be free! Now whilst this, of course, is somewhat of a weakness, the handcuffs were none the less totally effective at giving the security that Scotland Yard required, and so the tools were pefect at the job. It is often similar in the software world that whilst any protection can be targetted for attempts to compromise, the realities of the real world and real world situations are that the existance of this possiiblity is none the less of no consequence practically speaking, and that the protection offered is totally effective.

Now back to PHP, if you consider the PHP Encoding market, solutions broadly fall into two types and two extremes; source code encoding, and compiled code. The source code solutions rely on restoring source, which is executed by eval, and is trivial to expose by intercepting the restored code. These solutions truly are insecure, can result in severe performance degredation, don't offer 100% code compatibility due the differences in how eval processes some idioms, but none the less do have a place in the market and are suitable for some people.

Compiled code solutions, such as Zend, IonCube, SourceGuardian and PHPShield (actually the same product as SG just rebranded), compile code to bytecodes and eliminate the source, and are the other extreme. Ultimately the compiled code is of course available in memory as it has to be, and of course tools may be able to access it, (this is actually hardly a new revelation), but the point is that there is a gulf between the compiled code and original source, and this is part of the value in this type of solution. That and other benefits such as increased performance. In fact, all manner of information can be obtained with any encoding solution by examining what happens inside PHP at runtime, but is this insight useful? Practically speaking, no, not at all. As far as accessing compiled code goes, it may be novel for those that understand assembler code and that are interested to learn about PHP internals, but it's not the original source code, (afterall the bytecodes are a different language), and it's the source that most people are looking to protect. Even though Zend files have been turned back to source as indicated above, these sites are being shutdown, and even when up, when it comes down to it those services are not in reality a substantial threat at all for many reasons.

A further thing to note that some of these tools offer mechanisms for the developer to take advantage of that going beyond complied code. In tools such as ionCube, mechanisms exist for storing sensitive data inside the encoded files and away from the opcodes. This information isn't revealed at all by running an opcode dumper, and even triggering a core dump and examining a memory image wouldn't reveal the information either in its raw form, and so it's not necessary to try and hide it from the opcodes as it's simply not there in the opcodes in the first place. Like many protection systems, they need to be utilised fully to get maximum effect and benefit.

As a final thought, we shouldn't forget that Zend Encoder and ionCube, plus SG more recently, have been around for 3 to 4 years now, and it's only because of these systems that huge numbers of individuals, companies and large corporations have been able to produce products for the benefit of the PHP market and PHP itself. The viability of people even contemplating producing serious systems for PHP is substantially due to these tools, and they have been totally effective at what they set out to do. Had they not been, then in 3 years we'd have heard about it a long time ago. Without them, the development of PHP in terms of available products for putting together major systems would most likely have been substantially less swift, and projects such as hardened PHP might not even exist because no one would really care. Whilst from time to time people jump up and claim that XYZ is totally insecure (this blog post certainly isn't the first), there is often with a not always particularly well hidden agenda, and the reality from the end users perspective is different.

Without doubt, Zend, SG, ionCube, are a major contributing factor to the success of PHP, and of substantial benefit to thousands of users every day around the world.

Rather than trying to attack systems that offer real value for developers and that hardened PHP is not currently compatible with, it would surely be better to concentrate efforts on getting the hardened PHP patch adopted as standard. As soon as the patch is available in PHP, then value adding products such as Zend Encoder, IonCube and SG would become compatible very quickly (you'd be surprised just how quickly), and PHP will have taken a step further down the road of vital improvement.

Everyone involved in the business has the best interests of the PHP development community and PHP itself at heart, and taking positive steps instead of the negative one attempted here will ultimately get the respect, attention and action that they deserve.