Page 1 of 1
free alternatives to ioncube
Posted: Sun Mar 12, 2006 6:34 am
by Pyrite
Are there any FREE alternatives to ioncube?
Posted: Sun Mar 12, 2006 8:44 am
by feyd
APC has been mentioned as that specific role.
Posted: Sun Mar 12, 2006 9:08 am
by Pyrite
Hmm, I should have stated, a free alternative to ioncube's php encoder.
I looked at PHTML Encoder, but with the free version, anyone with PHTML Encoder and decode your files.
Posted: Sun Mar 12, 2006 9:29 am
by feyd
Last I saw, all of the encoders have been decoded.
Posted: Sun Mar 12, 2006 9:33 am
by Pyrite
meaning, none of them are secure?
Posted: Sun Mar 12, 2006 9:34 am
by John Cartwright
No encoder is truly secure anyways.. there is potential for any encoder to be broken
Posted: Thu Mar 16, 2006 6:50 pm
by AlecH
Yes however, I would have to say that Zend Encoder is probably so the most secure and reliable mostly because not many people have access to it because its just so expensive. Thats where it also faults when relating to this topic. But mainly, your right jcart.
Posted: Fri Mar 17, 2006 10:32 am
by timvw
Afaik, Zend encoder isn't any safer than others... They know it's broken but continue to sell the product..
Posted: Wed May 24, 2006 5:05 am
by ioncube
timvw wrote:Afaik, Zend encoder isn't any safer than others... They know it's broken but continue to sell the product..
Just to bring this thread up to date, encoding systems such as ionCube and Zend weren't broken per se, but people such as the Chinese "blue wind" produced a decompiler that given an opcode stream could have a go at recreating what source code could have been. They then used tricks to obtain opcodes at runtime for feeding into the decompiler. Whilst no system can ever give 100% protection as other industries have learned from the efforts of people like Jon "so sue me" Johansen, we combatted the current threat very effectively with the release of Encoder 6.5 back in January.
ionCube PHP Encoder 6.5 added features that keep the actual compiled code obfuscated even at runtime and so making it significantly harder to discover valid opcodes, as well as new user features for one-way user key based obfuscation of certain source elements, (function names and local variables). Additionally a new feature not found in other systems was added to support encryption of arbitrary files and not just PHP files, which is great for protecting template or XML files. In late April or early May, Zend responded by renaming their product and adding source element obfuscation simlar to ours, although not with a one way algorithm and without adding protection against opcode discovery.
We'd like to close source PHP, take the chance to improve it along the way and substantially improve security by doing this, but unfortunately the practical requirements of end users and the nature of target PHP systems restrict the extent to which security features can be added and there's no way for the general market that we could do this. So there's always a balancing act between security techniques and practicality, but we're committed to protecting as far as possible the IP of developers against those seeking to destroy PHP as a serious application language.