0

the story looks like this: we have a browser, we have attached windbg to this browser, we have a fuzzing 'page'. now, when browser will crash (and i.e. I know that bug occurs somewhere in the HTML code), how can I find that code which crashed the browser? is there a way to find it during the windbg session? appreciated for any help.

iamlearning
  • 1

1 Answers1

2

A simple approach would be:

  1. Figure out how to crash it every time.
  2. Attach a debugger
  3. Break at the program entry point
  4. Continue until the program asks for input
  5. Provide input that would crash the program
  6. Step over each call (there shouldn't be too many), don't step into. One call will crash it. Put a breakpoint on it and run again, but this time step in. Step over each call again, until it crashes, then move your break point one level deeper, etc.

It shouldn't take too long for you to reach the bottom.

Also some debuggers can break just before (or after) the program crashes. If you can do that, then you can do it the other way around, start at the crash place and work your way up to find a reason.

valentinas
  • 1,048
  • 8
  • 10
  • valentinas: thanks for the answer. I mean the situation like for example you can find in gdb: there is a 'list' command. Can I do the same/similar thing (command) to check where the error occured in the code? Maybe it will be more useful for me than 'only asm' reading. What do you think about it? – iamlearning Aug 04 '14 at 00:38
  • Do you have the source code of the application? If so, then you can use an appropriate debugged to step through the code, instead of ASM. Same approach should work. I haven't used GDB, so won't be able to help in that area I'm afraid. – valentinas Aug 04 '14 at 00:52