public sealed class PacketReaderTargetThe packet reader, driven through every one of its reads.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
The input is two things, and the split is what makes this work. A quarter of it is a program — a byte per read, saying which read to do and with what cap — and the rest is the packet those reads walk over. Fuzzing the packet alone would only ever exercise the one sequence of reads the harness happened to hard-code, and it is the sequence that finds the bugs: a length read as a blob and then as a string, a raw read of a negative count after a failure has already stuck.
The caps are part of what is fuzzed. TryReadBlob and TryReadString take a maximum from the caller precisely because the length on the wire is not to be believed, so the program supplies wild ones — zero, huge, and negative. A negative cap is the interesting one: it converts to a uint larger than any length, so the check passes and the only thing left standing between the packet and an allocation is the bounds check on the buffer. That it is enough is a claim worth testing rather than reading.
Fields and properties (2)
public string NameWhat to call it on a command line and in a report.
public string WhatWhich receive path this is, in one line.
Methods (3)
public long AllowanceFor(int inputLength)How many bytes an input may cause to be allocated.
public void Seed(ICollection<byte[]> corpus)Adds well-formed inputs for the mutator to start from.
public long Run(ReadOnlySpan<byte> input)Pushes one input through the decoder.
Used by (1)
- FuzzTargetsVixen.Net.Fuzz