Obfuscate Javascript

[twigster]

Hey everyone,

I'm looking for a good way to obfuscate some Javascript code. Does
anyone have a good experience or bad experience with a particular software?

thanks

[Evertjan.]

twigster wrote on 17 aug 2006 in comp.lang.javascript:

I'm looking for a good way to obfuscate some Javascript code. Does
anyone have a good experience or bad experience with a particular
software?

Read the NG'a archive. This Q is asked every week or so.

.... and you will come to the inevitable conclusion
that the need for clientside obfuscation is nonsense.

[... and that that for serverside obfuscation is too.]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[MB]

I'm looking for a good way to obfuscate some Javascript code. Does anyone

have a good experience or bad experience with a particular software?

Not really a obfuscator, but you could try a beta version of my Javascript
Cruncher which offers REAL compression of javascript files. Obfuscation
comes as a "side effect" of this compression.

http://www.fanskap.se/crunch

[Yanick]

twigster wrote :

Hey everyone,

I'm looking for a good way to obfuscate some Javascript code. Does
anyone have a good experience or bad experience with a particular software?

thanks

Follow this link :

http://dean.edwards.name/weblog/2005/02/packer2-beta/

Note : ALL your commands/blocks should be ended with a ';' , or it
might result in syntax errors. For example :

var foo = function(e) {
var i = 0;
switch (e) {
case 0:
if ( e == i ) {
sayHello();
};
break;
};
};

function sayHello() {
alert( "hello" );
};

[Yanick]

};
(forgot the last ending brace... :) but you get the idea !)

[Richard Cornford]

MB wrote:

>I'm looking for a good way to obfuscate some Javascript code.
Does anyone have a good experience or bad experience with
a particular software?

Not really a obfuscator, but you could try a beta version of my
Javascript Cruncher which offers REAL compression of javascript
files. Obfuscation comes as a "side effect" of this compression.

http://www.fanskap.se/crunch

Wouldn't it have been a good idea to test that a little before
proposing that anyone use it? As it stands the use of - eval - to
generate the actual 'executable' javascript inside an anonymous
function called as a constructor leaves any global function
declarations and global variable declarations in the original code
defining inner functions and f unction local variables. As a result
they are all inaccessible from the global scope, and will be invisible
to, for example, intrinsic event handlers defined in the HTML, or code
in other script files, or code in separate SCRIPT elements.

However, as an obfuscator it suffers from the usual problem that the
code that expands the data into javascript source code is provided in
the resulting file, and can then easily be used to recover the original
code (with the usual re-formatting courtesy of Mozilla/Gecko browsers).

Richard.

[MB]

Wouldn't it have been a good idea to test that a little before

proposing that anyone use it? As it stands the use of - eval - to
generate the actual 'executable' javascript inside an anonymous
function called as a constructor leaves any global function
declarations and global variable declarations in the original code
defining inner functions and f unction local variables. As a result
they are all inaccessible from the global scope, and will be invisible
to, for example, intrinsic event handlers defined in the HTML, or code
in other script files, or code in separate SCRIPT elements.

However, as an obfuscator it suffers from the usual problem that the
code that expands the data into javascript source code is provided in
the resulting file, and can then easily be used to recover the original
code (with the usual re-formatting courtesy of Mozilla/Gecko browsers).

As I said, it's a beta version and by that I mean "not finished". It will
have various options for how the decrunched data is made available to the
browser, etc.

Second, it is not intended to "protect" the javascript code in any way. It's
intended to make it smaller. The "obfuscation" is, as I said in the first
post, a "side effect". It is not the intent with the cruncher.

Everybody should know that protecting javascript is not possible. Take
programs like HTML guardian for example. You pay money for a false sense of
security. No matter how much you obfuscate or encrypt your javascript, if
the browser can run the code, you can also view it. The bottom line is, the
browser runs the decryption code, then has the decrypted code in a variable,
then makes it available to the document by using document.write() or eval().
Try this (tested in IE): Make a bookmark in your browser. As a URL, paste in
this:
javascript:void(document.body.innerText=document.d ocumentElement.innerHTML)
Now go to http://www.protware.com and then their demonstration page. Now
click that bookmark and you'll see the document body replaced by the
encrypted source and further down the decrypted source in plain view. So
much for protection.

You can never be safe, but you can at least save some bandwith by crunching.

[Paul]

twigster wrote:

Hey everyone,

I'm looking for a good way to obfuscate some Javascript code. Does
anyone have a good experience or bad experience with a particular software?

thanks

Interesting question since in my experience most js programmers start
off with obfuscated code. ;-)
though not js specific, this makes a good read
http://mindprod.com/jgloss/unmain.html

[Randy Webb]

MB said the following on 8/17/2006 10:01 AM:

Try this (tested in IE): Make a bookmark in your browser. As a URL, paste in
this:
javascript:void(document.body.innerText=document.d ocumentElement.innerHTML)

I prefer this one better:

javascript:'<code><ol><li>'+(document.documentElem ent||document.body).outerHTML.replace(/&/g,"&amp;").replace(/</g,"&lt;").replace(/%20%20/g,"&nbsp;%20").replace(/(\n\r?|\r)/g,"<li>")+'<\/ol><\/code>';

Now go to http://www.protware.com and then their demonstration page. Now
click that bookmark and you'll see the document body replaced by the
encrypted source and further down the decrypted source in plain view. So
much for protection.

You can never be safe, but you can at least save some bandwith by crunching.

There are better ways than "crunching".

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Blue Apricot]

twigster wrote:

Hey everyone,

I'm looking for a good way to obfuscate some Javascript code. Does
anyone have a good experience or bad experience with a particular software?

thanks

See the one at

http://www.jasob.com/

which is a commerical product and will cost money after the evaluation
runs out. I am not affiliated with this company, but I do believe the
product is worth the money.

I use it routinely to compress big JS files into relatively small ones.
(I am more interested in the "compression" than "obfuscation", but the
two are closely related.)

Blue Apricot

[Richard Cornford]

MB wrote:

>Wouldn't it have been a good idea to test that a little
before proposing that anyone use it? ...

As I said, it's a beta version and by that I mean "not finished".

<snip>

That is not what is usually meant by a beta. A beta should be working,
in the broadest sense, while your code is taking functional javascript
and breaking it, so not even basically functional.

Second, it is not intended to "protect" the javascript code

<snip>

It doesn't even obfuscate, as only the white space and comments are
lost in the translation.

Incidentally, is your 'compression' of javascript source better then
the zip compression that is a common (and expected) part of
transmission over HTTP 1.1? As your 'compression' diminishes the
repetition that zip works well with, the combined effect of your
modifications followed by zip compression may be worse than the outcome
of the zip compression alone.

Richard.

[Val Polyakh]

It *is* possible to obfuscate JS. The fact of viewing code does not mean
that you can *understand* it ;)
Try http://trickyscripter.com to see what I mean.

*** Sent via Developersdex http://www.developersdex.com ***

[Randy Webb]

Val Polyakh said the following on 8/24/2006 2:18 PM:

Please quote what you are replying to.

It *is* possible to obfuscate JS.

And nobody has said you couldn't.

The fact of viewing code does not mean
that you can *understand* it ;)

And just because *you* can't understand it doesn't mean it can't be
understood.

Try http://trickyscripter.com to see what I mean.

And then come back and ask why it doesn't work.

Get a better newsreader.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Lasse Reichstein Nielsen]

Val Polyakh <sc********@gmail.comwrites:

It *is* possible to obfuscate JS.

Absolutely. The big questions is whether there is ever any advantage
to doing it.

Anybody who can, and will, actually use the script you are obfuscation
is likely to be able to deobfuscate it too, and obfuscation is wasted
on everybody else (while still increasing the workload and complexity
at your end)

The fact of viewing code does not mean that you can *understand* it
;)

With some of the scripts people write, it seems that even writing code
doesn't mean that you understand it :)

Try http://trickyscripter.com to see what I mean.

The BigInt example isn't very readable code to begin with, so simply
stripping comments does wonders to obfuscate :)

It seems that that is all this "obfuscation" does, though, so one might
as well use JSMin: <URL:http://javascript.crockford.com/jsmin.html>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[pamelafluente]

Probably the effectivenes of the obfuscation depends also on the skill
of the reader.

To me, even plain source code is (still) obscure enough :)

I have seen some of these obfuscated stuff and it's really unreadable
(to me), unless you have some ages to waste doing search/replace, etc
....

To understand that stuff requires very high skills, and I guess who has
them, does not need at all to de-obfuscate other people code :) right?

just my 2 newbie cents

-Pam

Lasse Reichstein Nielsen ha scritto:

Val Polyakh <sc********@gmail.comwrites:

It *is* possible to obfuscate JS.

Absolutely. The big questions is whether there is ever any advantage
to doing it.

Anybody who can, and will, actually use the script you are obfuscation
is likely to be able to deobfuscate it too, and obfuscation is wasted
on everybody else (while still increasing the workload and complexity
at your end)

The fact of viewing code does not mean that you can *understand* it
;)

With some of the scripts people write, it seems that even writing code
doesn't mean that you understand it :)

Try http://trickyscripter.com to see what I mean.

The BigInt example isn't very readable code to begin with, so simply
stripping comments does wonders to obfuscate :)

It seems that that is all this "obfuscation" does, though, so one might
as well use JSMin: <URL:http://javascript.crockford.com/jsmin.html>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[scriptguru]

It *is* possible to obfuscate JS.

>
Absolutely. The big questions is whether there is ever any advantage
to doing it.

Actually the advantages seems to be pretty simple:
- smaller script size/faster download (2x-3x)
- it is really hard to steal, use and edit your code

The BigInt example isn't very readable code to begin with, so simply
stripping comments does wonders to obfuscate :)

It seems that that is all this "obfuscation" does, though, so one might
as well use JSMin: <URL:http://javascript.crockford.com/jsmin.html>

Douglas wrote very good thing. It is small, it is fast.
TrickyScripter is slower, but it will replace loacal variables and
function names. It can determine automaticaly is it safe to obfuscate
vars or not.
Also it makes some other changes - just read the first page of site
http://trickyscripter.com

[scriptguru]

The fact of viewing code does not mean
that you can *understand* it ;)

And just because *you* can't understand it doesn't mean it can't be
understood.

Oh, I see ;)
Actually it is possible to understand *any* code.
It is true, but if it is cheaper to write own software rather than
steal my or your app - than obfuscation is successful.

Try http://trickyscripter.com to see what I mean.

And then come back and ask why it doesn't work.

Please tell my why it doesn't work?! :)
You really find any bug or just want to talk?

Get a better newsreader.

Oh, I have no newsreader :-]

Randy

Val

[Richard Cornford]

sc********@gmail.com wrote:

>>It *is* possible to obfuscate JS.

Absolutely. The big questions is whether there is ever any advantage
to doing it.

Actually the advantages seems to be pretty simple:
- smaller script size/faster download (2x-3x)

Smaller script size is not an advantage of itself (for development
clear readable code is most desirable). So without an advantage for
download speed size reductions can be counter productive. As HTTP 1.1
requires UAs and Servers to support the zip compression of broadcast
resources (and they do in reality) download speed will be closely
related to the size of resource post-compression. Any action taken to
reduce javascript source size is likely to be removing some of the
repletion that zip takes advantage of, so the post zip compressed
result may even be larger than just zip compressing the original
source, and the result slower downloads in reality. Previous
discussions of this subject have suggested that generally removing
comments is the only advantageous action as even white space removal
can reduce zip compression efficiency.

- it is really hard to steal, use and edit your code

<snip>

Making it difficult for you to edit your own code is hardly
advantageous. How hard code is to steal depends entirely upon the
person doing the stealing. A moderately skilled javascript author will
be able to extract the actual executable code from any obfuscation
method, and re-format it to well structured (properly indented) source
code. That only really leaves the obscurity of the Identifiers used,
which is hardly much of a barrier to stealing code else most
non-English speaking javascript programmers would not be able to
understand 99% of existing examples.

So, the "hard to steal" only applies to people who don't know
javascript at all (who are not going to be stealing it anyway) and
people who have only just started to grasp the basics of javascript
(and they will not necessarily stay in that state for long).

Richard.

[scriptguru]

Richard Cornford напи�ав:

sc********@gmail.com wrote:

>It *is* possible to obfuscate JS.

Absolutely. The big questions is whether there is ever any advantage
to doing it.

Actually the advantages seems to be pretty simple:
- smaller script size/faster download (2x-3x)

Smaller script size is not an advantage of itself (for development
clear readable code is most desirable)

Are you kidding? 8-)
Nobody obfuscates the *source* code. Only published code have to be
obfuscated.

>Any action taken to
reduce javascript source size is likely to be removing some of the
repletion that zip takes advantage of, so the post zip compressed
result may even be larger than just zip compressing the original
source, and the result slower downloads in reality.

Nope, you wrong. If local variables in all the functions have equal
names then zip comression would be better. If spaces and comments are
removed then zip compression would be better.
Etc. If you want I can show you statistics: how some script can be
archived before and after obfuscation.
Remember, there is big difference between code optimizer/obfuscator
(like TrickyScripter) and code comressor (like Packer form Dean
Edwards). In both cases code seems to be obfuscated, but in first case
it cant be deobfuscated and compresses with zip/compress/deflate
perfectly, and in second case the code can me easily deobfuscated and
cant be compressed using zip/compress/deflate.

Making it difficult for you to edit your own code is hardly
advantageous. How hard code is to steal depends entirely upon the
person doing the stealing. A moderately skilled javascript author will
be able to extract the actual executable code from any obfuscation
method, and re-format it to well structured (properly indented) source
code.

How many time do you need to fully understand obfuscated code?
Maybe it is faster to write your own? ;)

>That only really leaves the obscurity of the Identifiers used,
which is hardly much of a barrier to stealing code else most
non-English speaking javascript programmers would not be able to
understand 99% of existing examples.

And non programmers would not be able to understand 99.9% of existing
examples ;)

So, the "hard to steal" only applies to people who don't know
javascript at all (who are not going to be stealing it anyway) and
people who have only just started to grasp the basics of javascript
(and they will not necessarily stay in that state for long).

If it is not a "Open window" script but something much more complex
(like TinyMCE or Bindows) then it will be EXTREMELY hard to maintain or
just edit obfuscated code. Just try and you'll see what I mean. Sure in
case if obfuscation is not just whitespace and commets stripping.

Val

[Randy Webb]

sc********@gmail.com said the following on 9/1/2006 6:58 AM:

>>The fact of viewing code does not mean
that you can *understand* it ;)

And just because *you* can't understand it doesn't mean it can't be
understood.

Oh, I see ;)
Actually it is possible to understand *any* code.
It is true, but if it is cheaper to write own software rather than
steal my or your app - than obfuscation is successful.

I am not going to have the "obfuscation can be successful" argument.
It's old news and not worth rehashing. It comes up about every year or
so when somebody new writes an obfuscater and wants to advertise it to
make money.

>

>>Try http://trickyscripter.com to see what I mean.

And then come back and ask why it doesn't work.

Please tell my why it doesn't work?! :)

First, the errors on the page. After a script error, anything that
happens after that is pure guess work.

Sidenote: That little gold box doesn't line up properly onmouseover in IE7.

You really find any bug or just want to talk?

Depends on what you call a bug. It took me less than 10 minutes to get
valid, readable, comprehensible code from any of the examples. Thats not
a true bug but when a product doesn't do what it advertises, thats a bug
to me.

Although I did find the Texas Holdem Odds Calculator neat but it is
extremely bloated for everything it uses to do it.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[scriptguru]

I am not going to have the "obfuscation can be successful" argument.

It's old news and not worth rehashing. It comes up about every year or
so when somebody new writes an obfuscater and wants to advertise it to
make money.

It is almost 100% true. I saw many many code crunchers, compressors,
optimizers etc.
w3compiler, jasob, Packer, jsmin, HTMLZip, HTMLCompact, the list can be
really long.
I've tried EVERY one. I just was needed to make some script smaller.
But all that stuff somtimes break the code or need time for
decompression (like HTMLZip). I've considered to write tool for myself.
It was a long way, but now it seems to be best and only one optimizer
which uses proper principles. It uses code modeling and can
automaticaly determine many things. There is no settings at all! Then I
considered to make it public.
About many money and ads. Maybe you noticed that every one can use my
tool completaly for free - trial version is fully functional and have
*no time limit*. Paying for it is a kind of donation.

>Try http://trickyscripter.com to see what I mean.
And then come back and ask why it doesn't work.

Please tell my why it doesn't work?! :)

First, the errors on the page. After a script error, anything that
happens after that is pure guess work.
Sidenote: That little gold box doesn't line up properly onmouseover in IE7.

I've fixed several bugs already. Maybe there is still any bugs. But if
anybody (and even not my customer who have tech support) reports a bug
I fix it quickly. With help of some sceptic people I've found several
errors, now it works much better and that sceptic guys are not so
sceptic now.
If some script in "examples" alerts error try to run original
non-optimized version - it will alert exactly the same error. Script
works exactly the same before and after obfuscation and it is normal.
If there was errors befor obfuscation then the same errors will be
after obfuscation.
If there is really something wrong with IE7 after obfuscation and OK
before - please describe it more detailed.

You really find any bug or just want to talk?

Depends on what you call a bug. It took me less than 10 minutes to get
valid, readable, comprehensible code from any of the examples. Thats not
a true bug but when a product doesn't do what it advertises, thats a bug
to me.

The real purporse of TrickyScripter is to make scripts significaly
smaller. And it must not affect HTTP compression. The obfuscation is a
side effect. At the moment it is more effective than any other similar
tool. If not let me know.
Actually I do belive that you can restore *formatting* and make code
readable (there is tons of tools for this purporse). But I don't belive
that you can fasr get an clear understanding how each function work
because all functions have similar variables names: i,I,o,O etc. If we
have many functions in one bigger functions (this approach now used
relatively frequently) then even the inner functions will be renamed!
It is not quickly manage with code like this, but sure it is posible.
There is nothing impossible in the world ;) Any crypt can by decrypted
and any obfuscation can be deobfuscated. But peple still encrypt and
obfuscate, isn't it?

Although I did find the Texas Holdem Odds Calculator neat but it is
extremely bloated for everything it uses to do it.

All scripts used in my examples are written by different people. It was
not important for my how script works and what it is doing - important
was only size of scripts. I can put any script to examples, and if you
want to see something cool there - just give me the URL ;)
I'm always open for dialogue and I it is always interestiong to know
what other people think.

Val