PHP Encoders offer little protection
PHP Encoders Protection where are you? is a blog entry on the PHP Security Blog where Stefan Esser writes:
From time to time people ask if it is possible to use the Hardening-Patch together with the IonCube Encoder or the ZendEncoder. I usually answer, that they should ask the IonCube support or the Zend support, to simply create compatible versions.
This will change in the future. I had a look at both encoders that are most probably the most famous ones and I am kinda shocked. The IonCube Encoder does not offer any protection against oparray_dumping or oparray disassembly. If you want to see this for yourself, then download derick and andrei's vld and apply the following patch: vle-request-hack.diff. After you have applied this, simply load the IonCube Loader as normal and activate vld as usual.
You will see the disassembly of the encoded PHP script in ZendEngine Opcodes and you will most probably not notice any obfuscation at all... (You can always compare the output to the output of the not encoded version)
The good news for all the users of ZendEncoder (or however it is called nowadays) is, that it is a little bit harder to get the disassembly of scripts that were encoded with ZendEncoder, because you will notice that the Opcodes are encrypted. But anyone skilled with runtime encryption layers will be able to decrypt those opcodes. When you have broken the opcode encryption they look like the output of ZendOptimizer. Which means there are some ZentOptimizer specific opcodes in it, that have something todo with cached functionnames...
I think this is quite bad news for Zend and the various other providers of PHP Encoders as they'll have their work set out for themselves to produce a more secure encoding mechanism whereby people cannot easily get to the unencrypted opcodes.
I've found the following comment on a chineese forum:
Hello,
We are aware of this problem, even before it reached China.
There is work being done now to develop the next generation of Zend Encoder that will have stronger encoding and will be harder to crack and decode.
You have to keep in mind that there is no encoding (or even encryption) mechanism that is 100% safe, especially something that needs to be decoded and parsed fast like a php script. Also, even though it is not uncrackable, Zend Encoder is the best solution in the market right now for encoding php code - and it provides a decent protection for most people.
Comments
It's been interesting to follow what various posters have written in forums following on from Mr. Essers curiously ill judged comments. Whilst oparray dumping is possible, albeit in this case only with a version of a tool that was patched for the purpose, the conclusion about total lack of security was simply silly and false.
Whilst there is no such thing as total security, and most particularly with PHP as most of what goes on inside PHP is observable due to it being opensource, encoded files are typically accessible only on certain servers due to restrictions (usually just one in fact), and dumped opcodes are not source code. Provided that the encoding tools are used to maximum effect wereby sensitive data is hidden away from the opcodes, the information given by a disassembler is really of little use whatsoever when you move beyond looking at opcodes for a hello world program. For practical purposes, the barriers to someone accessing opcodes and then relibably reconstructing what the source code might have been are formidable, and account for why it's not done.
It's worth noting too that for Encoder developers, there is a balance that has to be struck between aspects such as the security that's offered, the need for compatibility with other modules, flexibility and performance. We understand possibly better than anyone how to lock down PHP to a level that goes far beyond what anyone has attempted thus far in a non-custom product, and it's something that we discuss often internally, but this would be at the expense of producing encoded applications that could never be run on the average PHP installation. For 99% or more of the target market for encoding solutions, this would be a showstopper. So like other providers, we strike a balance, but always keep a close eye on the level of awareness that is around the "general public" for how PHP works internally.
When Zend were hit hard earlier this year, it was clear that whilst opcode dumping in the raw form that Esser describes was never a serious threat, it would still be necessary to increase security because of the increased potential threat from other types of analysis. Our first level solution to offer enhanced security is already incorporated into our latest technology, and innovatively prevents opcode dumping in the way described by Esser. A second phase will be incorporated into the next release. There's still the balance to be struck, but solutions from all of the top providers are likely to evolve and incorporate enhancements as the nature of the market continues to change.
ionCube.
Posted by: ionCube![[TypeKey Profile Page]](http://www.powertrip.co.za/blog/nav-commenters.gif)
|
October 27, 2005 3:08 AM
Unfortunately people are misled to believing that using encoders make their source code "secure". It would be great if it more difficult to obtain the opcode cache and convert it back to source code (minus the comments).
Personally I find it misleading creating hype about how secure the source code would/will be with using encrypters.
Posted by: Jacques![[TypeKey Profile Page]](http://www.powertrip.co.za/blog/nav-commenters.gif)
|
November 2, 2005 7:38 PM