Before we begin, here’s a couple words of caution! Always run Revelo in a virtual machine and disconnect the Internet just in case. Also, when doing a live analysis, remove object tags if you see them. While Revelo will block access to the Internet, external programs like Flash, Acrobat, Java, etc that are called upon by object tags won’t block access and your machine could get infected.
Here’s our very basic script. It takes a string of hex, converts it to text, then redirects you to Google:
To see what this is doing, paste the script into Revelo, making sure it’s surrounded with < script></script> tags. Click on the “Execute” button. Revelo will execute the code, show you what the script result is, then block its attempt to reach the Internet.
In order to see the final result without having it execute, we need to modify the request (options on the left). The last line of the script gives us a hint, “window.location.assign” followed by “url”. We can intercept that function so copy and paste it into the “Intercept Function with Name” textbox:
Click on the “Results” tab then click on “Execute” and you can see what the URL is:
Now let’s obfuscate the script further using some online tools…
Here’s the output:
We can see there are a bunch of hex code separated by commas. You can de-hex each array value to figure out what this does, however, just looking at the last line which starts with “window” should be suspicious to you. Since it looks like a function, we can intercept it and send it to a textbox. Copy the highlighted string over to the “Intercept Function with Name” option. What this does is catch the function and display the result without executing it.
Click on “Results” tab then click on “Execute”:
By the way, you don’t have to use Revelo for any of this. You can simply use Notepad.
Here’s the output which I pasted in Revelo. Since it starts with “eval”, we can use the “Redirect Eval to Action”. What this will do is change “eval” to “document.write” so it doesn’t execute the result.
And the result which is our original script:
At first glance, this one is a doozy! It seems to have converted the original script as Base64 then reversed it. At the very end, we see “eval” followed by some variables. Let’s try “Redirect Eval to Action”.
The result doesn’t look complete.
Cool, it works!
The creator of this script is brilliant! Not only is the obfuscation tricky, it looks cool. It’s logical + artistic. We’re gonna have to put our thinking caps on for this one!
At the end of the script, you see an “eval(x)” call. Let’s redirect the variable so enter “(x)” (including the parenthesis) to “Redirect Variable”. Revelo will display the value of the variable and not execute it.
On the “results” tab, we get the result, now copy that to the main tab. (I just pasted it in between the existing script tags.) We can see that it’s a function and does some funky math. We need some help here. If you go to the “Tools” tab, there’s a “Highlight Decryption Clues” button. Click on it. This highlights certain keywords that may be helpful to us.
The “y” variable is storing “i” which is a counter for the loop so that’s not important to us. The “fromCharCode” and “charCodeAt” tells us there is a conversion from decimal to text and that “o” is an accumulator of the result. Aha! If we look a little further, we can see that the result of “o” is returned to the caller of the function. Let’s peek into “o” so we need to intercept that. Type in “return” in the “Intercept Function with Name” field.
We get the result and paste that to the main tab. Looking at the code, it’s doing the same thing but this time it’s returning a substr of the result. Let’s use “return” one more time.
Wow, another layer of obfuscation! Again, we get the result and paste it to the main tab. Looks to be doing it again.
Finally, we get the deobfuscated result! It’s our script wrapped with document.writeln.
Hey, since it’s using document.writeln, we can do this:
And get the final result in one try:
Blackhole Exploit Kit
Now let’s try analyzing a real life obfuscated script. This one is from Blackhole’s landing page. You will notice that there are several sets of “script” tags.
If you paste the entire script in Revelo and execute it, you will have a problem! There’s an object tag hidden somewhere in the script that’s calling Java and it could result in your PC getting infected so remember to run everything in a VM. You can also disconnect from the Internet too if you wish to be even more safe.
The best way to analyze this is to do each script separately. Realize that some scripts will call other scripts or use variables from another script so we need to have some understanding of the code but this is the best way I know to handle this safely.
Let’s do the top portion first. (Note: I added “</body>” to close the open body tag which is up at the top.) We can see that the variable “a” holds the hex values at the top then it gets converted to HTML (e.g. “d.InnerHTML”) and finally appends itself to the body tag (e.g. “appendChild”). Let’s try the option “Replace InnerHTML with InnerText”. By converting this to text, we can see the HTML code but not have it rendered.
And the results show the call to a Java applet.
Now for the second part. The script at the top reads in the content of variable “dd”.
The bottom part shows the value of “dd” is “q” which is the ID of the span container. It also assigns “eval” to variable “zz”. If you follow the last script section, you’ll see that the variable “zz” gets assigned to “a” then the very last statement, “a(bq)”, is actually “eval(bq)”.
So we can either intercept function “a” or redirect variable “(bq)”. Either one works and the result will be the same. Note: The string “z0177, 0152…” is part of the span container and is not the result.
Here’s the deobfuscated script of Blackhole’s landing page.
You’ll find that many malicious scripts will be somewhat easy to deobfuscate. It’s really not worth it for exploit pack authors to spend a lot of time and energy making hard-to-decode scripts. All they need to do is change a simple script often. Look at Blackhole. One of the main reasons for its success is that the landing page script is constantly changing so by the time anti-virus and filtering products detect the script, it’s already updated to something else. And it’s not major changes, just small changes here and there. But that’s enough to get past security defenses.