PHP encoders, cracked!
Tags:
Web 2.0
The site http://www.phprecovery.com/ is claiming it can recover compiled PHP codes from Zend, Ioncube, SourceGuardian, TurckMM, SourceCop, ScopBin and CodeLock. Looking at the submitted test scripts by users, it seems the decoder can only recover the code but not the comments.
I’m not surprised at all since most of these encoders just compiles the script or even if it uses some sort of encryption the keys are always the same such that you can create a lot of hashes then try to find the collision.
There are now discussions on how will this affect developers who uses encoders to protect their programs; how about those who already deployed their programs, how will they protect them now?
8 comments:
this sort of thing is pretty much expected as "anything encoded is not secured because a key always exist", anyway good thing you found this, cheers
-- zoticaic
Therefore, we need to modify the encoding software such that we can specify a key unique to our machine. =)
[ simon.cpu ]
This is very old news now, but good to see it discussed. this really goes way back about 12 months to the russian sites antizend.com and phpdecode.com that were targetting Zend encoded files specifically. Those sites weren't widely known about, and the much more recent Chinese/Indonesian phprecovery and Chinese "Blue Wind" are spinoffs in the same vein.
It's true that nothing can be 100% secure, and what these hackers are doing is modifying the Loader components to expose the compiled code. Java bytecode has always been reversible to source. Compiled C code can be reversed to source. It's always possible. However, Zend and ionCube have always been strong solutions as a closed source execution engine is used, and no one had developed the skills to write a decompiler. However prevention of binary level patches to the decoding and execution engines is impossible without encryption support at the silicon level, and the threat potential always existed.
However, this is not to say that things cannot be done to make it much harder to discover valid compiled code, and to recreate a working program through decompiliation, and this is what we've done with ionCube 6.5.
While others, most notably Zend, were seeming to hide the issue under the carpet, and even publicly criticising their customers for being as bad as the hackers merely for being concerned about it (see http://www.litfuel.net/plush/?postid=109), we were being happy to discuss this type of issue and working hard on a solution. On Jan 16th we released Encoder 6.5, with new innovations such as one way obfuscation techniques for obfuscating elements of the original source code, and an obfuscating execution engine that executes obfuscated opcodes rather than more standard compiled code as previously. Even if/when opcodes are exposed in the future, the source level obfuscations may prevent reconstruction of working source code, at least without time consuming work on a script by script basis. To date, ionCube 6.5 has not been successfully reverse engineered to any useful level, although realistically this may happen one day, but with the new features incorporated into 6.5, and being aware of critical design flaws in some other updated solutions, ionCube 6.5 offers the strongest compiled code solution for protecting PHP code at the moment.
The presence of decompilers for PHP, if not in the wild, but as a service, does now cast compiled code solutions into two camps, and this is worth noting. Whereas before it was enough to have a compiled code solution that had a closed source Loader, it's now essential to have one that contains an execution engine. ionCube and Zend offer this, but at the time of writing, other solutions rely on PHP to execute code, and this is a weakness as the opcodes are trivially exposed, and opportunities for using non-standard opcodes do not exist.
It's definitely an interesting area, and one that we're passionate about. Anyone wanting to find out and learn more about protecting PHP is welcome to contact us and we'll be happy to discuss, whether for licensing and protecting intellectual property of code that is distributed, or for protecting website scripts from hackers and other users on the server, and which is particularly important on shared servers and a growing area.
We love you, ioncube! You rock! =)
[ ]
Its true any compilation can be reversed back to source but it may not always be the original and thats one good point where obfuscation can be useful. Ofcourse i can just put trace marks on the code and using Zend's debug->trace->step you can easily figure out the obfuscation.
I see one of the way to making it "virtually" hard to decompile is by allowing users to set their own keys (certs) and make a "polymorphic-encryption" routine that re-encrypts the source over and over (inheriting the properties of polymorphic viruses). Importing certificates to the Engine itself is a big plus and will work like a DRM feature for the engine.
Hi
You can't figure out the obfuscation that way because the debuggers won't run, at least not on ionCube code, but there could be a flaw there with Zend. Unless Zend have changed it, there are certainly other ways to figure out the obfuscation in Gaspra though.
1) They have made the obfuscation function available as a callable function in Zend Optimiser.
2) The obfuscated strings are the same length as the original ones.
I wonder what the phrases "loop hole" and "brute force attack" are in Hebrew.
There are some other design flaws with the latest release that make some other aspects to the obfuscation worthless, but we'll leave that as an exercise for the reader. That said, they may have patched up the holes since we last looked, which was when we were doing compatibility testing with our latest release a few months ago.
With regards to encryption keys, they're really a red herring in this type of system. Encryption per-se isn't that important, as the encoded files will be decoded at run time anyway. In essence, why try to reverse something that's going to be reversed anyway. Locking to hardware keys such as a CPU or motherboard key would be nice, but this isn't really effective either as a hacker will just obtain a copy of a product that is licensed to a machine that they own or have access to.
Given that there is a decoder anyway in order to run encoded files, compiled code encoded files have actually never been the weakest point, and from what we can tell, have never been decoded. The point to attack is *after* the files have been decoded, and so what's most crucial is the form of the decoded data. Until there were threats of a decompiler, regular compiled code was good enough, and using a closed source executor was a nice bonus. With people poking at the machine code of the decoder components, and having skills at recreating source code from bytecode, it's more important to deviate away from regular compiled code. Other techniques such as preventing compiled code from being obtained by looking at the internal PHP function tables are also important, and are the type of techniques that we use.
admin put on line to 1 user only recovery opcode encoded gaspra it work really
check here
http://www.phprecovery.com/forum/zend-test/60-test.html
Well, you can always make your own PHP interpreter. And oh, please make sure that in runs on FreeBSD 6.x amd64 too. *wink*
You rock, ioncube!!! =)
[ fvzba.pch ]
Post a Comment