|
|
|
|
|
|
by wepple
3625 days ago
|
|
|
in general, have a poke around https://fuzzing.info/papers/ First, I think the next big step in fuzzing will actually be a complement to fuzzing - solving. AFL and friends can bitbang their way to massive code coverage, but can still fail on fairly simple testcases. Some recent research[1] by the authors of Angr[2] show that by pairing the brute-force coverage and exception discovery of a tool like AFL with constraint solving tools can really dig deep into a program, by actually solving the path to a given block of code. Microsoft's infamous SAGE fuzzer does this IIRC. Second, I think there are still massive oportunities for fuzzing closed-source programs, as well as programs with tricky state, such as browsers or network daemons. [1] https://www.internetsociety.org/sites/default/files/blogs-me... [2] http://angr.io |
|
|
The idea of pairwise testing is that individual features in a program are commonly tested, but combinations of them are often poorly tested. However, trying to test all features with each other soon becomes a combinatorial nightmare. To deal with this, you use an algorithm (e.g. see the code for 'allpairs' at http://www.satisfice.com/tools.shtml ) to pick a minimal set of test cases that cover all possible pairs of configuration settings.
These test cases could then be used as starting points for fuzzing, to provide a greater code coverage faster.