Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20420 > unrolled thread

Javascript Obfuscator problem

Back to article view | Back to comp.lang.javascript

Contents

  Javascript Obfuscator problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-24 15:12 -0600
    Re: Javascript Obfuscator problem Stefan Weiss <krewecherl@gmail.com> - 2013-06-25 00:40 +0200
      Re: Javascript Obfuscator problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-25 08:51 -0600
        Re: Javascript Obfuscator problem Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-25 20:46 +0000
          Re: Javascript Obfuscator problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-25 15:23 -0600
            Re: Javascript Obfuscator problem Andrew Poulos <ap_prog@hotmail.com> - 2013-06-26 08:15 +1000
              Re: Javascript Obfuscator problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-26 17:45 -0600
                Re: Javascript Obfuscator problem Andrew Poulos <ap_prog@hotmail.com> - 2013-06-27 11:58 +1000
                  Re: Javascript Obfuscator problem "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-27 09:10 -0600
                    Re: Javascript Obfuscator problem Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-27 20:49 +0200
                      Re: Javascript Obfuscator problem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-27 21:38 +0200
    Re: Javascript Obfuscator problem "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-06-25 10:45 +0200

#20420 — Javascript Obfuscator problem

Hi:

    I was testing out the 'obfuscator' yesterday at 
www.javascriptobfuscator.com

    During my testing, the site 'failed to 'obfuscate' my lengthy JS code, 
and failed on the following lines (which I abstracted from about 600 lines):


****************************************************
pwidths = [31,68] ;
tables = [getobj("iclbtable")] ;
nlen = tables.length ;
for (i= 0;i < nlen;++i) {
   for (j=0,cells = tables[i].rows[0].cells,nlen2 = cells.length;j < 
nlen2;++j) {
      cells[j].style.width = "" + pwidths[j] + "%";
      }
   }

****************************************************

The error passed back to me is below

*******  error from javascriptobfuscate.com *********
JScriptCodeDom.CodeParseException: Unexcepted Token : Semicolon , Requires 
QuoteEnd , Line 5, Char 65 ---> System.Exception: Unexcepted Token : 
Semicolon , Requires QuoteEnd
   at JScriptCodeDom.CodeParser.ReadAndCheckToken(CodeTokenType equalto)
   at JScriptCodeDom.CodeParser.ContinueExpressionCore(CodeExpression 
leftexp)
   at JScriptCodeDom.CodeParser.ContinueExpression(CodeExpression leftexp)
   at JScriptCodeDom.CodeParser.ParseFullExpression(Boolean bthrowerror)
   at JScriptCodeDom.CodeParser.InternalParseStatementCore()
   at JScriptCodeDom.CodeParser.InternalParseStatement()
   at JScriptCodeDom.CodeParser.ParseStatement()
   at JScriptCodeDom.CodeParser.ParseToBlock(CodeBlock block)
   at JScriptCodeDom.CodeParser.ParseForStatement()
   at JScriptCodeDom.CodeParser.InternalParseStatementCore()
   at JScriptCodeDom.CodeParser.InternalParseStatement()
   at JScriptCodeDom.CodeParser.ParseStatement()
   at JScriptCodeDom.CodeParser.Parse(String code)
   --- End of inner exception stack trace ---
   at JScriptCodeDom.CodeParser.Parse(String code)
   at JScriptProtector.Protector.Protect(String[] codes)
   at JScriptProtector.Protector.Protect(String code)
   at Jsps._Default.Button1_Click(Object sender, EventArgs e)
***********************************************

I don't understand why there is an 'unexcepted'  (or does it mean 
'unexpected')  token at the end of line 5

Any guesses here (or is there an error my pea-brain can't find in that 
line ) ??

Thanks,

-- 
Mel Smith

[toc] | [next] | [standalone]

#20421

On 2013-06-24 23:12, Mel Smith wrote:
>     I was testing out the 'obfuscator' yesterday at 
> www.javascriptobfuscator.com
...
>    for (j=0,cells = tables[i].rows[0].cells,nlen2 = cells.length;j < 
> nlen2;++j) {

> *******  error from javascriptobfuscate.com *********
> JScriptCodeDom.CodeParseException: Unexcepted Token : Semicolon , Requires 
> QuoteEnd , Line 5, Char 65 ---> System.Exception: Unexcepted Token : 
> Semicolon , Requires QuoteEnd
>    at JScriptCodeDom.CodeParser.ReadAndCheckToken(CodeTokenType equalto)
...
>    at JScriptProtector.Protector.Protect(String[] codes)
>    at JScriptProtector.Protector.Protect(String code)
>    at Jsps._Default.Button1_Click(Object sender, EventArgs e)
> ***********************************************
> 
> I don't understand why there is an 'unexcepted'  (or does it mean 
> 'unexpected')  token at the end of line 5

I'm not familiar with the JScriptProtector and JScriptCodeDom classes; a
quick search on the web only shows other error messages like yours. My
guess is that this obfuscator is using a home-brew parser that can't
handle assignment lists as the first expression in |for|.

This will avoid the parser error:

    cells = tables[i].rows[0].cells;
    nlen2 = cells.length;
    for (j = 0; j < nlen2;++j) {  // ...

And so do obvious syntax errors:

    var f o o = 4 2;

(Result: "var _0x1d51=[];var f;o;o=4;21;")

> Any guesses here (or is there an error my pea-brain can't find in that 
> line ) ??

Your code is fine (assuming those variables are declared somewhere in
the original code). You can either change your source to make the
obfuscator happy, or use a different obfuscator.


That said, why are you even using an obfuscator? The only good reason
(for carefully selected values of "good") that comes to my mind is to
evade detection by security software. Every other use is misguided and
counter-productive, IMHO. This includes "I don't want other people to
see/copy my code without permission".


- stefan

[toc] | [prev] | [next] | [standalone]

#20431

Stefan said:

"> I'm not familiar with the JScriptProtector and JScriptCodeDom classes; a
> quick search on the web only shows other error messages like yours. My
> guess is that this obfuscator is using a home-brew parser that can't
> handle assignment lists as the first expression in |for|.
>
> This will avoid the parser error:
>
>    cells = tables[i].rows[0].cells;
>    nlen2 = cells.length;
>    for (j = 0; j < nlen2;++j) {  // ...
>
> And so do obvious syntax errors:
>
>    var f o o = 4 2;
>
> (Result: "var _0x1d51=[];var f;o;o=4;21;")
>
>> Any guesses here (or is there an error my pea-brain can't find in that
>> line ) ??
>
> Your code is fine (assuming those variables are declared somewhere in
> the original code). You can either change your source to make the
> obfuscator happy, or use a different obfuscator.

    Yes, the vrbls are of course defined higher-up. btw, I'm starting to 
deliberately use my own 'hoisting' techniques. But maybe that's not 
adviseable.

>
> That said, why are you even using an obfuscator? The only good reason
> (for carefully selected values of "good") that comes to my mind is to
> evade detection by security software. Every other use is misguided and
> counter-productive, IMHO. This includes "I don't want other people to
> see/copy my code without permission".

    I'm just on a 'learning exercise', and thinking of  perhaps obfuscating 
the data (in the internal tables) of my pages. This has nothing to do with 
JS, but, as I said, I'm just trying to get a bit of knowledge about 
obfuscation techniques for later in my development.  I'll be looking around 
(a few months from now) about how to encrypt table data, so that the client 
browser shows the info correctly, but the 'sniffer' of the table data has a 
difficult time de-obfuscating.

Thanks for the response.

-Mel

[toc] | [prev] | [next] | [standalone]

#20440

On Tue, 25 Jun 2013 08:51:09 -0600, Mel Smith wrote:

>     I'm just on a 'learning exercise', and thinking of  perhaps
>     obfuscating
> the data (in the internal tables) of my pages. This has nothing to do
> with JS, but, as I said, I'm just trying to get a bit of knowledge about
> obfuscation techniques for later in my development.  I'll be looking
> around (a few months from now) about how to encrypt table data, so that
> the client browser shows the info correctly, but the 'sniffer' of the
> table data has a difficult time de-obfuscating.

Anything that is genuinely worth the effort of obfuscating is worth the 
effort of cracking.

Furthermore, some people will, on detecting your obfuscation, simply 
crack it to see what you're hiding.

It is the very nature of the web that by using wget I can invariably get 
the raw data that a server sends, regardless of cookies, browser 
sniffing, ajax etc at the server.

Once I have the data, I can de-obfuscate it. Alternatively, I can use 
greasemonkey to write a script that walks the dom.

This is assuming that saving the whole web page or simply copying and 
pasting from the screen won't do the job.

You are wasting your time if you are trying to obfuscate data from the 
end user whose browser you are planning to deliver it to. If you need to 
protect it in transit, use https.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#20442

Denis said:

> Anything that is genuinely worth the effort of obfuscating is worth the
> effort of cracking.
>
> Furthermore, some people will, on detecting your obfuscation, simply
> crack it to see what you're hiding.
>
> It is the very nature of the web that by using wget I can invariably get
> the raw data that a server sends, regardless of cookies, browser
> sniffing, ajax etc at the server.
>
> Once I have the data, I can de-obfuscate it. Alternatively, I can use
> greasemonkey to write a script that walks the dom.
>
> This is assuming that saving the whole web page or simply copying and
> pasting from the screen won't do the job.
>
> You are wasting your time if you are trying to obfuscate data from the
> end user whose browser you are planning to deliver it to. If you need to
> protect it in transit, use https.


Hi Denis:

    I've been 'sniffing' programmatically since this past January digging 
into public web sites (to which I subscribe to and belong) that hold 
information I wish to collate and deliver to other users as a centralized 
fount of information, at the same time adding value to this public info on 
easy to read, centralized tables.  My data 'rows' now amount to 
approximately 19000+ rows of 5 columns of 'yummy' info.   These rows are 
spread among approx 67 different tables of up to 1400+ rows each -- some as 
little as ten rows.  In the process of these past six months, I have 
cleaned, and re-cleaned and programmatically corrected much of the faulty 
public information, standardized terms, standardized formats, etc, etc

    I would like to offer this new set of info to the public *free*. But, if 
it is not obscured in some fashion (thru encrypting, obfuscating, etc), then 
some *other* 'sniffer' is going to come along and take a day or so to 'lap 
up' all my hard work, and then offer it at a price.  *That* would really 
choke me up !

    So, I'd like to make that harder to do by 'obfuscating' somehow.

    Since the info is all hard textual. I thought maybe of encrypting it, 
then doing 'something' at the client browser end to de-encrypt the tables 
(thru obfuscated JS) and display in clear -- and somehow make the 'sniffer' 
work a little harder.

    But, as you note,  it would be a small task for someone with expertise 
to de-obfuscate.

Thanks.

-Mel
 

[toc] | [prev] | [next] | [standalone]

#20443

On 26/06/2013 7:23 AM, Mel Smith wrote:
> Denis said:
>
>> Anything that is genuinely worth the effort of obfuscating is worth the
>> effort of cracking.
>>
>> Furthermore, some people will, on detecting your obfuscation, simply
>> crack it to see what you're hiding.
>>
>> It is the very nature of the web that by using wget I can invariably get
>> the raw data that a server sends, regardless of cookies, browser
>> sniffing, ajax etc at the server.
>>
>> Once I have the data, I can de-obfuscate it. Alternatively, I can use
>> greasemonkey to write a script that walks the dom.
>>
>> This is assuming that saving the whole web page or simply copying and
>> pasting from the screen won't do the job.
>>
>> You are wasting your time if you are trying to obfuscate data from the
>> end user whose browser you are planning to deliver it to. If you need to
>> protect it in transit, use https.
>
> Hi Denis:
>
>      I've been 'sniffing' programmatically since this past January digging
> into public web sites (to which I subscribe to and belong) that hold
> information I wish to collate and deliver to other users as a centralized
> fount of information, at the same time adding value to this public info on
> easy to read, centralized tables.  My data 'rows' now amount to
> approximately 19000+ rows of 5 columns of 'yummy' info.   These rows are
> spread among approx 67 different tables of up to 1400+ rows each -- some as
> little as ten rows.  In the process of these past six months, I have
> cleaned, and re-cleaned and programmatically corrected much of the faulty
> public information, standardized terms, standardized formats, etc, etc
>
>      I would like to offer this new set of info to the public *free*. But, if
> it is not obscured in some fashion (thru encrypting, obfuscating, etc), then
> some *other* 'sniffer' is going to come along and take a day or so to 'lap
> up' all my hard work, and then offer it at a price.  *That* would really
> choke me up !

If you intend to give away someone else's content for free then why do 
you want to continue to make a claim on it (how can you even make a 
claim on it)?

Do the websites you subscribe to know that you have been 'lapping up' 
their content for redistribution?

Why do you assume that people are waiting to on-sell the content you are 
'lapping up'?

1.4K+ row tables sound ridiculous, as far as usability is concerned.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#20462

Andrew said:


> If you intend to give away someone else's content for free then why do you 
> want to continue to make a claim on it (how can you even make a claim on 
> it)?

    I make no claim on it at all, I'm siumply reading it and re-formatting 
it for ease of use -- and its public info asnd publically available at many 
other locations.

>
> Do the websites you subscribe to know that you have been 'lapping up' 
> their content for redistribution?
>
    They provide their content freely to everyone.  and they  will be 
provided with *my* database shortly -- for free

> Why do you assume that people are waiting to on-sell the content you are 
> 'lapping up'?

    I don't 'assume' it -- I'm just wary that it might occur.
>
> 1.4K+ row tables sound ridiculous, as far as usability is concerned.

    Another judgement from you with insufficient knowledge for same.

-Mel


-Mel

[toc] | [prev] | [next] | [standalone]

#20463

On 27/06/2013 9:45 AM, Mel Smith wrote:
> Andrew said:
>
>
>> If you intend to give away someone else's content for free then why do you
>> want to continue to make a claim on it (how can you even make a claim on
>> it)?
>
>      I make no claim on it at all, I'm siumply reading it and re-formatting
> it for ease of use -- and its public info asnd publically available at many
> other locations.

Then why do you want to obfuscate it if not to reinforce some claim to it?

>> Do the websites you subscribe to know that you have been 'lapping up'
>> their content for redistribution?
>>
>      They provide their content freely to everyone.  and they  will be
> provided with *my* database shortly -- for free

So your answer to my question is "no".

>> Why do you assume that people are waiting to on-sell the content you are
>> 'lapping up'?
>
>      I don't 'assume' it -- I'm just wary that it might occur.

If you didn't assume that people would why do you guard against it?

>> 1.4K+ row tables sound ridiculous, as far as usability is concerned.
>
>      Another judgement from you with insufficient knowledge for same.

I said that they *sound* ridiculous not that they *are* ridiculous. If 
each table row was 22 pixels high that equates to a table that's over 
30,000 pixels high.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#20473

Here are my final words on this thread:


<!-- Obfuscated by www.www.javascriptobfuscate.com --><script 
language="javascript" type="text/javascript">var 
O10='==wOpkSZwF2YzV2XoUGchN2cl5WdoUGdpJ3duQnbl1Wdj9GZ7kyTxkEKkxWaoNEZuVGcwFmLxEDbKsTXwsVKnQWYlh2JoUWbh50ZhRVeCNHduVWblxWR0V2ZuQnbl1Wdj9GZg0DIxEDbgIXY2pwOpwkUV5CduVWb1N2bkhCduVmbvBXbvNUSSVVZk92YuV2Kn0DbyVnJnsSKyVmcyVmZlJnL05WZtV3YvRGK05WZu9Gct92QJJVVlR2bj5WZrcSPmVmcmcyKns2b9MmczRXZn9zLt92YuUGdhN2c1ZmYvRHcpJ3YzFmdhpmL3d3dukGch9yL6AHd0h2Jg0DIjJ3cu8UMJpwOpcCdwlmcjN3JoQnbl1WZsVUZ0FWZyNmL05WZtV3YvRGI9AyTxkEIyFmd7cSRzUCdwlmcjN3LDNTJwITJEdTJwITJwITJwITJBBTJEBTJCNTJwITJ5ITJEVTJpJUNlM3bsV3bwFGMyUyKwITJyITJzlGMyUydlJHZuFkMyUCOyUCdyVGbhBjMlAjMlAjMlEEMlQEMlQWZ0F2YzVnZi9GMyUSZiBjMlwGbldHMyUSeh1GMyUyLvAjMlAjMlAjMlEEMlQEMlQXYoRHMyUCduVWbt92YwITJhBjMlMXawITJzlGaUBjMl8yLwITJwITJwITJBBTJEBTJCdTJwITJ5ITJrsSaCNTJ2M0MlkmQzUCMENTJpBjMlIXY2hjMlAjMlI3bmFEMlQEMlAjMlEEMlQEMlI0MlAjMlQUNlIjMlMGdlJjMlMkMlIjMlcmbpxGZlVmbyITJDJTJyITJlRWdyJjMlMkMlIjMlUGdpx2bw1WayITJDJTJyITJkV2c1ZmbvNmMyUiMyUSeydmbhJjMlIUNlAjMlQ0MlAjMlM3bsV3bwFGMyUichZXQwUCRwUSRzUCdwlmcjN3QzUyJ9UGchN2cl9FIyFmd';var 
_0x84de=["ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=","","charAt","indexOf","fromCharCode","length"];function 
O0l(data){var _1lIlOI=_0x84de[0];var 
o1,o2,o3,h1,h2,h3,h4,bits,i=0,enc=_0x84de[1];do{h1=_1lIlOI[_0x84de[3]](data[_0x84de[2]](i++));h2=_1lIlOI[_0x84de[3]](data[_0x84de[2]](i++));h3=_1lIlOI[_0x84de[3]](data[_0x84de[2]](i++));h4=_1lIlOI[_0x84de[3]](data[_0x84de[2]](i++));bits=h1<<18|h2<<12|h3<<6|h4;o1=bits>>16&0xff;o2=bits>>8&0xff;o3=bits&0xff;if(h3==64){enc+=String[_0x84de[4]](o1);} 
else {if(h4==64){enc+=String[_0x84de[4]](o1,o2);} else 
{enc+=String[_0x84de[4]](o1,o2,o3);} ;} ;} while(i<data[_0x84de[5]]);;return 
enc;} ;function _1lI(string){var 
ret=_0x84de[1],i=0;for(i=string[_0x84de[5]]-1;i>=0;i--){ret+=string[_0x84de[2]](i);} 
;return ret;} ;eval(O0l(_1lI(O10)));</script>


-Mel

[toc] | [prev] | [next] | [standalone]

#20475

Mel Smith wrote:
> <!-- Obfuscated by www.www.javascriptobfuscate.com --><script 

Are you aware that they send a request telling them document.referrer
and document.URL.  Knowing document.URL may be necessary for checking
the license, but why do they want to know document.referrer?

Anyway, at least this kind of obfuscation seems pretty useless, as one
can see the unobfuscated code in the developer tools of a browser and
copy it from there.

You may read <http://jibbering.com/faq/#hideSource>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#20476

Christoph Michael Becker wrote:

> Mel Smith wrote:
>> <!-- Obfuscated by www.www.javascriptobfuscate.com --><script
> 
> Are you aware that they send a request telling them document.referrer
> and document.URL.  Knowing document.URL may be necessary for checking
> the license, but why do they want to know document.referrer?
> 
> Anyway, at least this kind of obfuscation seems pretty useless, as one
> can see the unobfuscated code in the developer tools of a browser and
> copy it from there.

Apropos: The Chrome Dev Tools have a “Pretty Print” feature that can be 
toggled with the “{ }” button on the bottom of the Sources tab.  Makes 
debugging easier.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#20429

Mel Smith wrote on 24 jun 2013 in comp.lang.javascript:

> I don't understand why there is an 'unexcepted'  (or does it mean 
> 'unexpected')  token at the end of line 5
> 
> Any guesses here (or is there an error my pea-brain can't find in that 
> line ) ??


"unexcepted" can also mean "unalterable",
<http://www.merriam-webster.com/dictionary/unexcepted>
and since the prime method of obfuscation is alteration,
it is quite clear that a dedicated obfuscator should object. 

It ain't necessarily so. 
[Ira Gershwin, 1935]

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web