Tutorial 5 

Evaluating impossible:

Malzilla supports a very limited number of DOM objects.
If you are not familiar with DOM and interaction between browser and JavaScript, lets try to explain it in few words.
If you take a look at some JavaScript, you will probably see something like document.write().
In such example, document is an object provided by the browser.
That object provides method write.
So, our browser needs to deal with some objects, and these objects and their methods are accessed from JavaScript.
You can define any kind of objects and methods if you are developing a browser or any other kind of application that can be accessed from a JavaScript.

For browsers, there are standardized objects and methods - the HTML DOM:
http://www.w3schools.com/htmldom/default.aspBack to Malzilla. As you see, there is a really big number of objects and methods that need to be supported by a browser.
As I do not have such resources, nor enough time, I've implemented just most needed objects and methods into Malzilla.
Lately, there is a lot of malicious scripts that are using document.createElement() function, which is a really big task to implement.
As I would probably need a couple of years to implement it, we need another way around.
The real problem is the script written in a such way that the eval() function is needed to decipher first round, but it makes problem lately at second step, as it will try to evaluate document.createElement(), which is not supported.
Normally, if we have to deal with eval() function, we will either override it, or replace with some more friendly function for an analyst (alert(), document.write()...).
The mentioned tricky scripts can't be analyzed such way, as neither replacing or overriding would give you the next step in analysis.
Till now, we have used the debugger to monitor the state of variables at the moment of document.createElement() occurrence.
That gave us the links to malware, but not the script.
Well, previous week I found this interesting Didier Steven's blog:
http://blog.didierstevens.com/2007/08/07/a-second-spidermonkey-trick/
I got that idea long time ago too, but I'm (almost) C++ analphabet, so I didn't know how to do it myself.
After taking a look at the changes Didier made to SpiderMonkey (ver. 1.5), I did something similar to more recent version, and modified Malzilla to use it.
Now we can also see the tricky script in deciphered form, not just the debugger output.

Thanks Didier.

Example script that explores this behavior:



Test that script with both Malzilla 0.9.2.3 (pre3) and 0.9.2.4 (pre4), with Override eval and Replace eval, and test it with 0.9.2.4 without overriding or replacing (Leave as is option), and see what I mean.


Copyright (c) Bojan