In the recent past, we've shown several methods on how to unravel obstinate JavaScript codes used to convey exploits. Here's a brief round-up of the methods we commonly use. All four methods require that you get a copy of the hostile page, preferably by use of a text-only HTML tool like wget, curl or similar (since you cannot easily download a Javascript exploit with a browser that speaks Javascript without also running the Javascript code at the same time).

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.

Pro: Quick and easy to accomplish
Con: 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
As explained eg. in https://isc2.sans.org/diary.html?storyid=1917. In your copy of the hostile page, hunt down all the "eval(txt)" and "document.write(txt)" function calls, and replace them with document.write("<textarea rows=50 cols=50>");document.write(txt); document.write("</textarea>"); Then again put the modified HTML onto some place from where you can open it with a web browser. The decoded JavaScript will show up inside a textarea panel.

Pro: 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.
Con: 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.

Pro: 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.
Con: 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.

Pro: 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.
Con: Fails for Javascript code deliberately written to only uncompress on Internet Explorer.

The Playground
To see the above four methods "in action" and try them out on your own, take a peek at my write-up on http://handlers.sans.org/dwesemann/decode/index.html

Caveat: For the first two methods mentioned, be mindful that you are actually running hostile code inside a potentially vulnerable web browser. Make sure to apply the usual precautions (VMWare or the like, deployed far away from any production network you might have, and keeping a keen eye on the firewall log, etc).