8

I myself am a static analysis guy; I mostly gave up dynamic reverse engineering ten years ago. So these days, my process is usually to locate where my input enters the module that I am interested in, and then perform heavy static analysis to determine how my input manipulates the state of the program. I have found some neat bugs such as information disclosure this way; however, I am undoubtedly a lot slower than my counterparts who employ a lot of dynamic analysis and dynamic input generation (e.g., randomized fuzzing).

What steps do you usually take to discover vulnerabilities in closed-source programs?

Improve this question
1
  • 3
    This sounds very much like a poll, which generally doesn't go over well on StackExchange sites.
    – JMcAfreak
    Mar 27, 2013 at 18:46

1 Answer 1

Reset to default
6

This is how I typically do it, although it largely depends on the target/project and it's only how I like to do it myself:

  • Start (probably dumb) fuzzing the application as soon as you have the target.
  • Meanwhile, statically analyse the application in order to understand how it works and, maybe, to find low hanging fruit vulnerabilities.
  • Try to understand if you can make any smarter your fuzzer once you have enough structures and functions discovered in IDA.
  • If you have a hit in your fuzzer, discover the root cause of the problem and if it could be exploitable. If it isn't, nevertheless, it's worth checking in deep the area where the crash happened as that crash is a probable indicator of an interesting area to focus on.
  • If you have a hit while doing static analysis, try to write a simple trigger for it.
  • Focus on the part where the bug exists to continue statically analysing.
  • Once you have 1 true vulnerability found via either by fuzzing or statically analysis, write rules/scripts to find similar vulnerabilities.
  • Possibly write an exploit for it and go back to 2.
  • When tired of finding such vulnerabilities and after understanding the inner workings of the application, try to find logical flaws.

PS: Reading documentation is also a good way to find some vulnerabilities, as well as reading change logs, diff patches, commit messages, etc... if you have access to source code (sometimes you can have partial access to the target's source code, even for closed source applications).

Just my 2 cents.

Improve this answer
2
  • could you elaborate a bit more on "write rules/scripts to find similar vulnerabilities". Say you found a vulnerability through fuzzing what kind of rules are you going to write? Do you mean something like limiting the parameter input search space for your fuzzer or?
    – ixje
    Mar 28, 2013 at 6:54
  • I mean creating rules/scripts for finding similar patterns to the code where you found a vulnerability, in the binary code. It's very probably that there will be more vulns/bugs similar to the one you found. Although not a vulnerability, this can give an example.
    – joxeankoret
    Mar 28, 2013 at 8:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.