Jump to content
Tuts 4 You

Ollydbg: Opening a file and making the handle available to debugged pr


PaperBall

Recommended Posts

The situation:


 


I have a malicious Word document from which I have extracted the shellcode and loaded it in Ollydbg.


 


The shellcode  assumes it executes within a copy of Microsoft Word which has the malicious DOC file open.


 


The Shellcode will search for the DOC file by going over the list of open open file handles.


 


When it finds a possible match, it (or a part of it) is loaded into memory.


 


The shellcode then proceeds to decrypt the payload in memory etc etc ...


 


 


My question:


 


While debugging a program in Ollydbg, can I manually open a file so that the file handle becomes available to the debugged process?


 


also, is there a way to have the debugger execute my own commands, regardless of what the program code says?


i.e. could I manually open the file so that the filehandle becomes available to the debugged program?


 


Any other suggestions on how I could solve this problems would be appreciated.


 


Thanks,


 


        - Paper


Edited by PaperBall
Link to comment

I believe the best way to debug such exploits is by debugging shellcode directly inside Microsoft Word. There are lots of reasons, you already found one. Also, shellcode might rely on some MS Office DLLs that won't be loaded in your dummy application.


 


 



is there a way to have the debugger execute my own commands



 


You can assemble some code manually and then change EIP register to run your code. You can automate that with plugin like OdbgScript or MultiAsm which can assemble+run some code in the context of debugged program. Or you can inject your own DLL into debugged process using some Olly plugins (don't remember which one, though).


 


 



can I manually open a file so that the file handle becomes available to the debugged process?



 


Child process can inherit handles from parent processes. But I don't think Olly runs your debugged process with bInheritHandles = true. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx


 


 


Link to comment

I believe the best way to debug such exploits is by debugging shellcode directly inside Microsoft Word. There are lots of reasons, you already found one. Also, shellcode might rely on some MS Office DLLs that won't be loaded in your dummy application.

 

I agree that would be the optimal method.

Can you give me any hints on what I can break on?

  • Start Microsoft Word,
  • Start Ollydbg and attach to the Word process
  • Set breakpoints on ..??
  • Open the infected document in word?
  • Debug the Shellcode
  • etc ..?

Thanks ,

 

   - Paper

Link to comment

If you know which vulnerability is being exploited, you should know which piece of code is vulnerable - and put a breakpoint there.


If you don't know which vulnerability is being exploited, it's a bit harder. I'd start by putting breakpoints on ReadFile and similar functions. Then after Word loads malicious document, put HW on-access breakpoint on the part of the document which contains the exploit. Not sure it's the best way, though..


Link to comment

If you know which vulnerability is being exploited, you should know which piece of code is vulnerable - and put a breakpoint there.

If you don't know which vulnerability is being exploited, it's a bit harder. I'd start by putting breakpoints on ReadFile and similar functions. Then after Word loads malicious document, put HW on-access breakpoint on the part of the document which contains the exploit. Not sure it's the best way, though..

 

The vulnerability is "Bloodhound.Exploit.366" or CVE-2010-3333

I tried to attach to Word from Olly and load the file,   

I got a "Access violation" and Olly said it could not show me any code at EIP, (Cannot read memory)

 

Link to comment

or just change the shellcode to begin with EB FE, let Word run, and then attach.

The shellcode won't be able to continue until you allow it by restoring the bytes.

Link to comment

I finally managed to extract the payload with Ollydb, putting the EB FE instructions on the NOP sled and debugging the WinWord process.

Out fell  36 KB RAT.
 

This was a very fun and educative process, 

 

Thanks to both of you,  - PaperBall

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...