Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Javascript decoding round-up - SANS Internet Storm Center SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms:

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Javascript decoding round-up

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 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, cesarean 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.

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).

...and before you write in to ask: Yes, concrete examples on how to use the four methods above will follow later today :)


385 Posts
ISC Handler
Feb 17th 2007

Sign Up for Free or Log In to start participating in the conversation!