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:
Does the PoC actually work?
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).
Run the PoC
look at the call stack when there is a exception->follow them
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.