Javascript Compressor

Hi,

First of all thank you for the script: it works very well and is very effective! :)
But I have a problem: I lost the uncompressed version of a file js. (problem backup). I need to make a change. Do you have a solution? Thank you in advance for your reply.
Good day

I found some packed code on some site and I wanted to unpack it, so I made this.  It works well enough for me and most of the code that come out is valid.  Maby this could be add to javascriptcompressor.

Hi again Matthew, it looks good and seems to work very well. I'll copy your code to JavascriptCompressor and add a contribution link to your webpage.

Cheers!

Thank you so much for the packer!! and well done for the unpacker, which is neat, indeed.

HOWEVER, you need to be careful about inline regular expressions containing a semi-colon in the pattern, because the unpacker seems to insert a carriage return after the semi-colon, in the middle of the regular expression!

Example:

Initial statement:

   while(x = y.match( /(&#([0-9]+);)/ ))

packs into something like :

1Z(f=u.f(/(&#([0-9]+);)/))

and then the unpacker gives:

    while(x = y.match(/(&#([0-9]+);

    )/))

Notice the extraneous line-feed after the semi-colon. This causes trouble interpreting the RegExp at run-time.

Regards.

I was trying to work that out and not add new lines between (), But a new javascript style is to do :

(function () {

//code here

})();

So that can not work.  But most of the code is valid and running the code through FireFox with Firebug, it is easy to find errors in the code and fix.

matthewfl:

I found some packed code on some site and I wanted to unpack it, so I made this.  It works well enough for me and most of the code that come out is valid.  Maby this could be add to javascriptcompressor.

i appreciate the contribution of your unpacker but haven't you think for a second that releasing it to the public can make the js packer lost its relevance?  so whats the point of having a compressor if it has a decrypter... sir  i suggest that you hide the link of your unpacker for the sake of everyone thx

Zherow, I think you have missed completely the point of this packer, and of JavaScript as it happens.

Firstly: this packer, as its name suggests, is a packer, not explicitly an obfuscator. There is a big difference. The packer helps reduce the size of some code, by stripping out blanks and comments, and happens to make the resulting source difficult to read, but it does not alter the symbol names. An obfuscator would indeed help in deflating the source, but it would more particularly mangle the names of variables and functions. Besides, an obfuscator needs some smart input, in order to work properly: the developer must specify the external symbols (the names of the variables and functions that must not be changed because they are accessed from outside the obfuscated script).

Second: we are talking JavaScript here, it is not compiled, and it cannot be encrypted. No matter how hard to read, the script will eventually be evaluated in plain explicit text by the browser...

...which means that, by using the proper tools (Firebug in FireFox for instance) or by placing the appropriate alert( ) call instead of the very last eval( ) call, you will read the real code (albeit mangeld/obfuscated, but still, it's some JavaScript and you can debug it and view the variables' contents etc.).

Again, there is no way to prevent anyone to read and/or reuse some JavaScript. If you want to protect your code, don't do JavaScript.

Gabriel.

Most web developers when seeing the packer code could think to replace the eval with an alert.  The big think that make it different from just replace the eval with alert is that it trys to add new lines and tab the code according.  So that way the code is easier to read for the programer.  As long as there is no new line the code is valid.

matthewfl:

Most web developers when seeing the packer code could think to replace the eval with an alert.  The big think that make it different from just replace the eval with alert is that it trys to add new lines and tab the code according.  So that way the code is easier to read for the programer.  As long as there is no new line the code is valid.

Yes that is true.  And that is good for 1-5 kb of javascript but any more and that would be really hard to read as one line of code.  And fixing about 1-5 errors is not that hard for what the system dose for you.