[WEB SECURITY] JavaScript Obfuscators

Sophia Sun sophiasfq at gmail.com
Sun Jan 25 19:41:39 EST 2009


You are right that eventually any obfuscated JavaScript code must be
interpreted and run by a JavaScript engine in a browser. However, automatic
dynamic analysis of JavaScript code might incur too much performance
overhead. If static analysis is the only affordable option, obfuscation is a
problem that needs to be dealt with.

A few obfuscation techniques that I am aware of are: character encodings,
randomization of variable names and function names, string manipulations
such as string reversion, use of ternary operators, replacement of numbers
with arithmetic expressions, inserting comments, newline characters and
NOPs, code shuffling, code nesting, and encryption. But it seems to me that
few JavaScript obfuscators use encryption routines.

Code morphing in hackvertor is interesting. Thank you, gaz!

--Sophia

On Sun, Jan 25, 2009 at 2:12 AM, Eric Rachner <eric at rachner.us> wrote:

>  The short answer is that no obfuscator can be so powerful as to really
> confuse the Javascript parser of any browser with which it is intended to be
> compatible.
>
>
>
> At the end of the day, a (de)obfuscator must present code to the browser au
> natural, or it won't run.  Personally, I won't spend time writing utilities
> to attack individual obfuscators because I know that every obfuscator must
> eventually stop pretending to be clever and pass a blob of plaintext
> javascript to the host browser for interpretation.  If I want to know what's
> going on, I can just hook/inspect whatever is given the browser.
>
>
>
> In my opinion, the only real reason to care about the behavior of a given
> obfuscator is academic: sometime's it's interesting to guess at whatever the
> malware author might be thinking.
>
>
>
> - Eric
>
>
>
> *From:* Sophia Sun [mailto:sophiasfq at gmail.com]
> *Sent:* Saturday, January 24, 2009 8:09 PM
> *To:* James Landis
> *Cc:* websecurity at webappsec.org
> *Subject:* Re: [WEB SECURITY] JavaScript Obfuscators
>
>
>
> Thanks for pointing out the ambiguity, James.
>
>
> I'm interested in examining how obfuscated a piece of JavaScript code can
> be. Both commercial and open-source obfuscators for JavaScript only (static
> JavaScript "compiler") are of interest to me. I would like to know what
> kinds of obfuscation techniques are being used in an obfuscator, such as the
> randomization of variable names and function names and code shuffling.
>
> I agree with you that client-side code manipulation provides no real
> security value. But think about obfuscation from a web administer's
> standpoint, a highly obfuscated piece of JavaScript code could possibly
> delay the detection of a payload. Take XSS worms for example, it seems to me
> that most of them are obfuscated. It would be nice to know what obfuscation
> techniques are commonly used in obfuscators and how powerful an obfuscator
> can be in obfuscating JavaScript code.
>
> --Sophia
>
> On Sat, Jan 24, 2009 at 6:10 PM, James Landis <elspood at gmail.com> wrote:
>
> More parameters please. Commercial or open-source? Do you want the
> obfuscated output or the obfuscator itself? JavaScript only or
> JavaScript + HTML? Dynamic server-side runtime obfuscators or static
> JavaScript "compilers"?
>
> As I'm sure you know this, given the fact that you explicitly use the
> word "obfuscator", but manipulation of client-side code provides no
> real security value beyond prevention of casual theft and reuse of
> code.
>
> -j
>
>
> On Sat, Jan 24, 2009 at 4:53 PM, Sophia Sun <sophiasfq at gmail.com> wrote:
> > I'm collecting JavaScript obfuscators for research purpose. Could any of
> you
> > name a few widely used ones? So far, I've tried Jsob and some free
> > JavaScript obfuscators. Thanks.
> >
> > --Sophia
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090125/e8c144eb/attachment.html>


More information about the websecurity mailing list