Blog
Tapping into the Opera JavaScript Interpreter
09.21.2007 - 2:28 PMPrevious Posts
September 2007| 09/28/2007 | AV Killer Analysis Report » |
| 09/26/2007 | Storm Worm Chronology » |
| 09/24/2007 | K.I.S.S. Principle » |
| 09/21/2007 | Tapping into the Opera JavaScript Interpreter » |
| 09/19/2007 | The Malware That Keeps On Giving » |
| 09/13/2007 | Phast Phlux Phishing » |
| 09/05/2007 | Tapping into the IE 7 JavaScript Interpreter » |
+ August 2007
+ July 2007
+ June 2007
+ May 2007
+ April 2007
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
Post a Comment:







