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....
Comments
Programmer
Im sure you have heard this phrase before.
"Locks are to keep honest people honest, dishonest people will find a way around the lock".
In the C world, compiling of code is not about security its just the way C works. They are removing that "extra" step which provides for faster running and a easier to distribute product. There are decompilers out there, How do you think people hack games?
Compiling of php keeps the honest person honest, thats it. The dishonest person will always find a way around what ever method your using to protect your scripts!
Look at the ipod, half the time it doesn't even take a day after some release for a new version of some program to unprotect itune files pops up.
-
Indeed, with Derick's VLD You can dump the opcodes.
But how do You map/parse the Opcode back to php source ?
That's a challenge!
Chef
Nice story!
I hope they will crack it. I never by php if the code is encrypted.
Let's consider this a little
"I never by php if the code is encrypted."
People with this attitude have never paid for any source code in their life, and never will.
"Compiling of php keeps the honest person honest, thats it. The dishonest person will always find a way around what ever method your using to protect your scripts!"
This is correct and absolutely fine. It is where much of the value in the better tools lies with their ability to help do what any business must do, which is maximise revenue. Let's consider the two factions that you identified.
Dishonest people, the types that will hack if they can or else spend days or weeks looking for hacked software, do not buy software, period. Therefore whether they eventually do or don't get hold of hacked software is irrelevant to the provider as it does not represent any loss of revenue. Sure it's annoying but that's it, and there is even the possibility that one day the dishonest person, once they finish school and leave home to enter the real world, may mend their ways and actually buy the product, and this may never have happened had they not been able to have an extended "trial" and grow to appreciate a product.
This leaves us with the honest person and the issue of temptation. No shop would let people walk out with products for free and the offer to come back and pay if they like it, but this is precisely what software providers are doing if they provide evaluations in source form. The major value of the better protection tools is therefore to take away temptation by making access to source code substantially non-trivial, particularly during the evaluation process, and this can boost sales revenue by several times. It's a simple fact that no solution can offer total security, whether it's to software, your house or car, or anything else, but it's also the case that it doesn't need to. The maximum damage to a business comes not from software theft of protected solutions, but from not having any protection at all, and the benefit to a business from adding non trivial code protection is immense.
Not True...
"Dishonest people, the types that will hack if they can or else spend days or weeks looking for hacked software, do not buy software, period."
I have to hack code and software that I have purchased to make some minor tweaks.
For example: I have a google checkout module for a CMS that was purchased from a company and installed on a domain alias. Before the site goes live I have to crack the code to put the correct url in. If the code was written to account for this there wouldn't be a problem, but when is code ever perfect(my code included)? If I contact the company that I purchased the module from, I will have to wait until who knows how long before going live. It is true sometimes there is no delay, but my customer wants to go live now that the project is basically completed. Do I wait, delaying getting paid from the customer longer or just hack the code and get paid now?
Another Example: I use both windows and Linux. I can't stand being required to register my Windows license with Microsoft. Someone came up with a hack to fix that and since I purchased my copy of Windows who is being unethical or dishonest?
There are plenty of other examples I can post, but the reality is sometimes the honest people really do need to hack to make life better and easier. You shouldn't close your mind and think outside the box. There are always possibilities or reasons you haven't thought of.
I realize the comments on this page are old, but I just came across this and had to throw my 2 cents in.
