While this tool does have some protections built into it, it may execute malicious code that could harm your computer so use it in a virtual machine. It’s been tested to run on Windows XP. There’s a helper document inside the zip file which includes safe samples to play with.
* Includes a built-in browser proxy which displays the URL of outgoing requests
* Displays the Document Object Model (DOM) elements
* Includes a packet sniffer which logs incoming and outgoing requests
* Includes a software firewall to prevent the program from accessing Internet content accidentally
* Ability to act as a web proxy to catch and block redirects
* Ability to clear the browser cookies
* Ability to spoof the user-agent string
Before I show you how this works on some live samples, I should tell you about one new thing I’m trying out. I like portable apps but my tool is not since it relies on several OCX controls. I wanted to virtualize it but VMWare ThinApp was not an option due to the high cost. After searching a bit, I found several other options:
After looking into each one and testing some of them out, I found Enigma Virtual Box to be the best for me. It’s flexible, has a small footprint, and it’s free! Caveat is that it may trigger AV.
Now onto the samples…
Here’s what we are trying to deobfuscate:
You can leave the options alone and just click on the “Execute” button. If it’s a redirect, you’ll see the URL pop up.
If you go to the “Traffic Detail” tab, you can see the GET requests made by the script. Because the program’s Internet Connectivity option (left panel) is set to “block”, the requests were dropped and never left your PC. Notice also that this script sets a cookie. If you don’t clear the cookie after each execute, the script may not do anything.
On the main tab, let’s scroll down to the bottom of the script. You can see there’s an eval call, a strange-looking call, and a likely variable.
Let’s use the “Intercept Function with Name” method and copy/paste that decodeURIComponent call then go to the “Results” tab. Cool…we just got the hex values of the deobfuscated script!
Let’s do one better. Let’s use the same method and copy/paste the eval call instead.
If you’re not getting the results you want or if you like to manually deobfuscate scripts then you can click on the “Unmodified Request” option and make manual changes to the script yourself like so:
DOM-based scripts, like this one, give a lot of tools headaches. What this tool does is enumerate the DOM objects and display what’s there.
Let’s just click on “Execute” so we can see if there’s a redirect:
Now let’s see the DOM elements so click on both of those tabs. Note: you may need to click on “Execute” twice to get the elements to populate.
Let’s analyze the script further. This code is messy so let’s beautify it. Click on “Beautify” then “Copy to Main”. You will have to fix the HTML code (e.g. script tags).
Scrolling down near the bottom, you’ll see “i.body.appendChild(B);”. Ah, so the results get attached to the body. Okay, let’s select the “Intercept DOM with Variable” method and type in “B”.
Now let’s have a look at the “Results” tab:
Here’s a live script that needs to be deobfuscated in two steps. We have to first deobfuscate the bottom half then tack that part to the first half to view the final script. You can see two distinctive parts of the script.
At the bottom of the script, we can see an eval. Let’s choose the “Redirect Eval to TextArea” method.
Nice, we deobfuscated the first part.
Let’s copy that over to the main tab and replace the bottom script with our newly deobfuscated code:
Hmmm, it’s not clear exactly what’s going on so let’s click on the “Highlight Decryption Clues” button. This highlights some key functions and more importantly, variable accumulators. Now we can follow what’s going on. Look at the variable “V3NsLL” and how it contains “eval” then becomes “xTlHf” and finally “X9DfwSP”. Ahh, so at the very bottom it looks like the variable “uXGJZXGp” is getting eval’d.
Let’s use the “Intercept Function with Name” and paste in “X9DfwSP” and go to the “Results” tab. We can see the deobfuscated source which is exploit code.
Last thing to mention is that the tool creates a temporary file called “~temp.html” which contains the original script plus its attempt to deobfuscate the code. You can have a look to see what it’s doing by opening this file in Notepad (do not open it with your browser directly since you will render the code without protection!).
Above is the code it used when we intercepted the function “X9DfwSP”. If it’s wrong, you can always copy and paste the fix over to the tool, make corrections, then click on the “Unmodified Request” option and check out the results.
There you go…I hope this tool helps you!
No warranties, program is made available as-is. Credits to: Eric Wolcott (firewall) and Michael D. (proxy).