JavaScript code mangler / scrambler / ... khm, more than

[Scott Sauyet]

No, you wouldn't if you were a paying user of my webapp.

Maybe that's the difference. I've never had someone pay to use my
webapps. They are either freely available, or locked in a corporate
Intranet. I've certainly never been in a situation where the webapp
is itself what people are paying to use.

Ok. But I gave you the tools to decript them with ease.

I saw that, but not until after I'd finished sending my second
response. The first one was easy. The second one, I clearly
missed a step, but still ended up close enough to get most of the
sense of it. The version I ended up with started, "It's simple. I li}
e this k{nd of t�{ngs". I'm curious as to what I missed, when I did,
this:

rot13(base64(rot13(~coded data~)))

What was the missing step?

-- Scott

 

[Jorge]

    rot13(base64(rot13(~coded data~)))

What was the missing step?

That it's a rot135, not a rot13.

 

[Scott Sauyet]

That it's a rot135, not a rot13.

Ah, never seen that before. Interesting...

-- Scott

 

[Andrew]

Sorry.   All you really need to do is Google do for "Control flow
obfuscation"
or "Data flow obfuscation", or read any of Christian Collberg's papers
or any paper that references Collberg :-}

Well, I would, except that I didn't know that the paper you were
citing is from Collberg (or its title either)... I did manage to find
some other very interesting papers though, which is just as well. :-D

Thanks, I'll take a look at it.

 

[Thomas 'PointedEars' Lahn]

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

 

[Scott Sauyet]

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.

 

[Andrew]

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!

 

[Scott Sauyet]

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

 

[Andrew]

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?  

It's somewhere in between of those two... But more former than the
latter.
If such tool was readily available, I would have been a happy customer
- the cost of obfuscators is usually small enough that it doesn't make
a difference in the project's funds. This is in the line of "it
doesn't hurt and it mught help" type of thinking.
But buying the "normal" JS obfuscators is meaningless, I could
"decode" such code in a matter of minutes.

The third reason is plain curiosity - I just wanted to know what can
be done.

Thanks again!