And now for something normal .... back on PHP land....
Someone posted a comment on a post I did a while back about a
product that was supposed to provide encryption on PHP scripts. (That blog post was probably my most controversial, as the author of the application send me an email asking me to contact his lawyers....)
The post this time was about another magic cure, php recovery, a new web site claiming (or appearing to) sell a product to recover php source code after it has been encrypted. Well, considering my last post, using plain old PHP methods, this is perfectly feasible. However they also claim to restore your code if it was encrypted with ioncube and Zend's encoders, which, not having tried them, but knowing the author of both products reasonably well, I have a few doubts about.
Well, for the uninformed, the basic premise of Zend encoder and ioncube (as far as I know) is the same as bcompiler, which I created based on some of the code in APC. Basically the idea is to deal with the bytecodes that PHP creates. For a normal file, this would be function, class definitions, and raw code. (although conditional classes are a bit complex from my recollection)
Looking at the basic premise of converting these bytecodes back into PHP, while it is definatly feasible, there would be significant limitations to the end result.
- uncommented! - if any of the encodes obsfucate the variable names or function names on compilation, you are in real trouble here..
- layout and formating. - no whitespace or formating by a programmer..
- optimizations my modify the code - chances are after decompiling it, a few bytecode optimizations would have occured, often making the code even more difficult to understand.
If you want to play with a potential decompiler, have a google for Derick's VLD, this can dump the opcodes to a readable format, from there, it's not totally impossible to create the code from it.
What always strikes me is the whole issue about bytecode compilers, when I wrote bcompiler originally, One of the reasons was to protect the source, however, this protection is totally superficial, and probably only valid in the 'try-before-you-buy' market. (Which in our case was going to be giving embedded linux boxes with compiled PHP code on them). Even that in hindsight was a very questionable use. I would be extremely wary of using any code that was encoded on a mission critical project. Lag times for response, and long term support risks are just too big to consider anyone providing encoded source. (on the other end, dont deliver all the code without even a deposit! - especially to questionable dotcoms...)
As for our mysterious php recovery application, If this guy is serious, he should at least fill out a valid domain registration details for whois. Sorry 12345689 in JAPAN doesnt look much like a valid telephone number to send your money to....
