Some fuzzers are blackbox while others are protocol aware. Even the ones that are made protocol aware, the fuzzer writer typically has to get the protocol specification and implement packet awareness logic in the fuzzer. Unfortunately, just because the fuzzer is protocol aware, it does not guarantee anything about the code coverage by the fuzzer. To make matters worse, what if we wish to attack a proprietary binary protocol with no protocol specification or source code access. Tools like AFL cannot come in handy because of we cannot compile the code, or give a function name to be monitored. There are other limitations like -- if we want to fuzz the 3rd packet in the protocol sequence, it is not possible with tools like AFL.
The presentation deals with this specific scenario where the target protocol is completely unknown (proprietary) and we do not have access to the source code or protocol specs. The tool we have developed builds a feedback loop between the client and the server components. The packet is then mutated optimally to increase the code coverage based on this feedback that the server component of our tool sends to the client component. The tool does not need target binary compilation and there is no need for the daemon to be restarted along with the feedback monitor. We fuzz using the runtime monitoring of the target daemon.
Looking forward to seeing you at the talk !!
