Forgot your password?
typodupeerror

Comment: Re:Zend Encoder (Score 2, Informative) 60

by MarkAtZend (#15731364) Attached to: Has Zend Source Encryption Been Rendered Useless?

My apologies, I should have hit preview first. Here is the formatted version:

Earlier this year we were made aware of sites such as the ones pointed out here that offered commercial services to decript the intellectual property of others. We must stress the illegality of such services, and we will fight such efforts in all ways available to us.

Let's analyze the problem. The vast majority of PHP code is deployed as a web application. In that case, users of the web application have no access to the PHP code - only to the output of these applications (the (X)HTML produced to create the dynamic webpages). The vulnerability discussed in this SlashDot thread therefore does not apply to that scenario.

But the strength of PHP is driving another use of the language. More and more software vendors are creating applications that will be distributed traditionally - by download or CD, and in such cases there is a clear necessity to hide the intellectual property that went into the creation of their application. That is what our Encoder products were designed to make possible.

As pointed out in this debate, any attempt to encode a language is countered by attempts to decode. There is no language that is exempt from this (Google for "[your language] decoder" if you are interested). In the case of PHP, encoders may well encrypt the language that makes up the IP in the application, but at runtime it has to be decrypted to the format that the PHP interpreter can process. Those who are smart enough to snoop into the interpreter can see the straight PHP code being executed. This is true for Zend, IonCube and all others who provide encoding solutions.

The metaphore of using keys to lock your house is applicable. It will not stop the most determined thief, even if it does keep out most of them. And as thiefs become more sophisticated, we want to make our locks more robust.

Zend Technologies has been pursuing an additional strategy of encoding. Today, even if the decoders manage to recreate the code encrypted by our newest product, Zend Guard 4, they will find little if anything that will be meaningful to them. The reason for that is the strong obfuscation that Zend introduced with Zend Guard 4 - it is the first product that obfuscates object oriented programs created with PHP 5.x.

The decoders may be at work to figure out how to reconstruct the original code from this obfuscated code, but they should know that we'll deliver even stronger obfuscation in the 4th quarter of this year. They will have to keep investing time and money to keep up with our development cycle, not to mention figuring out how to make a business out of this illegitimate activity.

====

When the news of the decoders broke earlier this year, we informed all our customers (and former customers) about the situation, what steps to take, and made Guard 4 available to them for free when it shipped in April. Thousands of them have upgraded and are ahead of the decoders today. Through their ongoing relationship with Zend they will stay ahead.

====

So TinkerTim has an option to release his PHP application securely - and if he was a Zend Encoder customer he would have known. If his intent is not that, but instead to promote the decoders, then our message to him is that we will make his life very difficult by continually advancing the encryption technology.

Mark de Visser
Zend Technologies

PS - because of a legal dispute with a European company we had to discontinue the trademark "Zend SafeGuard", and replaced that with "Zend Guard" (we combined the functionality of Zend Encoder and Zend SafeGuard Suite in this new release).

"Call immediately. Time is running out. We both need to do something monstrous before we die." -- Message from Ralph Steadman to Hunter Thompson

Working...