Before you get started, do keep in mind that when using a debugger, you *will* be executing potentially harmful malicious code so take the necessary precautions!
Microsoft Script Debugger is free and can be obtained here . To activate the debugger, you first need to enable script debugging in Internet Explorer by making sure both of the “script debugging” options are unchecked.
Here we have an actual malicious script.
Launch IE and ensure you set the “Break at Next Statement” from the “Script Debugger” menu item before running the script.
Script Debugger will then launch and you should see something like this.
Step through the code until you get to the very end but don’t let it get past this point yet. While you are here, you can enter the value “hTNiNQic” in the “Command Window” and you can see what’s being stored.
When you step through (by clicking on Debug > Step Into), another window will appear. This are the results of the eval in the code which is the second layer of obfuscated code.
Again, have it go through to the very end but stop it before the last step. This time enter “uXGJZXGp” and you’ll see what’s there.
Step through once again and the final eval will be deobfuscated.
You can now copy the code from this third window since this is the final deobfuscated code.
Let’s now have a look at Microsoft Script Editor. You need Microsoft Office 2003 (or 2000) but you don’t have to install the entire suite. Choose the custom install and disable everything except for the following:
We’ll use the same malicious script and activate Script Editor the same way as described above. You should see the following when the program loads.
Just go to the very end of the script and just before the last statement, place your cursor in front, right-click and select “Run to Cursor”.
At this point, the Script Editor will stop just before performing the eval. In the “Immediate” window, you can enter variables to see what is being stored in there.
Step through the eval and Script Editor opens another instance.
Once again, go to the very end, place your cursor in front of the last statement, and run to the cursor once again.
A third instance should open and you should now see the final rendered deobfuscated code.
IE8 Developer Tools
Go the end of the script and just before the last step, insert a breakpoint by right-clicking and selecting the option from the context menu.
When you run through the code, the debugger will stop before proceeding. What’s cool about this tool is that all the local variables are enumerated and populated as the code runs. Go ahead and click on the “Locals” tab and see the values stored in all the variables.
When you step through, another set of undefined variables will show up in the “Locals” tab.
Add another breakpoint before the last step.
Finally, the script is deobfuscated!
This is probably the best tool out of the three.
There are a few things to consider before using any one of these tools. First and foremost, you will be executing potentially malicious code so protect your PC by using the tools in a VM.
Secondly, these tools only work with IE. Some scripts could be written to have a different behavior if running in Firefox or Chrome. Most of the time, IE is the preferred platform but keep this in mind anyway.
Not all scripts will be deobfuscated this easily. You may have to figure things out along the way such as where to insert breakpoints, clearing cookies, stitching sections together, etc.
Aside from the disadvantages, it can be useful to use a debugger. Take, for example, this code (I deliberately used conditional compilation so this would look tricky). If you were to *quickly* run through this in your head, what would you think the alert box say?
If you said “one”, you would be wrong. It would pop up with “two”. It’s an easy mistake to make if you looked at this very quickly or was too tired, etc. A debugger might help in tricky situations like this. Incidentally, if you run this code using Firefox, a “three” would popup so be sure to remember point two above.