JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
in [JavaScript]
|
Prev: Code Guidelines
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Andrew on 23 Dec 2009 05:27 Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Lasse Reichstein Nielsen wrote: > > Thomas 'PointedEars' Lahn <PointedE...(a)web.de> writes: > >> AIUI, that means in a nutshell that you cannot devise a general function > >> that computes another function that computes the same result for the same > >> input (a trivial property) as a third function. > > > I don't think you can conclude that from Rice's theorem. > > > It may not be possible to detect, in general, any non-trivial property > > of a given partial function, but that doesn't preclude creating a > > different (syntax for) a function that behaves the same. > > Not for an intelligent being, that is. But that was not what was asked.. Actually, this might be the point - the set of possible transformations _would_ be done by an intelligent being (the developer preparing the mangling system). Only the choice and application of the transformations would be done by an algorithm (the mangler program). > > You just can't tell a-priori what the behavior is for all inputs. > > That is exactly the point of Rice's theorem, and the reason why what the OP > wants cannot be done. > > > Trivial example is eta expansion: > > f |-> function(x) { return f(x); } > > > You can argue whether the latter is a *different* function from "f", > > but in this case it's not important. The desired result is a function > > that is extensionally equivalent to the original, but with a more > > convoluted syntax. > > Your example function, when called, would recurse (call itself) until the > stack memory runs out. (So yes, it holds, but not on a Turing machine ;-)) I think you misunderstood the syntax - "|->" is not the same as "=". Enjoy!
From: Scott Sauyet on 23 Dec 2009 13:45 On Dec 22, 3:26 pm, Andrew <anz...(a)gmail.com> wrote: > function b(v) { > return(a(-v)); > } > > function a(x) { > if (x>7) > { > var a=x+3; > var d=x-7; > c=(a%x)+4; > return((d+c)*(d+c)) > } > else > return((x>0)?(x*x):(b(x))); > } But how would you tell your super-obfuscator about the boundary conditions? // a(36028797018963969) = 1.2980742146337066e+33 // 36028797018963969 * 36028797018963969 = 1.298074214633707e+33 // a difference of 288230376151711740 So for the value x = 36028797018963969, not only is a(x) != x * x, and Math.abs(a(x) - x * x) > 0, (much greater!) In other words, even for your simple, hand-tuned function, there are values for which it does not match the intended function. Perhaps this input value is irrelevant to your code, but do you have to indicate to the tool the possible values for every function? I think you're underestimating the difficulty of creating such a tool. Moreover, even if you could build it, it would only stop casual viewers from understanding your code. Anyone who understands Javascript could, with some perseverance, be able to weed through this nonsense to understand the core of your programs. In other words, while I think this is an interesting abstract discussion, I don't think there are any real chances of building a tool that does what you want. -- Scott
From: Thomas 'PointedEars' Lahn on 23 Dec 2009 18:23 Andrew wrote: > Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: >> Lasse Reichstein Nielsen wrote: >> > Thomas 'PointedEars' Lahn <PointedE...(a)web.de> writes: >> >> AIUI, that means in a nutshell that you cannot devise a general >> >> function that computes another function that computes the same result >> >> for the same input (a trivial property) as a third function. >> > I don't think you can conclude that from Rice's theorem. >> > >> > It may not be possible to detect, in general, any non-trivial property >> > of a given partial function, but that doesn't preclude creating a >> > different (syntax for) a function that behaves the same. >> >> Not for an intelligent being, that is. But that was not what was asked. > > Actually, this might be the point - the set of possible > transformations _would_ be done by an intelligent being (the developer > preparing the mangling system). Only the choice and application of the > transformations would be done by an algorithm (the mangler program). You are still missing the point. >> > Trivial example is eta expansion: >> > f |-> function(x) { return f(x); } >> >> > You can argue whether the latter is a *different* function from "f", >> > but in this case it's not important. The desired result is a function >> > that is extensionally equivalent to the original, but with a more >> > convoluted syntax. >> >> Your example function, when called, would recurse (call itself) until the >> stack memory runs out. (So yes, it holds, but not on a Turing machine >> ;-)) > > I think you misunderstood the syntax - "|->" is not the same as "=". That is true, but it does not matter. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 23 Dec 2009 18:32 Scott Sauyet wrote: > In other words, while I think this is an interesting abstract > discussion, I don't think there are any real chances of building a > tool that does what you want. And even if there were, it would not be desirable to use in production code, for with greater complexity comes less efficiency. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Andrew on 27 Dec 2009 14:00
On Dec 23, 7:45 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > In other words, even for your simple, hand-tuned function, there are > values for which it does not match the intended function. Perhaps > this input value is irrelevant to your code, but do you have to > indicate to the tool the possible values for every function? > > I think you're underestimating the difficulty of creating such a > tool. Moreover, even if you could build it, it would only stop casual > viewers from understanding your code. Anyone who understands > Javascript could, with some perseverance, be able to weed through this > nonsense to understand the core of your programs. I am beginning to think that the example was not such a good idea... yes it's flawed. It is an EXAMPLE, not proof of concept. You can do better if you wish. :) So, to recap: - of course it is possible to do it, at least to some extent (still not buying the Rice's theorem having to do anything with this - as Lasse pointed out, compilers do that all the time) - of course this is not the protection against determined hacker (much better than name replacement though) - of course there will be performance penalty > In other words, while I think this is an interesting abstract > discussion, I don't think there are any real chances of building a > tool that does what you want. Well, that might be true. But not because of all the things others have written in these posts, but because JS is such a difficult language for this task. I am no way an expert in JS, but from what I have seen (closures come to mind) there are some concepts that make it really hard to do this kind of thing. Not impossible, but difficult. Not sure it would be a bad business idea though - seeing how obfuscators sell for $60-$250 when they are not even remotely successful. If someone is capable of doing it, of course. I would have bought a copy right now, but of course, it would have to be so good that a capable programmer would have difficulties deducting what the code does. |