finding myself repeating "fuzzers are stochastic, with enough cpu time you will always find a bug, results are a usually demonstration of resources not algorithms"
like, hacking, along with spam and fraud are the sorts of activities where things only need to work 0.1% of the time to be successful
it isn't a demonstration of clever code or tooling but the uncompromising effectiveness of sheer brute force heh
@tef > with enough cpu time you will always find a bug, results are a usually demonstration of resources not algorithms"
I'm inclined to think that's largely a reflection of bad design (either of the program, tools or language).
If the program can enter invalid states, it supports logical operations to put it in such a state (unless you're fuzzing for hardware flaws, at which point the program is incidental and barely if at all related). That's bad design (or implementation thereof, it's quite possible to have a good design and screw up the coding part) unless it specifically must support arbitrary operations for its intended purpose.
Some languages make proper implementation of a design harder though, such that running fuzzers can be useful when for whatever reason proper semantics for the intended operation cannot be directly encoded. (The real solution is discontinuing use of those languages or use without tooling that provides such properties.)
tef
LisPi