423,498 Members | 1,177 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,498 IT Pros & Developers. It's quick & easy.

Javascript Obfuscator

P: n/a
Hi,

I am looking for a good javascript obfuscator - I found several on the
web, but I am looking for one that can also handle javascript in jsp,
html and java files - so I need a javascript obfuscator that handles
my entire web project.

Is there anything like that, preferable as a Eclipse plugin?

Thanks,

Martin

Aug 21 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On Aug 21, 4:11 am, Martin Mücke <Doo...@gmx.dewrote:
Hi,

I am looking for a good javascript obfuscator - I found several on the
web, but I am looking for one that can also handle javascript in jsp,
html and java files - so I need a javascript obfuscator that handles
my entire web project.

Is there anything like that, preferable as a Eclipse plugin?
If you are a Java type then I think the new YUI Compressor is likely
the best option for you as a starting point. I think you'll will have
to write the plugin part that strips and replaces code from the JSP,
HTML and Java files. That or you could just make sure that all your
JavaScript lives in pure JavaScript files that are dynamically added
to other files. I'd vote for the later solution.

Peter

Aug 21 '07 #2

P: n/a
Martin Mücke wrote:

I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
Aug 21 '07 #3

P: n/a
On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
Martin Mücke wrote:
I am looking for a good javascript obfuscator [snip]

In my opinion, there are no "good obfuscators".
And why is that? That is almost like saying there are no "good
compilers." If the obfuscator goes all the way by parsing the code and
building an abstract syntax tree there is certainly a possibility of a
good obfuscator. I believe that the YUI and Dojo tools use the Rhino
engine to parse the JavaScript and then analyze the AST. These strip
IE conditional comments but I don't think that limits them from begin
"good".

Peter

Aug 21 '07 #4

P: n/a
Peter Michaux said the following on 8/21/2007 12:33 PM:
On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
>Martin Mücke wrote:
>>I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".

And why is that?
Ummm, because there aren't any? :) The problem isn't a good/bad
obfuscator, the problem is that even if you have a "good one" it is a
wasted effort.
That is almost like saying there are no "good compilers."
If the obfuscator goes all the way by parsing the code and
building an abstract syntax tree there is certainly a possibility of a
good obfuscator. I believe that the YUI and Dojo tools use the Rhino
engine to parse the JavaScript and then analyze the AST. These strip
IE conditional comments but I don't think that limits them from begin
"good".
So you think a program that breaks otherwise properly working code can
be called "good"?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Aug 21 '07 #5

P: n/a
On Aug 21, 1:51 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Peter Michaux said the following on 8/21/2007 12:33 PM:
On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
Martin Mücke wrote:
>I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
And why is that?

Ummm, because there aren't any? :)
What is your criteria for a good obfuscater? Does it necessarily have
to deal with every possible bit of code that could go in script tags?
Or just deal with the subset of code that you write?

Do you minify your code at all?

The problem isn't a good/bad
obfuscator, the problem is that even if you have a "good one" it is a
wasted effort.
Not a total waste, it makes it harder/slower to understand the code
and so will throw off some wimpy thieves. If the value of smaller
downloads and moderate protection exceeds the cost of development/
maintenance of the obfuscator then on balance an obfuscater is a good
idea.

That is almost like saying there are no "good compilers."
If the obfuscator goes all the way by parsing the code and
building an abstract syntax tree there is certainly a possibility of a
good obfuscator. I believe that the YUI and Dojo tools use the Rhino
engine to parse the JavaScript and then analyze the AST. These strip
IE conditional comments but I don't think that limits them from begin
"good".

So you think a program that breaks otherwise properly working code can
be called "good"?
Sure a minifier/obfuscater can be good but it may not be perfect
because it may have a bug. An obfuscater is a JavaScript-to-JavaScript
compiler. All compilers have bugs but that doesn't mean we write
everything in assembly. When a compiler bug crops up we fix it.

Peter

Aug 21 '07 #6

P: n/a
Peter Michaux said the following on 8/21/2007 5:26 PM:
On Aug 21, 1:51 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
>Peter Michaux said the following on 8/21/2007 12:33 PM:
>>On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
Martin Mücke wrote:
I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
And why is that?
Ummm, because there aren't any? :)

What is your criteria for a good obfuscater?
I hate them so I don't have a criteria for what I would call a "good"
one versus a "bad" one. The biggest problem with them is that people
think that once they obfuscate code that they have "protected" it and
that simply isn't true. It doesn't mean there won't ever be one that
protects client side code, it just doesn't exist yet.

The other problem is that obfuscation and minimization and come to be
synonymous in the web world when they are entirely different animals.
Does it necessarily have to deal with every possible bit of code
that could go in script tags? Or just deal with the subset of code
that you write?
Ideally, it should be able to handle anything I write, or leave it alone
if it can't handle it.
Do you minify your code at all?
Are we talking about minimizing or obfuscating?

Minimizing has some effect, but I am not even sure that minimizing is
worth the effort unless it is done "on the fly" by the server.
>The problem isn't a good/bad
obfuscator, the problem is that even if you have a "good one" it is a
wasted effort.

Not a total waste, it makes it harder/slower to understand the code
and so will throw off some wimpy thieves.
If "wimpy thieves" are all you are trying to protect from, then the code
wasn't worth stealing to start with. If the code is so unique/complex
that it is worth stealing then the person stealing would have to be able
to understand it and if they can understand it then they can write it
and if they can write it they don't need to steal it. It is the
Obfuscation Paradox from hell.
If the value of smaller downloads
Smaller downloads are a result of minimizing, not obfuscating code. When
I talk/write about obfuscation I am referring to code that typically
starts with eval(.....
and moderate protection exceeds the cost of development/
maintenance of the obfuscator then on balance an obfuscater is a good
idea.
That same "moderate protection" can usually be gained by
src="hideMyCodeFromWimpyThieves.js"
>>That is almost like saying there are no "good compilers."
If the obfuscator goes all the way by parsing the code and
building an abstract syntax tree there is certainly a possibility of a
good obfuscator. I believe that the YUI and Dojo tools use the Rhino
engine to parse the JavaScript and then analyze the AST. These strip
IE conditional comments but I don't think that limits them from begin
"good".
So you think a program that breaks otherwise properly working code can
be called "good"?

Sure a minifier/obfuscater can be good but it may not be perfect
because it may have a bug.
You seem to be grouping them together as if they are the same thing when
they aren't. One of the side effects of minimizing can be some simple
obfuscating (renaming of variables, etc).
An obfuscater is a JavaScript-to-JavaScript compiler.
Most of the ones I have looked at don't do that. They simply minimize to
an extent, rename variables, convert it to a text string and then spit
out some eval('someTextHereInASCII') code.

But, if a minimizer or an obfuscator totally breaks my code because it
removed my IE conditional comments then I would definitely call it
anything but "good".

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Aug 21 '07 #7

P: n/a
Peter Michaux wrote:
On Aug 21, 1:51 pm, Randy Webb wrote:
>Peter Michaux said the following on 8/21/2007 12:33 PM:
>>On Aug 21, 8:41 am, The Magpie wrote:
Martin Mücke wrote:
>>>>I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
>>And why is that?

Ummm, because there aren't any? :)
>What is your criteria for a good obfuscater?
In principle an obfuscator is something that renders something else more
obscure (Note that the question asks for an obfuscator and not a
minimiser, so presumably minimisation is not the/a point). The criteria
for what would represent a good would depend on why an increase in
obscurity is desired. There would be some standard of 'sufficiently'
obscure, to satisfy the assumed need, and a good obfuscator would be one
that achieved, or exceeded, that level of obscurity.
Does it necessarily have to deal with every possible bit of
code that could go in script tags?
Or just deal with the subset of code that you write?
That is quite a strange question. The code that any individual may write
may include anything that javascript allows. Anything that works on
javascript source code should be required to handle everything that
javascript can do.
Do you minify your code at all?
It is obfuscation not minimisation that is the subject here.
>The problem isn't a good/bad obfuscator, the problem is
that even if you have a "good one" it is a wasted effort.
Not a total waste, it makes it harder/slower to understand
the code and so will throw off some wimpy thieves.
As has been pointed out before, if that code that is being written uses
any moderately 'advanced' techniques the odds are already good that it
is beyond the comprehension of your "wimpy thieves". I cannot remember
the name that is used, but the HTML groups talk of the principle that
the worth of any web source code is inversely proportional to the effort
made to conceal it.
If the value of smaller downloads
You are back to minimisation again. Because HTTP 1.1 introduced
standards for transition of content zipped/compressed, and user agents
support it, the size reduction effects of minimisation are not nearly as
significant as superficial observations may suggest. It has even been
demonstrated that some source code size reduction strategies have a
negative impact on subsequent zip compression, making the actual
downloads larger (if only fractionally).
and moderate protection
Moderate relative to what exactly?
exceeds the cost of development/maintenance of the
obfuscator then on balance an obfuscater is a good idea.
So you are not including the cost of QA on the post-obfuscated code?
>>That is almost like saying there are no "good compilers."
If the obfuscator goes all the way by parsing the code and
building an abstract syntax tree there is certainly a
possibility of a good obfuscator.
Isn't being able to handle the code as real javascript more of a
criterion for not declaring the obfuscator as unacceptably bad, rather
than a reason for declaring it good?
>>I believe that the YUI and Dojo tools use the Rhino
engine to parse the JavaScript and then analyze the
AST. These strip IE conditional comments but I don't
think that limits them from begin "good".
I have never liked IE conditional comments and I do not use them, but
realistically they are used so any obfuscator offered for general public
use should be designed to cope with them before it can even be
considered suitable for consideration.
So you think a program that breaks otherwise properly
working code can be called "good"?
Sure a minifier/obfuscater can be good but it may not be
perfect because it may have a bug. An obfuscater is a
JavaScript-to-JavaScript compiler.
Some may be, but certainly not all on offer are.
All compilers have bugs
but that doesn't mean we write everything in assembly. When
a compiler bug crops up we fix it.
If you are writing a compiled langue then you have no choice but use a
complier. Obfuscating javascript source code is absolutely optional, and
it has drawbacks including questionable effectiveness at addressing its
objectives, making post-obfuscation maintenance and debugging of the
code harder that it may have been otherwise and requiring that the
post-obfuscated code is fully QAed so that any problems that may have
been introduced by the obfuscation process can be identified.

Richard.

Aug 21 '07 #8

P: n/a
Peter Michaux wrote:
On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
>Martin Mücke wrote:
>>I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
And why is that?
Well, its because obfuscators are supposed to make code "coded" (as in
normally unreadable). And they don't.

If the obfuscator goes all the way by parsing the code and building
an abstract syntax tree there is certainly a possibility of a good
obfuscator.
No... that would be a code compressor.

These strip IE conditional comments but I don't think that limits
them from begin "good".
It also doesn't make them obfuscators. Just compressors.

And as a final blow - why would you even *want* to obfuscate the code
in the first place? I've yet to see any (including my own) that is
remotely worth the effort.
Aug 22 '07 #9

P: n/a
On Aug 21, 11:04 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Peter Michaux said the following on 8/21/2007 10:19 PM:
On Aug 21, 3:22 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Peter Michaux said the following on 8/21/2007 5:26 PM:
>On Aug 21, 1:51 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Peter Michaux said the following on 8/21/2007 12:33 PM:
On Aug 21, 8:41 am, The Magpie <use...@pigsinspace.co.ukwrote:
Martin Mücke wrote:
>I am looking for a good javascript obfuscator [snip]
In my opinion, there are no "good obfuscators".
And why is that?
Ummm, because there aren't any? :)
What is your criteria for a good obfuscater?
I hate them so I don't have a criteria for what I would call a "good"
one versus a "bad" one. The biggest problem with them is that people
think that once they obfuscate code that they have "protected" it and
that simply isn't true. It doesn't mean there won't ever be one that
protects client side code, it just doesn't exist yet.
The other problem is that obfuscation and minimization and come to be
synonymous in the web world when they are entirely different animals.
I see them as inextricable. Given that minification programs remove
whitespace that makes programs easier to read, minification programs
do obfuscate in a trivially reversible way. Obfuscater programs that
work by replacing identifiers choose short identifiers when possible
and so are minification programs.

What you are describing in this thread is more minimization than
obfuscation.
[snip]
This is the same script "obfuscated" (from a web search for obfuscators):
eval(unescape('%68%35%3D%30%3B%68%30%3D%27%%36%44% %36%35%%36%45%%37%34%%32%45%%35%35%%35%32%%34%43%% 33%42%27%3B%66%75%6E%63%74%69%6F%6E%20%68%31%35%28 %68%31%31%29%7B%68%38%3D%4D%61%74%68%2E%72%6F%75%6 E%64%28%68%31%31%2F%34%30%39%36%2D%2E%35%29%3B%68% 31%33%3D%68%31%31%2D%68%38%2A%34%30%39%36%3B%68%39 %3D%4D%61%74%68%2E%72%6F%75%6E%64%28%68%31%33%2F%3 2%35%36%2D%2E%35%29%3B%68%31%34%3D%68%31%33%2D%68% 39%2A%32%35%36%3B%68%31%30%3D%4D%61%74%68%2E%72%6F %75%6E%64%28%68%31%34%2F%31%36%2D%2E%35%29%3B%68%3 1%36%3D%68%31%34%2D%68%31%30%2A%31%36%3B%72%65%74% 75%72%6E%28%27%27%2B%68%31%39%28%68%31%30%29%2B%68 %31%39%28%68%31%36%29%29%3B%7D%68%32%3D%27%%34%41% %34%31%%35%36%%34%31%%35%33%%34%33%%35%32%%34%39%% 35%30%%35%34%%31%41%%30%30%%32%44%%32%41%%34%31%%3 1%44%%34%43%%34%46%%34%33%%34%31%%35%34%%34%39%%34 %46%%34%45%%30%45%%34%38%%35%32%%34%35%%34%36%%31% 42%%30%30%%32%44%%32%41%%34%32%%31%44%%34%34%%34%4 6%%34%33%%35%35%%34%44%%34%35%%34%45%%35%34%%30%45 %%34%34%%34%46%%34%44%%34%31%%34%39%%34
Ahh ok. Now I know what you mean. That mess of percents is really
crazy and trivially easy to undo. I suppose whitespace removal and
identifier replacement are both minification and obfuscation to some
degree. Actually identifier replacement is a better obfuscation then
those percents because it takes a person's slow analysis to undo what
identifier means what.

Thanks,
Peter

Aug 22 '07 #10

P: n/a
On Aug 26, 9:10 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

[snip regarding obfuscation/minification]

Thoughts and comments appreciated and points taken.
Any library claiming to be "good for everything" would be a bad library
for that reason alone, as there a no real world contexts where
everything is needed. (Considering that the project I am working on at
the moment now has a client-side code base of over 100,000 lines and it
certainly does not need to do 'everything', for example, there is
currently no code at all that attempts to manipulate user selections)
This actually made me very bitter when I first started
learning Rails and Prototype had the official stamp of
approval.

Does it still, or are the mistakes of the past being corrected?
Prototype is still packaged and integrated with Rails. Prototype is
getting better but some foundational design decisions (eg augmenting
built-ins) will always make it fatally flawed. They are swatting flies
instead of removing the rotting carcass from the room. They have had a
share of good ideas.

Peter

Aug 31 '07 #11

P: n/a
On 22 Aug, 00:16, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

[snip]
Obfuscating javascript source code is absolutely optional, and
it has drawbacks including questionable effectiveness at addressing its
objectives, making post-obfuscation maintenance and debugging of the
code harder that it may have been otherwise and requiring that the
post-obfuscated code is fully QAed so that any problems that may have
been introduced by the obfuscation process can be identified.
[/snip]

Speaking as a reformed character, who has experimented with
obfuscation in the past, I would strongly support this statement, from
experience.

If one seeks to obfuscate large complex script files, the obfuscation
process can introduce a number of subtle problems which can also vary
from browser to browser.

These feel like a very small needle in a very large haystack, and it
would seem to me that to solve these problems requires the close
involvement of the program authors, to try to deduce how the
obfuscator could be effecting the program.

If you are lucky these problems show up as a syntax error - although,
if your code is all in one line, then an error which points to "char
237636 on line 1" is daunting, and the cause is rarely the character
pointed to.

If you are unlucky, then the problem will not produce a syntax error,
but will appear either as a mysterious runtime error at some point, or
worse, a program logic error, which you may never spot until it is too
late.

The only way I was able to even able to get my obfuscated code to run
was to adopt a layered approach, to trap errors:-

remove comments
test on target browsers
change "var" names
test on target browsers
change function argument names
test on target browsers
change other names
test on target browsers
remove line breaks
test on target browsers

But this was madness, a complete waste of resouce when I could be
spending my time writing, testing, debugging and maintaining my
original code. It is hard enough debugging the original code without
introducing a whole new layer of errors.

Julian

Aug 31 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.