Another heuristic to consider.

[jdefrancesco]

So we use Cyclomatic Complexity and Loop detection. That's great but I think we when considering the attack surface to fuzz we might have better luck with coarse grain input tracing. That is. Looking for high level calls we know are used to open a user file or parse user input. For example. On a windows target like Adobe. We can run Dr Coverage with some trace input and simply track the path taken which will probably mean seeing calls to things like NtReadFile/CreateFile, etc.

When I was fuzzing Adobe Reader my approach generally included finding a library it loaded. Debugging it with windbg to see how the DLL boot straps and the primary calls it makes. I then am able to harness out that functionality.

Here is a great write up on the same exact process I pretty much use when using WinAFL: https://research.checkpoint.com/2018/50-adobe-cves-in-50-days/

I think if we combine that work flow with the other heuristics we can narrow down the type
Of harness we want to generate for fuzzing. Hi Cyclomatic complexity doesn't necessarily mean it's code that is often exercised. The primary challenge I faced for some
harnesses I had to create involved reversing objects or structs out. This is namely and issue with C++ code that doest export its symbols in a portable way... I would love to add some support for crafting data structures to some degree which we can pass to the functions or DLLs we fuzz.