[chc4]

I'm suspicious of the effectiveness. Most people are doing symbolic execution to find bad pointer dereferences as bugs, whereas this tool is doing it to build the least constrained model and then checking the code against that same model. Wouldn't any code paths that are discovered as part of symbolic exploration and have out-of-bounds read/writes then be infered away as constraints, instead of bugs? Or being unable to detect memory corruption in the form of controlled pointer value overwrites, since you can't say that all pointer dereferences derived from your symbolic input are bugs that allow for attacked controlled memory corruption, because you don't have a concept of what inputs are under user control unlike most uses of Angr or other symbolic tainting tools. Is there a better list of the types of bug classes or heuristics that this is able to catch? Are there any numbers on the false positive/false negative rates against a dataset?

[chc4]

Thinking about it more, a lot of bugs come around downstream of your initial function inputs, and you'd still be able to catch things like "heap allocation and then out of bounds read from that allocation with an offset derived from input" just fine since your least-constrained model only infers for the inputs. That probably covers a lot of the normal use-cases for Angr plus automatically harnessing inputs to reach that, which sounds pretty useful

[thinkmoore]

Yes, that's a good way to think of it---we need to come up with a valid / reasonable context in which to explore the function at all, which will subsequently let us look for other bugs (like the divide by zero in the blog post).