5

My daily job is analyzing reported proof of concept files that exploits document viewers. People who report vulnerabilities in document viewers just give me the PoC and vulnerable version number. They usually fuzz stuff and find offset that leads to stack overflows etc. Which means they do not give me info about the root cause of the vuln. So only with the vulnerable binary and the PoC, I need to analyze following things:

  1. Does the PoC actually work?

  2. In which part of the binary is vulnerable? (ex. no argument checking in function A ... blah blah; I need to know this because I have to contact the vendor to fix the vuln)

I am new to this field and currently this is how I do it(I analyze in XP).

  1. Run the PoC

  2. look at the call stack when there is a exception->follow them

  3. Check whether SEH is corrupted -> set breakpoint on the corrupted SEH to find the instruction that overflows the stack

By playing around I can find the assembly instruction that triggers the exploit. However, it is hard to backtrack all the way to the root cause. Assembly instruction that overflows is usually in the library but the vuln is not the library, it is the user program that maliciously called the library right?

I don't know if I made my point clear but need some tips doing this kind of reverse engineering.

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
Jaewon Min
  • 329
  • 1
  • 10
  • I'ld use memory/hardware breakpoints, or look for repeating patterns in the buffer values, to track back to the root problem. Btw in the POC code you see how the value is inputted, so you should be able to determine where to look from that. – Dominik Antal Jan 17 '14 at 06:15
  • Thanks for the reply. I should make one thing clear, POC is a document file( ex .doc files) so there is no code that inputs value :( I just open it inside the viewer – Jaewon Min Jan 17 '14 at 08:05
  • 2
    Don't assume that a working exploit will always cause an exception to be thrown :) – Jason Geffner Jan 20 '14 at 14:20

1 Answers1

2

First, your platform is very important ( mine is Windows )

In Windows WinDbg + !exploitable is one of fast analyze options. it is here

Additionally I use WinDbg + !analyze to determine standard name of bug... it is default WinDbg extension.

Finally, as the nature of bugs is unknown (in your case) it is not an easy way to detect root cause.

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
sealed...
  • 291
  • 1
  • 8