Deobfuscating JavaScript and Shellcode: Debugging + Dedicated Tools – Part 2/2

Welcome to Part II of a two-part series on JavaScript and shellcode deobfuscation!

In our first video, we explored a few different methods to deobfuscate JavaScript. The first session resulted in a deobfuscated HTML page complete with malicious JavaScript. In this session, I cover how the malicious JavaScript works. Additionally, I debug the shellcode that is used in the exploit and explain how it works.

The following is a list of tools covered in this video:

First Section: JavaScript Review

Tool Name Author(s) Link Notes
js-beautify Lielmanis & Sanfilippo https://github.com/beautify-web/js-beautify Installed in REMnux: Simply run “js-beautify
SciTE Linares & Hodgson http://www.scintilla.org/SciTE.html A SCIntilla based text editor. Installed in REMnux: Simply run “notepad
SpiderMonkey Mozilla https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey Installed in REMnux: Simply run “js
vi Bill Joy et al. http://en.wikipedia.org/wiki/Vi While not technically a coreutil, vi is bundled with and/or is available for most *nix-based systems
REMnux Lenny Zeltser http://zeltser.com/remnux/ I used REMnux 5 under VMware Fusion in the video, but Oracle VirtualBox works great too


  • I used SciTE to review the deobfuscated JavaScript. REMnux has an alias to SciTE called notepad, which I used in the video. I could have used any number of text editors or code editors to view the code, but I simply used the primary code editor as included in REMnux. Feel free to use whatever you’re comfortable with when it comes to reviewing the JavaScript.

Second Section: Shellcode Debugging

Tool Name Author(s) Link Notes
OllyDbg 2.01 Oleh Yuschuk http://www.ollydbg.de/ A 32-bit disassembler and debugger for Windows


  • I used OllyDbg 2.01, but many people still use OllyDbg 1.10. Version 2 of OllyDbg is a complete re-write, and as such, the plug-in architecture was re-written. Since v1.x plug-ins are not compatible with v2.x, some people prefer to use the old version. Luckily, everything that we do in this series will work fine either version. Feel free to use whichever version you prefer.

OK, now that you have the links, check out the video!

I hope you all enjoyed the videos. I look forward to any and all feedback, so please do not hesitate to write a comment!

Thanks gang!

– 8bits0fbr@in


  1. justin says:

    Hello 8bits0fbr@in,

    Thanks for the awesome videos, tutorials and related info. Especially the deobfuscation technique and shellcode analysis parts. Super.
    I had a couple of doubts though. Hoping to clear them here.

    The quicktime code does not use the heapspray/nop memory string(0x0c0c0c0c) to trigger the epxloit.
    The win-zip and webviewfolder code uses the HS memory string to trigger the exploit.

    Hence don’t you think there are only 2 exploits? I was guessing the QT related code was added to provide some distraction to the user? Because even if it succeeds the next win zip exploit gets called.Please correct me if I am wrong.

    Also i believe the JS code attempts all the exploits in case it is not able to download and execute the binary. The code seems to be calling the next exploit whether or not the current one fails/succeeds:

    if (num = 255) setTimeout(“startOverflow(1)”, 2000);
    else startOverflow(1);

    if (num = 255)
    setTimeout(“startOverflow(2)”, 2000);

    else startOverflow(2);

    Am i right in my understanding?Could you please clarify?

    • 8bits0fbr@in says:

      Hiya Justin! Thanks for the comment! Sorry I took a few days to respond. [Reasons go here.]

      To begin, the QT exploit does call makeSlide(), so we know that the code is attempting to fill memory with the exploit code (which utilizes the `0x0c0c0c0c` string). While we do not have the actual QT code, as we did not get qt.php in our sample, we have no way of knowing what the actual QT “movie” was intended to do. We can see that QT was vulnerable around this time: https://www.kb.cert.org/vuls/id/659761 (x-reference the CLASSID). My initial assumption was that the QT movie loaded simply led to a crash, which would potentially trigger the exploit that makeSlide() provides.

      Next, you are correct in that the code calls all exploits, regardless of the success rate with each step. In fact, the JS code uses setTimeout() with a secondary argument of 2000, which translates to two (2) seconds. Thus, the code provides a 2-second buffer to call the next exploit if the current exploit “succeeds.” By “succeeds,” I mean that the try statement does not move to the except portion of code.

      Notice that the startOverflow() function contains a try/catch block, the try portion of which ends in `num = 255` for both the QT and WinZip exploits. If this value is set, the code waits two (2) seconds before calling the next exploit. Otherwise, the next exploit is called right away. So yes, the code does attempt all exploits regardless of success rate.

      Hope this helps! Thanks again for the comment!

      • justin says:

        Hey 8bits0fbr@in,

        Ok, I get it now. QT exploit did the payload spraying by calling makeSlide(). But to trigger the exploit either the crash or qt.php would have been the way to go. It makes sense now. The PHP code could have helped complete the analysis.

        Thanks for clarifying my second query too.
        Again, awesome work!!

Leave a Reply

Your email address will not be published. Required fields are marked *

Today is Monday