JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
in [JavaScript]
|
Prev: Code Guidelines
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Thomas 'PointedEars' Lahn on 8 Jan 2010 22:10 Andrew wrote: > On Dec 29 2009, 6:46 pm, Thomas 'PointedEars' Lahn > <PointedE...(a)web.de> wrote: >> Scott Sauyet wrote: >> > You didn't respond to Lasse Nielsen's last post, but, if you're right >> > that Rice's theorem says that you cannot programatically convert a >> > function to another of identical behavior, how do explain the >> > existence of compilers? >> A compiler transforms source code into machine-dependent code; IOW, it >> translates one higher-level language into another, lower-level language. >> That is a concept fundamentally different from that which Rice's theorem >> addresses. > > Ok, then, let's use JS minimizers and obfuscators as an example > (instead of compilers). They transform source code so that it is > written in another way, yet it performs the same as it did. > Not that they are useful for this case, but they are instant proof > that such transformations are possible - and by automated tools too. Apparently there has been a gross misunderstanding here. Of course what you describe is possible. I had no intention of denying that. It is a completely different thing, though, for a program to *recognize* by mere code analysis *whether* two functions (that have *non-trivial* differences, which excludes minimizers and obfuscators, including the Y-combinator approach) are functionally identical or not. That is the problem which Rice's theorem addresses and which can be proven to be undecidable by reduction to the undecidable halting problem. And if one reads more closely, *that* is the problem posed by you in the OP (as also indicated by the Subject line "... more than obfuscator ..."). PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Scott Sauyet on 9 Jan 2010 16:38 On Jan 8, 10:10 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Andrew wrote: >> Ok, then, let's use JS minimizers and obfuscators as an example >> (instead of compilers). They transform source code so that it is >> written in another way, yet it performs the same as it did. >> Not that they are useful for this case, but they are instant proof >> that such transformations are possible - and by automated tools too. > > Apparently there has been a gross misunderstanding here. Of course what > you describe is possible. I had no intention of denying that. It is a > completely different thing, though, for a program to *recognize* by mere > code analysis *whether* two functions (that have *non-trivial* differences, > [ ... ] And if one reads more > closely, *that* is the problem posed by you in the OP (as also indicated > by the Subject line "... more than obfuscator ..."). With all due respect, I don't think that is what the OP was suggesting. It's hard to know of course, but I think this from the OP: | BUT: I am looking for something that would NOT (only) do | the basic comments stripping / names renaming, but also | changed the (apparent, of course) flow of the program. more implies something that can operate at the syntactic level. The original example (which, as already pointed out, doesn't work) seemed to me to attempt to operate on a function in a manner that could be automated without any recognition of what the function was calculating. I would expect that if the OP really wanted a tool that would comprehend the meaning of the functions, he would have actually said so. I can understand that "more than obfuscator" sounds more like something beyond the limits of Rice's theorem, I took it to mean more than the weak current obfuscator. This seems to offer additional evidence: "To unscramble such code you would in general need an execution optimizer." Such tools also work at the syntactic level, albeit with some deep understanding of the language and their interpreters/compilers. It's hard to imagine a semantic encoding that could be decoded syntactically. But perhaps the OP is still around? Andrew, do you mean that the code would have to recognize, for instance, a squaring function and change it based upon that? Or would it be enough that the tool could somehow do syntactic changes hard to recognize and reverse? -- Scott P.S. I do want to reiterate that even if it could be done, I'm not in favor of it.
From: Andrew on 28 Jan 2010 03:49 On Jan 9, 10:38 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 8, 10:10 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: > > Andrew wrote: > >> Ok, then, let's use JS minimizers and obfuscators as an example > >> (instead of compilers). They transform source code so that it is > >> written in another way, yet it performs the same as it did. > >> Not that they are useful for this case, but they are instant proof > >> that such transformations are possible - and by automated tools too. > > > Apparently there has been a gross misunderstanding here. Of course what > > you describe is possible. I had no intention of denying that. It is a > > completely different thing, though, for a program to *recognize* by mere > > code analysis *whether* two functions (that have *non-trivial* differences, > > [ ... ] And if one reads more > > closely, *that* is the problem posed by you in the OP (as also indicated > > by the Subject line "... more than obfuscator ..."). > > With all due respect, I don't think that is what the OP was > suggesting. It's hard to know of course, but I think this from the > OP: > > | BUT: I am looking for something that would NOT (only) do > | the basic comments stripping / names renaming, but also > | changed the (apparent, of course) flow of the program. > > more implies something that can operate at the syntactic level. The > original example (which, as already pointed out, doesn't work) seemed > to me to attempt to operate on a function in a manner that could be > automated without any recognition of what the function was > calculating. I would expect that if the OP really wanted a tool that > would comprehend the meaning of the functions, he would have actually > said so. > > I can understand that "more than obfuscator" sounds more like > something beyond the limits of Rice's theorem, I took it to mean more > than the weak current obfuscator. This seems to offer additional > evidence: "To unscramble such code you would in general need an > execution optimizer." Such tools also work at the syntactic level, > albeit with some deep understanding of the language and their > interpreters/compilers. It's hard to imagine a semantic encoding that > could be decoded syntactically. > > But perhaps the OP is still around? Andrew, do you mean that the code > would have to recognize, for instance, a squaring function and change > it based upon that? Or would it be enough that the tool could somehow > do syntactic changes hard to recognize and reverse? I'm still around, though not that close... ;) (sorry for late response) Just to answer the question about my intent - Scott, you understood my intent correctly. Thomas, I'm sorry if I wasn't clear enough in my first post (and later ones). It did refresh my (and possibly other people's) knowledge on the subject though, so the posts were not wasted :) So, to recap what I've learned: - it is possible - the correct keywords are "control flow obfuscation" - no such tools exist for JS (yet) About the value of such tool... Well the opinions differ. My opinion is that: - it would be helpful in some cases (like mine :-D ) - it would be grossly misused in most of the cases But since such tool doesn't exist yet and I have no intention of writing it, I will just minimize and publish my JS code. Again, thank you all, I've learned a bit more. :) Enjoy!
From: Ira Baxter on 28 Jan 2010 10:32 "Andrew" <anzesk(a)gmail.com> wrote in message news:08bdcb3b-d9d2-458c-94c2-8a0bd36e95fe(a)a32g2000yqm.googlegroups.com... On Jan 9, 10:38 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 8, 10:10 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: > > Andrew wrote: > >> Ok, then, let's use JS minimizers and obfuscators as an example So, to recap what I've learned: - it is possible - the correct keywords are "control flow obfuscation" *** and "data flow obfuscation" *** - no such tools exist for JS (yet) *** the basic capability exists in tools that manipulate JS. *** The DMS Software Reengineering Toolkit could be used to implement this. About the value of such tool... Well the opinions differ. My opinion is that: - it would be helpful in some cases (like mine :-D ) - it would be grossly misused in most of the cases *** We haven't seen a lot of demand, and users of such *** tools want them to be "push the button" and it isn't that easy. *** Most of the potential users seem to have a hard time with *** just simple identifier scrambling and the notion of "public" vs. not. ** Ira Baxter, CTO*** www.semanticdesigns.com But since such tool doesn't exist yet and I have no intention of writing it, I will just minimize and publish my JS code. Again, thank you all, I've learned a bit more. :) Enjoy!
From: Scott Sauyet on 28 Jan 2010 10:45
On Jan 28, 3:49 am, Andrew <anz...(a)gmail.com> wrote: > On Jan 9, 10:38 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: >> But perhaps the OP is still around? Andrew, do you mean that the code >> would have to recognize, for instance, a squaring function and change >> it based upon that? Or would it be enough that the tool could somehow >> do syntactic changes hard to recognize and reverse? > > I'm still around, though not that close... ;) (sorry for late > response) No problem. We're not going anywhere. :-) > Just to answer the question about my intent - Scott, you understood my > intent correctly. Thomas, I'm sorry if I wasn't clear enough in my > first post (and later ones). It did refresh my (and possibly other > people's) knowledge on the subject though, so the posts were not > wasted :) No, it was a very interesting discussion. > So, to recap what I've learned: > - it is possible > - the correct keywords are "control flow obfuscation" > - no such tools exist for JS (yet) And, IMHO, they would be more difficult to write for JS than for less dynamic languages. I don't mean that it's impossible; I am, after all, the one who brought up the Y-combinator. But I imagine that this sort of transformation might leave obvious and easily reversible traces. Ones that wouldn't do so would be much harder to write. > About the value of such tool... Well the opinions differ. My opinion > is that: > - it would be helpful in some cases (like mine :-D ) > - it would be grossly misused in most of the cases > > But since such tool doesn't exist yet and I have no intention of > writing it, I will just minimize and publish my JS code. Are you willing to share your reasons for wanting this? Is it simply an attempt to keep a jump on the competition? Or is it one of those thing that you'd tell me, but then you'd have to kill me? :-) > Again, thank you all, I've learned a bit more. :) Ditto! Cheers, -- Scott |