Obfuscated JavaScript – Oh What a Tangled Web

My colleague Daniel Novomeský alerted me to a problem he’s observed with the way some web-developers use JavaScript: a few of them have the habit of obfuscating JavaScript code on their web sites, presumably in order to compress it so that it takes less disk-space (“packing”) or using a “protector” in order to make it harder for a competitor to “steal” script code. The problem with this is that the use of this sort of utility to obfuscate code makes it harder for security software to identify known or unknown malware, so JavaScript is commonly obfuscated  by malware authors in order to evade or hamper detection.

I spy with my little eye

To the human eye, of course, there’s no dramatic difference between legitimate and malicious scripts if they’re obfuscated. An AV program might easily flag an “innocent” program as malicious because a technology normally associated with malware is being used.

The Greatest Good for the Greatest Number?

When the signature is throttled back so that the presence of the obfuscation software is not flagged as suspicious, it means that the interests of a few developers of  poorly-implemented web pages are given priority over the interests of the many people whose systems are threatened by the many sites that serve obfuscator-protected malware. Indeed, malware writers sometimes go out of their way to use “popular” obfuscators in hope they remain undetected, knowing that AV vendors try to avoid detecting legitimate websites, so, increasingly, the vendors are leaning towards a more Utilitarian approach.

The Unwise and Wherefores

Why, you might wonder, would you obfuscate a legitimate script? Well, one cryptor for which we have a specific detection is sometimes used by web developers because they think it gives them good copy protection and imperviousness to reverse engineering. Sadly, this is just giving them a sense of false security. An experienced JavaScript coder is unlikely to have any problem decoding the script to extract the original source code.

In fact, it’s possible for an anti-virus engine to decode a script in real time, in order to assess the malice or innocence of an object more reliably by examing the de-obfuscated script. However, this kind of in-depth analysis takes substantial time and resources, and most users would not regard the processing delay as acceptable.

Some obfuscators can also reduce the size of the JavaScript code, which might be another reason they’re used on legitimate sites. But there is actually a better method of reducing the bandwidth: the webserver can be enabled to use GZIP compression, so that HTTP responses will be compressed, and in fact, the compression ratio is much better this way than is the case with JS packers. However, using a JS packer and server side compression together may be worse from this point of view than using the original script with the server side compression only. As with compression in other contexts, compressing the same object twice or more does not make sense, and may actually result in increasing its size and time taken to load.

Trade(-off) Gap

Given this rich assortment of related problems, it’s hard to see how anyone could continue to recommend the use of protectors, since they don’t necessarily offer much to the developer in the way of protection against patching or reverse engineering to offset their disadvantages.

Pack It In!

As it happens, the IEEE Malware Working Group, of which ESET is a member, has been working for some time with some of the major packer companies on a system for making it possible to blacklist individual (mis)users of the software rather than the software itself. (Vendors with an approach based on whitelisting and/or reputation services may also find approach more useful.)

We hope that this will introduce some significant benefits to companies like Themida, to AV vendors, and (most importantly, some would say!) to the customer, whereas current piecemeal approaches to blacklisting and whitelisting have only limited, short-term effectiveness. Which is why, at present, AV vendors tend to favour a more generic approach that benefits the majority.

David Harley
Daniel Novomeský

Author David Harley, ESET

  • Alex

    I use a custom made javascript obduscator to protect my code.
    See for example:

  • Zack

    This is the stupidest thing I've read in months. You are hypocrites – this blog and your homepage uses minified javascript from varying files. ( you penalizing google and yahoo for using minified javascript? Or just small consumer website you haven't heard of.
    Minifying javascript is industry standard, recommended by Google, Yahoo and anyone else that doesn't have their heads up their asses.

    Get with the program and stop tormenting your users.

    • David Harley

      minification != obfuscation…

  • Ajnasz

    Noone cares about stealing the code, it will be only smaller and the result will be even better if you use gzip compression..
    For example, just removing the comments, what shouldn't be transferred at all can make the files much smaller..

    • David Harley

      I’m getting a little weary of hatemail. I won’t be approving any more comments that don’t make a sensible point in a reasonably polite manner.

  • TimTheTinker

    Are you referring to the Google Closure Compiler?

  • Robert Hurst

    Hello there.
    My name is Robert Hurst. I respect your desire to alert the pubic of the dangers that can be encountered on the web. I however feel that your atricle is in need of great revision, if nessisary at all.
    JavaScript is not a toy language. Its used by proffessionals to build complex applications both on the client and the server. That being said, a majority of JavaScript programmers are proffessionals that know what they are doing.
    Judging by your artice I'll asume that you do not program JavaScript profesionally. Obfiscation is to prevent end users, not programmers, from tampering with the code on runtime. However its not a method that is depended on for security.
    JavaScript is a language that will be very important in the years to come. I feel your artice misleads end users into thinking JavaScript is a bad thing, and that JavaScript programmers are not proffessionals.
    Next time you share an artice on a topic outside you area of skill, please do your reseach first. Because of your empoyer's reach into the public eye. you could very negitively effect the progress of an open web independent of plugins.
    Thank you for your time.
    – Robert Hurst

    • David Harley

      No-one said that JavaScript is a toy language, or attacked the professionalism of JavaScript programmers in general: that’s very different to pointing out a problem with a particular practice used by some programmers (actually the problem goes way beyond JavaScript, but this is an instance that hasn’t previously received much attention). Making negative assumptions about our competence on the strength of an imagined slight is not professional, and thanking me for my time doesn’t make it any less discourteous.

  • Russ

    Hi David & Daniel,
    Thanks for the article – I think you make the point quite well that there aren't many good reasons for legitimate Javascript to be obfuscated.
    I'm surprised by some of the venom you've received over what seems to be a straightforward and sensible article.

    • David Harley

      Hi, Russ. Thanks for that straightforward and sensible comment. :)

Follow us

Copyright © 2017 ESET, All Rights Reserved.