Competent fuzzers don't just use random bytes, they systematically explore the state-space of the target program. If there's a crash state to be found by feeding in a file full of null bytes, it's probably going to be found quickly.

A fun example is that if you point AFL at a JPEG parser, it will eventually "learn" to produce valid JPEG files as test cases, without ever having been told what JPEG file is supposed to look like. https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-th...

AFL is really "magical". It finds bugs very quickly and with little effort on our part except to leave it running and look at the results occasionally. We use it to fuzz test a variety of file formats and network interfaces, including QEMU image parsing, nbdkit, libnbd, hivex. We also use clang's libfuzzer with QEMU which is another good fuzzing solution. There's really no excuse for CrowdStrike not to have been using fuzzing.

In my limited experience, I thought any serious fuzzing program does test for all "standard" patters like only null bytes, empty strings, etc...

The files in question has a magic number is "0xAAAAAAAA" so it is not possible that the file was all zeros.

Instrumented fuzzing (like AFL and friends) tweaks the input to traverse unseen code paths in the target, so they're super quick to find stuff like "heyyyyy, nobody is actually checking if this offset is in bounds before loading from that address".

No, it wasn't. Crowdstrike denied it had to do with zeros in the files.

At this point I wouldn't be paying too much attention to what Crowdstrike is saying.

Have to speak the truth albeit at minimum, in case legal...

Which also explains why they, only if needed to cover their back legally, confirm or deny details being shared on social and mass media.

Possible? Yes. Likely? No.

No, it wasn’t all zeros: https://x.com/patrickwardle/status/1814782404583936170