Why, to smash the stack, of course.
It's perfectly obvious that all of these queries about needing to
include (seemingly) random sequences of bytes in code are about
"cracking/hacking/freeking/whatever-you-want-to-call-it" - let's not get
into that argument...
Not necessarily for evil purposes, mind you. It's worth the exercise
just to learn what all the fuss is about.
Not necessarily, indeed.
Suppose you found some C source code that computes a 32-bit CRC used
in a common communications protocol. You figured out a way to
implement the CRC calculation in a better way. And in order to verify
your code, you need some "random sequences of bytes" to test against
the C source code you found against your implementation.
Given that the C source code you found is correct, what better way to
verify your implementation than to test it on the binary data stored
in files by recursively reading these files in a given directory.
Of course the concept of a directory is not something specified by the
C Standard, but if there are compiler-specific functions that deal
with directories (as there are in Windows and Linux and Mac OS X),
then using such functions are a benefit rather than a hindrance for
the purposes of verification.
The test program is simple: recurs the directory and read each file in
binary mode and compute the CRC of the file using the C source code
you found and the C source code of your implementation. If the results
differ, output the path of the file. Then use your favorite debugger
to figure out the problem.
Sometimes you have to put on your software engineering hat in favor of
your C Standard hat. In response to that, some here may say "woe is
you for doing that"; perhaps there really is more to it than that and
perhaps they should really rethink their ways.