Offensive Fuzzing

What problem it addresses

Static review and unit tests often only exercise explicit paths. Complex input surfaces such as parsers, network protocols, IPC, syscalls, and IOCTL handlers can still hide edge cases, memory errors, and state-dependent failures. This skill targets security testing and reliability validation, using fuzzing to generate abnormal inputs and surface crashes, hangs, undefined behavior, concurrency issues, and logic inconsistencies.

How the skill works

It turns fuzzing into a practical workflow: map target input surfaces and high-value areas, instrument and build the target, write a harness, prepare a seed corpus, then launch multiple fuzzer classes. The material covers BlackBox, GreyBox, Snapshot, WhiteBox, and Ensemble approaches, with tool choices such as AFL++, Honggfuzz, libFuzzer, Nyx, syzkaller, and LibAFL placed according to target type. Key steps include:
- Use afl-cmin and afl-tmin to reduce seed corpora and crash inputs
- Use CmpLog, dictionaries, AFLGo directed execution, or concolic assistance when progress stalls
- Choose oracles by bug class, such as ASan, HWASan, TSan, UBSan, KASAN, and KCFI
- Use specialized harnesses and analysis paths for kernels, EDR or Windows scanning engines, Rust, and embedded targets

It also covers crash triage and reproducibility: pin the CPU governor, record binary hashes, preserve input sequences, and treat ASLR disabling as a carefully bounded test action. This is useful for teams that can build C/C++, Rust, Go, Python, or kernel test environments and want to integrate fuzzing into continuous testing.