Deobfuscating JavaScript


A few months ago I read a post in the WebSense Security Labs blog: The Ultimate Deobfuscator. Wow, pretty impressive hacking effort and nice tricks to hook JavaScript eval() function and document.write() in Internet Explorer. But couldn’t you use JS Debugger hooks in Firefox to do the same thing with only a few lines of code? And then maybe even more generic because eval() and document.write() are certainly not the only ways to generate JavaScript code on the fly (out of the top of my head: changing window.location to a JavaScript URL, event handler attributes or setTimeout() with a string parameter).

Anyway, I finally took the time and actually wrote that Firefox extension: JavaScript Deobfuscator (source code). It adds a “Watch code execution” menu item to Tools menu, once checked all JavaScript compiled on a web page is posted as a message to Error Console. Nice side-effect: the JavaScript engine reformats the code to make it more readable. Downside: JavaScript performance goes down the drain, so using the browser with that option always switched on really isn’t recommendable.

The result is quite impressive with the obscure JavaScript code on the default Firefox home page. All the sudden you can see the functions executing there and it is possible to understand what they do. But that’s relatively little code of course, with something like GMail the code keeps coming so fast that it is impossible to keep track. Somebody want to create a better presentation for the data?

Categories: ,


  1. timendum

    Why don’t integrate Deobfuscating JavaScript with FireBug?

    Reply from Wladimir Palant:

    Yes, that would be something for a volunteer. I don’t use Firebug and all I needed was a proof of concept.

  2. Aerik

    Could this kind of thing lead to an extension to block the 3 kinds of scripts independently? Inline scripts written in the head, inline scripts written in the body, and linked scripts?

    Reply from Wladimir Palant:

    No, this is irrelevant for Adblock Plus – already because of the performance implications. But also because the debugging interface is purely informational, it cannot be used for blocking.

  3. z

    Reply from Wladimir Palant:

    Yes, I have seen it. But it won’t tell you what a live web site is running. You have to locate the code that you want to analyze (which can easily get extremely complicated), and then this code might have enough dependencies on the DOM that you will never see anything useful outside a browser. Not to mention that intercepting eval() and document.write() isn’t sufficient – something that I explained in just that blog post.

Commenting has expired for this article.

← Older Newer →