I have been interested in security particularly vulnerabilities and exploit development for a number of years but I have never really put much effort past the "hackmes" with strcpy or something relatively trivial to find. I've even gone the script kiddie route and modified some PoC exploits [Not like that. I used to have a SPARCstation that I had long since forgotten the password too. I rooted it but I liked the flair of it so much that I continued to use a bindshell when I wanted to use it. We all have our moments. haha].

I am a little curious about the methodology employed by security researchers. I have used (and written to little success) fuzzers before and I have read fairly extensively on the subject but the actual process still remains a bit of a mystery to me. Is the field primary composed of people fuzzing a target and waiting until it breaks or is there more static analysis involved and, if so, does the static analysis consist of trolling every function of a binary for assessment?

The latter seems less likely but if so I am really curious as to the process by which one would approach a real world binary. This may provoke some flames but, after looking at some of the research and projects that are forwarded by this community, the fuzz-and-forget model seems to lack the "down and dirty" reversing that much of the popular online media seems to credit the researchers. I am almost sure that I'm missing something.

There's a lot of variation, but the more common approaches to finding new vulnerabilities are:

1. Automated fuzzing, then reverse engineering the target with the help of the crash dump to try to determine if it's exploitable and how to exploit it.
2. Source code review, if available.
3. Manual "fuzzing"/testing, followed by reverse engineering the target with the help of the crash dump to try to determine if it's exploitable and how to exploit it.

Manual reverse engineering of an entire binary in search for vulnerabilities is rarely done. (Though as Hex-Rays gets better it may be more common and approached as #2 above.)

And for a nice example of a high-level approach at finding vulnerabilities, check out https://media.blackhat.com/bh-us-10/whitepapers/Cerrudo/BlackHat-USA-2010-Cerrudo-Toke-Kidnapping's-Revenge-wp.pdf

Thanks for the article. There are so many tuts out there that are of the form: start here, ???, there's your solution. It's nice to catch something that shows a little methodology.

Fuzzing in and of itself is such a vast subject that I don't know if it will be worth trying to discuss in a forum but I do have some questions about them. What seems to be the most effective fuzzing strategy random data or smart fuzzing with selected strings? I could see how both would have some merit but I don't quite see how testing on a handful of parameters will cause such a large set of test cases. It seems that, within a few mutations, the usefulness of the fuzzer's outputs will deteriorate severely. In the case of a smarter fuzzer, what kind of tranformations should I be looking at?

I can see how runtime would vary greatly because of state explosion but how long should I expect it to run before I can reasonably conclude that my program won't shake anything out?

I would really like to sink my teeth into some real world exploitation but I guess I'm going try my hand at writing a fuzzer first. While I'm waiting for something interesting to happen, what kind of things could I do to brush up? I'm not really sure if there is any unique skill sets that I should work on so I don't get lost in a large binary.


I know this is a long post with very vague questions but so is the direction that I want to take. I'm just looking for some insight.

This is probably not the best site on which to ask those questions

Well, that's a shame.

Still continue to ask.. though the answers may not be 'found' or given all at 'once' stuff tends to happen over time.