Can Zend encoded files truly be decoded?

Reason i ask this is that i have purchased a zend encoder and have seen on the net that some people can decode zend. Ive tried these sites out and well they dont work. Thing is, if someone does sit down with some time is it actually possible to decode zend?

any feedback would be great.

Thanks in advance!

I've also heard that its possible to decode Zend encoded files, i would recommend Ioncube, i've heard its never been decoded. :D

Anything can be decoded. However if the encoder compiles the source into bytecode then although it is possible to decompile it, they can't get the "true" original source back completely because the compilation process removes whitespace and comments.

My understanding is that Zend encoder does not encode scripts but rather it compiles them into code that can be executed by Zend optimizer. In this compilation many things are lost. It is not possible to simply decode such script. I think it is possible to trace it in some way (like the linux binaries can be traced with trace utility) which would show what is it doing and you might be able to recreate some of that. You would still not be able to access class or function definitions though which makes "decoding" pointless.

There are services (or service since I've only and confirmed one) that can decode any encoded file for a small price. Decompiling a compiled PHP file is aparrantly possible, but you don't get the formatting or comments since they're removed. It is the encoding bit which is important as that adds extra security to help reduce the usefulness of the output from a decompilation task. For example the new Zend Encoder has function obfuscation and ionCube are releasing a new version soon with extra security (they haven't revealed what yet).

Yes it is possible to decode a zend encoded phpscript, some parts remain encrypted but for the most part the code is readable.

Do not ask me how to decrypt a file, because you will not get a response.

Only a handfull of people know how to decode a zend encoded file, I am sure there are people out there who can figure it out who havn't yet.

googled it and found this:
<< URL removed >>

I haven't tried it yet.

Bottom line is: If someone REALLY REALLY wants your code, they will get it - encrypted or not. It's just a fact software developers have to deal with. Zend is the most secure IMHO since it does not use PHP to decode and run your files like IonCube, but instead compiles it. Just encode it and don't spend your time worrying about the one or two nerds out there that will try to decompile your code.

Zend is the most secure IMHO since it does not use PHP to decode and run your files like IonCube, but instead compiles it.

They both work by compiling the code and both use a zend extension module to do the execution. It is not the compilation that is the issue, is the security added before compiling. And my knowledge is that ionCube is more secure.

But whatever, it is down to personal preference. Both have more or less the same precentage of installation on servers and both are secure enough for most people. Security is always improving. But ways to crack the security are too.

Hey thanks guys for all your comments regarding the issue.
Ive been checking out zend forums and there have been tons of posts regarding the issue on zend being decoded, and everytime someone posts something about it the forum admins delete if from the forum. Weve been waiting a comment from the zend team but still no response.

I guess in the end just like "Czaries" said "If someone REALLY REALLY wants your code, they will get it - encrypted or not" which i feel is true and is something i shouldnt worry myself about.

thx again for the response guys

The truth is, these decryption websites work .. I've paid at least one to attempt to decode my test file, and the output was almost identical to my original.

<< URL removed >>

I sent an encoded test file to them. Their response was a file identical to the original without the // comments. Everything else was in tact.

For years, Zend has told its users it compiled files byte-by-byte before encoding, therefore resulting in a non-reversible file. Apparently that wasn't true ..

googled it and found this:
<< URL Removed >>

I haven't tried it yet.
I have tried it,it indeed can decode zended script,And it can also decode the script encoded by icube and sourcegaden.

At the beginning,i don't belive it,but it did!

It is important to note that since these decoders have been available, ionCube have released a new version with more advanced encoding and obfuscation functionality which (to my knowledge) has not yet been cracked. Zend are also introducing similar functionality into their new release, currently in beta. However it is always a cat and mouse game where the companies develop new protection and given time it is cracked, prompting further updates.

For years, Zend has told its users it compiled files byte-by-byte before encoding, therefore resulting in a non-reversible file. Apparently that wasn't true

It may have been half true.

Certainly it would have been foolish for Zend to claim that their protection could never be compromised, if they did make such claims, because there is no such thing as total protection. We always make this clear when asked, and a solution can still be effective for practical purposes. It is reasonable and honest to say that it woud be very difficult to do, and indeed, it seems improbable that the hackers have reversed the encoded files themselves as there's simply no need. There is certainly nothing to suggest that this was ever done for ionCube files, and more than likely Zend encoded files were not reversed either.

Until maybe the middle of last year when << URL Removed >> and << URL removed >> emerged, there were also no decompilers for PHP, and so no tool for having a go at recreating what source code could have been from bytecodes. Coupled with opcodes being hard to obtain and no compromises in 3 years or so, the solutions could reasonably be considered to have been proven as highly effective. However, given a decompiler, opcodes being hard to obtain is no longer enough.

The ionCube Loader, ZO for Zend, ixed for SG, all restore encoded files to some form of bytecode at runtime. Although very difficult to do, it is likely that hackers have focussed on actually modifying the behaviour of the loader components at the machine code level, effectively patching the .so files. This type of activity is used to work around product licensing systems, to enable or disable functionality of a program, and in this case, to force exposure of the bytecodes that have to exist at some point for the compiled PHP code to execute. Just like trying to disprove the four colour theorem (actually proved in 1976 by computer), contemplating schemes to prevent program patching is fun but doomed to failure. Patching binaries to change behaviour cannot be prevented, and the focus therefore has to be on making such an attack firstly as difficult as possible to do in any productive way, but working on the assumption that it will be done at some point, on making obtaining opcodes not enough to recreate useful source.

This was our thinking when we started work several months ago on the latest ionCube solution, released a few weeks ago, and there are currently no known systems that can recreate what source may have been from the latest ionCube Encoder, and possibly not for Zend Gaspra either (curiously named after a Spa town in the Ukraine).

Preventing the malicious acts of those wishing not only to destroy the efforts of dedicated PHP developers, but who seek to make PHP a less desirable and viable language for serious application development is definitely a challenge, but one that will always be met to the fullest extent possible.

wait. are php developers the only one who is encoding their codes?

what about python, perl developers?

wait. are php developers the only one who is encoding their codes?

what about python, perl developers?

perlcc and cx_freeze convert Perl and Python respectively, into executable applications. It's not byte-code but still protects the code (I believe the CPanel team uses perlcc for their backend).