Blog

Tapping into the Opera JavaScript Interpreter

09.21.2007 - 2:28 PM
In our last blog we saw a neat way to decode javascript obfuscation by hooking mshtml!docuemnt.write of IE 7. If you didnt read our last blog here you can find it at http://www.websense.com/securitylabs/blog/blog.php?BlogID=142. This week we're going to do the same thing for the Opera web browser, and yes we going to do the same thing to Opera.

But why, do you ask? This is a good opportunity for us to use the new Immunity Debugger from ImmunitySec to show how we search and hook something when there are no symbols avilaible!

First we create a simple html page that contains a call to document.write

Second we need to find out which Opera module handles the parsing. To solve the problem we will use Process Explorer from sys-internals and we will you use the Thread tab to watch what threads are running and from which module.

From the analysis we can see that when opera parses our webpage a thread inside opera.dll gets executed

At this point we're pretty sure that the code gets handled by the opera.dll module. Our next step is to find the exact line of assembly inside opera.dll that handles document.write. There are alot of ways to go about soloving such problem, but today we will use the hit-trace feature of Immunity Debugger!

hit-trace overview (from documentaion)

"Hit trace gives you the possibility to check which parts of the code were executed and which not. The method implemented in Immunity Debugger is rather straightforward. It sets INT3 breakpoint on every command within the specified region. When breakpoint executes, Immunity Debugger removes it and marks command as hit. As each trace breakpoint executes only once, this method is very fast."

From reading this we see that we can use this feature to let us filter which region of memory gets executed and which does not. We also want to know how many times each region gets executed, because we are interested only in regions that are excuted once (since we are calling document.write only once).

To verify we have found the correct line of code, we repeat the same process again but this time with a web page that has 2 calls to document.write.

Once we found the correct code area, we set a breakpoint in the start of the memory area and exam the memory. Here you can see the result:

In our results we found that the function at 0x67A25D38 parses the document.write script and one of the function paramaters is an indirect pointer to UNCIODE String which is the sText string of document.write(sText). All we left to do is to hook it and intercept the pointer!

Tools

Process Explorer for Windows v11.0
http://www.microsoft.com/technet/sysinternals/Utilities/ProcessExplorer.mspx

Immunity Debugger
http://www.immunitysec.com/products-immdbg.shtml

Game 0ver

Bookmark This Post:

Post a Comment: