ionCube Logo
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


 
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder

Ioncube Encoder security

Author Message
Korben Dallas



Joined: 26 Feb 2006
Posts: 2

PostPosted: Sun Feb 26, 2006 3:50 am    Post subject: Ioncube Encoder security Reply with quote

Greetings..

I am curious, at the following website: [mod edit]

They are actively selling "services" for cracking Ioncube and other popular PHP encryption methods.

A friend of mine made me aware of them, after he had them (successfully) decode some ZEND encoded files for him. I was planning on purchasing both Ioncube and ZEND's encoders, but now I have to think again perhaps.

This is obviously troubling (I am not trolling), and I would like to know what Ioncube's position on this is, and what steps (if any) are being taken to prevent such services from flourishing and making your products irrevelant.
Back to top
View user's profile Send private message
Alasdair



Joined: 11 Jan 2005
Posts: 30

PostPosted: Sun Feb 26, 2006 12:42 pm    Post subject: Reply with quote

Welcome to post 16th January Wink

From my understanding of the situation, ionCube v6 and below was vulnerable but not to the extent Zend was. Zend encoded files seem to be completely reversible to source (with the exception of comments) whereas Iíve never seen or head of a full ionCube encoded file being returned to source.

While all this was happening over the past couple of months, ionCube were already hard at work on the next version of their software, v6.5, which added several new layers of protection including a new obfuscation function (which was released 16th January) and I donít believe anyone has managed to break the new measures yet. Zend are also working on a new version of their product, V4, but it still isnít out.

One thing to note is that ionCube have put out several new releases with innovative features and added protection while Zendís only releases recently have been to fix issues or add PHP5 compatibility. ionCube pro-actively work to stay Ďone step aheadí of the people looking to come up with methods to get at the source code, whereas Zend (in my opinion) seem to take a more laid back attitude and simply react as issues come up - Zend's protection product has remained pretty static over the past couple of years, which obviously makes it easier for people to break as it's not constantly evolving (whereas ionCube is).

No solution is 100% secure and there will always be groups and people who try and get past the protection offered by Zend/ionCube, the important thing to consider is how each company reacts to the situation.

I'm sure Nick or Jon will be able to give a more detailed reply to you at some point Smile
Back to top
View user's profile Send private message Send e-mail
liaison
ionCube Support


Joined: 16 Dec 2004
Posts: 2788

PostPosted: Sun Feb 26, 2006 8:36 pm    Post subject: Reply with quote

Hi

Thanks for the posts guys. This is very old and stale news now, and we've discussed this and what we've done about it at length on various forums. You'll also notice our post last year announcing that a new security solution would be released. We're on the ball Smile

Since antizend.com and phpdecode.com popped up last year targetting Zend, we were on a heightened state of alert if you like, regarding this issue. For 3 years or so, the solutions have been highly effective, striking the right balance between achievable protection and practicality. With PHP opensource you've the biggest weakness right there, and so we use the techniques of code compilation, coupled with a closed source execution to get excellent performance with good security. Really we'd like to require our encoded files to work with a closed source ionCube version of PHP. We could make PHP better, make it different internally, and with everything closed source there'd be great security. But, how many shared hosts would install a custom version of PHP just to run an encoded file? None is the answer, so it would never fly as a solution. We'd also like to change the encoding algorithms periodically, requiring updated Loaders. However this would cause so much upset and problems for end users that this would never work either. So, there are compromises, but the technique of compiled code and a closed source executor is fundamentally sound, and probably the best way to go in the general case.

What most likely happened is that the Chinese modified the Loader and Zend Optimiser from Zend at the binary machine code level to expose compiled code, which is very difficult btw., and also wrote a decompiler to recreate what source code could have been from the compiled PHP. This is an exceptional kind of attack, and modifying C programs by actually poking the shared library is impossible to stop, so one has to make it as difficult as possible for this to be effective.

With the release some weeks ago, we added a number of features to make it harder to locate valid compiled PHP code, as this is the starting point for using a decompiler. Working on the assumption that at some point, compiled code may be obtained again in the future, we also added extra security mechanisms to obfuscate the compiled code internally, as well as parts of the PHP code such that reversal of the compiled code will be harder, and perhaps making it impossible to reconstruct a working program. The extra security comes at a price of a little extra overhead at runtime, and slightly slowed encoding vs. to earlier releases, but we worked hard to optimise the solutions so that the impact is not as much as it could have been, and the results are good.

In terms of choice of solution for security, the compiled code solution represents the best way to go, but note that now not all compiled code solutions are the same. Whereas in the past, any compiled code system would be good enough, now it's vital in out opinion to go for one that uses a closed source execution engine, because the others are just passing standard compiled code to PHP where it can be intercepted.

Our solution and Zend obviously do this, and if looking at any others, be sure to ask about that aspect of their solution.
_________________
Community Admin
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    ionCube Forum Index -> ionCube PHP Encoder All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum