ISC's Four Methods of Decoding Javascript + 1

After reading CGISecurity today I was pointed to an article over at the ISC. It listed four methods of decoding javascript as illustrated in the following table.

Note: The table values are taken from Daniel Wesemann's ISC post

Method	Description	Pros	Cons
The Lazy Method	Edit your copy of the hostile HTML so that it only contains the necessary HTML headers and the Javascript you're interested in. Then hunt down all occurences of "document.write" and "eval" inside the Javascript and replace them with "alert". Copy the modified file onto a web server of yours, or to some other place from where you can easily open it with a web browser, which should make the decoded JavaScript appear inside one (or several) pop-up "alert" windows.	Quick and easy to accomplish	Usually only decodes one (the first) encoding stage. Don't be disappointed if you get the next level of gibberish in your alert pop-up.
The Tom Liston Method	The idea is that you replace occurences of eval(stringVal) and document.write(stringVal) with document.write("<textarea rows=50 cols=50>");document.write(txt); document.write("</textarea>");	Quick and easy to accomplish, and in case the textarea reveals another stage of encoded Javascript, this method allows for easy cut-and-paste to continue the decoding.	Careful with typos. If you have a typo in the leading textarea definition, the following "document.write(txt)" will go right to the browser, as it originally would have, and the exploit will execute.
The Perl-Fu Method	Try to make sense of the Javascript decoding routine, and then re-create it with a short code block in PERL.	Very easy and fast for use on the dumber encoding methods like XOR, Caesar ciphers (character permutations), etc. Also the "safest" method, as this approach alone does not actually execute the hostile code.	You have to speak Perl and be able to translate the Javascript decoding into Perl. Much too tedious an approach for very convoluted Javascript, or JavaScript codes using functions which are hard to translate into Perl (like the arguments.callee codes seen frequently in fall 2006)
The Monkey Wrench Method	Use the stand-alone Javascript interpreter "SpiderMonkey" to run the encoded Javascript block. Replace the document.write(txt) with print(txt) before doing so, SpiderMonkey doesn't have any document object by default.	Little hassle, good results, fast method to get around a hard "outer shell" of a Javascript block encoded multiple times, works well in combination with the Perl-Fu method.	Fails for Javascript code deliberately written to only uncompress on Internet Explorer.

First a few quibbles about the list. One the Perl-fu method is really about translating javascript into your language of choice. It's a bit difficult as it doesn't handle interaction with the DOM. The monkey wrench method has some trouble with browser specific interpreter issues such as handling subscript notation.

So my little addition to this for javascript is the use of firebug. Firebug in case you've missed it is a javascript dubugger in the form of a Firefox extension. This allows you to among other things set breakpoints and single step through javascript lines. The method breaks down like this:

1. Put the javascript in an HTML page, we'll call a test page


2. Modify the javascript to have a debugger statement at the start of the javascript.


3. Make sure firebug is enabled


4. Load the test page in Firefox


5. Now set breakpoints where you want and single step

Since I copied the pros and cons from the ISC list I figure I'd better contribute my own row for the firebug method.

Method	Description	Pros	Cons
Firebug Method	Adding a debugger statement to the start of the javascript, and then single step your way through the code setting break points to speed up the work. Stopping to examine the DOM. etc.	This allows you to examine the code for side effects like manipulating the dom. Gives you the power of a debugger.	Does not work with browser specific javascript except for Firefox. Can be slow if you just single step your way through.

For example if I have a sample file:

<html>
<script>
while(1){
 alert('fooo');
}

</script>
<body>

<body>
<html>

I can simply add a breakpoint before the alert call by adding the statement

<html>
<script>
while(1){
debugger;
alert('fooo');
}

</script>
<body>

<body>
<html>

This drops me into firebug at the debugger line. I can now single step my way through the code and inspect the DOM in the GUI.

For more information on using Firebug check out this video here