Fuzzing TCP servers
Intro The architectures of software fuzzing setups that authors of security fuzzing tools had originally implemented were fairly simple. In early days of security fuzzing (before 2010) the vast majority of fuzzing engines were writing mangled content to disk files, and then instructed fuzzed binaries where to find them: $ honggfuzz -f INPUT_DIRECTORY -- /usr/bin/djpeg ___FILE___ Here, the placeholder (___FILE___ for honggfuzz, @@ for AFL) was supposed to be replaced by a name of a file holding the actual fuzzing content, and a fuzzed binary was re-executed continuously over supplied set of input files. When such fuzzed binary ( djpeg here) crashed, the input file that was believed to have caused this crash was copied into a crashdir directory under some new and fancy name, e.g.: SIGSEGV.PC.af0ef0.STACK.c7dc5c2c7.CODE.1.ADDR.0x8.INSTR.mov____0x8(%rcx),%rdi.fuzz or crash-50b12d37d6968a2cd9eb3665d158d9a2fb1f6e28 With continuous advancement of fuzzing techniques, even mor