Originally Posted by
mrobinson
A few months ago I developed a script encoding system along the same lines (completely written in PHP). I even used gzip/base64 to obscure the code as you describe (although to limit performance degredation I only did this 3 times). I even went as far as to work on an extension module (quite a learning curve with no C experience). I quickly decided that I wouldn't develop it further. Unfortunately, regardless of the encoding method used it will need to be decoded and evaluated at some point. As has already been suggested this is the weakness (You beat me to it Daijoubu, read "replace eval with echo").
Ok. I'll say this much, I've been evaluating systems like Codelock and also looked at the technique of Richard Fairborne's example... and I see them as perilously flawed, for these reasons.
I started working to concieve my own, and I think I came up with a very interesting solution. I'll note a caveat at this point however. The remarks made by ioncube are sobering. If someone has the knowlege to recompile a customized version of the php interpreter, they may well be able to hand themselves a version of your source code... but, I think the technique I'm thinking of still suggests a much more secure obfuscation method than these others.
My thought... as you see people base64 and gzip at a number of levels. What if you had more customized functions on every level of obfuscation changing "the game"? If instead of using standard php functions, you used your own functions at each level, and some of these functions (at the deeper levels), used facets of information from each of the previous levels... to the degree that one would literally need to sit and piddle through the levels, and follow the code logic like breadcrumbs... up and down the consecutive levels of obfuscation.
For example...
Final code might look like this...
Code:
function o(m,p){var out="";var I1O1I,OI10,II00="";
var O00O,OO0O,O0O0,OOO0="";var i=0;m=m.replace(/[^A-Za-z0-9+/=]/g,"");
eval(p);return out;}m="FN8D%q0UTRD0<s*9S%TS.M&i@[}#@3Ti.%OsEm0U.w9[U%HfFJ*7TQu8F#D0<w&v@squ<3H[UJiu>IihU#iD%s*q<RTf@dGq<3H[nQ91<R}v<sr=nMT=nRSeTRD0<smu>Im&UIu7NGeqSQvwU%HfF%r=nRTi.M4eTRD0<sujWIuwTq0US%}0<wvjURD1{dD0<squ<3H[V%HfVNOfUI{wNGeqSRH[>M0e<3Ls<3H[U%H=nRSiTQuhWIm&UIuf<RTf@dGqSs0sEm0UpG0UNGe/Fqzz";do{O00O=k.indexOf(m.charAt(i++));OO0O=k.indexOf(m.charAt(i++));O0O0=k.indexOf(m.charAt(i++));OOO0=k.indexOf(m.charAt(i++));I1O1I=(O00O<<2)|(OO0O>>4);OI10=((OO0O&15)<<4)|(O0O0>>2);II00=((O0O0&3)<<6)|OOO0;s=String;x=s.fromCharCode;out=out+x(I1O1I);out=(O0O0!=64)?out+x(OI10):out;out=(OOO0!=64)?out+x(II00):out;I1O1I=OI10=II00="";O00O=OO0O=O0O0=OOO0="";}while(i<m.length);o(m,p);
(NOTE: The string above is basically a javascript example, but just translate it in your head to php.)
A mutating string of characters could be used to perform a "string translate" at different points (in different ways), and equations could be used to construct strings and behaviors up and down the deobfuscation hops.
Essentially, what if NEW functions were introduced at each deobfuscation hop, and each of those functions may be combined mixed and matched at any point in the hop, in getting to the hop that follows. I would say 10 "hops" max would have the code in such a state as to be an obsolute irritation to understand. The only way to GET the code, would literally be to RUN it, or to literally step through the code, having each level of obfuscation on a separate page that you could reference, and track the logic from. Though... fractured correctly, it may be ultimately impossible for most people to interpret (or follow).
While your "encrypting" script could "encrypt" your code in seconds, you would not be able to "decrypt" very easily at all, as you could even make the self evaluating process of the script different every single time you perform an encryption (as the script "decrypts" itself, so you'll never need to do much else).
Looking at codelock, it seems even that project saw fit, only to gzip/base64 the code a number of times, before letting out into a body of code that further tried to rearrange things. To me, that's all fine and good, but it completely smacks of "easy to get at" to me. If all you're going to do is gzip/base64, before letting people at the final code logic... its pointless. Even using it at one level in vanilla form is pointless. The method I suggest above seems much more impenetrable (with the exception of... REALLY REALLY determined expert hackers, or people that can recompile the PHP CLI to their liking).
I'm going to keep working on the method I suggested, unless someone who understands what I'm describing can find a fatal flaw other than what I've pointed out. I also wanted to try SourceGuardian, but its as expensive as Zend and Ion, and also requires PHP version specific files to be distributed (so if they ever go away, or slow their release of new versions for new versions of PHP, your a little up the creek).
Originally Posted by
mrobinson
For any serious work I would want my code compiled (and I lean towards IonCube).
How easy have people found it to distribute files that have been encoded with IonCube or Zend? That's the only thing that puts me off using them... the idea that users may have Hosting companies that make it impossible to use them, or that they simply don't know how to get these systems up and running easily. Is it easy?
Regarding the argument of using open source products to create closed-source products... I think that's bonkers. PHP wouldn't be where it is today without being open sourced. It's a particular model. If everything should be OPEN SOURCE that used open source technology, things would get more expensive, as people would need to make up for the THEFT levels. vBulletin and X-cart have to deal bitterly with levels of theft, yet not all products can be as popular as those two, to make up for the theft. That's just reality.
~ DNexus
Bookmarks