Apparently ioncube can be hacked but Zend is very hard to hack
There was a bogus post in a forum some time ago that claimed this, but it was incorrect, and ironically, we've been shown by some russian hackers to be more secure than Zend
The key to security for both Zend and ionCube is compiled code and closed source execution engines. We both use this approach, but at ionCube we go further by protecting both the Encoder and Loader from analysis by inspection of both the encoded files and Loader (Optimiser in Zends case) to discover techniques. In other words, with our system, using the Unix strings program on encoded files and programs will reveral nothing of interest (except copyright messages and warnings about reverse engineering , and inspecting datafiles will reveral no tell tale signatures about data encoding. With some other products, strings may reveal clues that could be exploited, and if you're familiar with some file formats of well known algorithms, you may find these signatures present in the data files from some vendors. During the design and testing phases in our own product development, we ensured that we carefully audited the behaviour of our products in order to understand and discover potential weaknesses, and effectively, tried to hack our own products! We see this as a vital step in the development process for any security product.
In conclusion, and despite possible weaknesses that arguably but demonstrably exist in the Zend system, the bottom line is still that both Zend and ionCube represent the state of the art in encoding technology, are the most secure ways to protect your PHP code, and significantly more secure than source based approaches.
Originally posted by Mr Unknown >The key to security for both Zend and ionCube is compiled code and
> closed source execution engines
Sounds too much like security through obscurity to me.
Not when it's understood what a compiled code system means.
PHP works by parsing and compiling scripts into machine code instructions that are then interpreted by a virtual machine. The parsing and compiling is time consuming, and incidentally it's this step that accelerators such as PHPA, mmcache, Zend etc. eliminate by caching in shared memory, and accounting for the significant speedups. Having a compiled code layer also lends itself to encoding tools as the compiled code format is relatively obscure, and in the absense of a decompiler, bears no obvious relationship to source code at all.
Crude source code encoding systems merely hide the source at encoding time, and at runtime, restore the source code and pass it to eval() for parsing, compiling etc. - all the usual steps that happen when regular source files are processed. This technique is of course inefficient as there can be significant overhead in the decoding, and every decoding step is overhead that is not counteracted elsewhere. It's also insecure because you can easily intercept the restored source when it's passed to eval().
Compiled code systems work by running the parsing and compiling stages before encoding even takes place. Typically the compiled code is then optimised for size and performance as the PHP compiler produces inefficient and wasteful code sequences, and it's this compiled code (which is "unreadable" binary data and not source) that is the input to the encoding engine. At runtime, the restored data is again the compiled code, and this is then executed using a closed source execution engine (in the case of ionCube and Zend). It's the fact that the restored data is still binary and not source that is one of the crucial things.
For ionCube certainly there is obscurity in the implementation of the software (try the Unix strings program on the encoder or Loader and you'll get an idea), but the encoding techniques, or more crucially the input and output to the encoder, are based on protecting a data stream that is already well protected. Coupled with keeping the restored code inside the loader components, preventing single stepping through the execution engine in PHP (as it's not called) provide a strong defence. In a sense using compiled code actually is protection through obscurity, but this is because machine code level instructions are a much more obscure form of representation when compared to that of source based systems, where your actual source code is restored; so this is a good thing.