The opposite scenario, however, can be a problem as well. Suppose that our fuzzer is aware of the checksum and then modifies its fuzzed output data files so that the checksum is always valid. What happens now if there is a defect or security vulnerability in the checksum logic? This logic isn't being tested, as the fuzzer has implicitly assumed that it's always correct; this is an assumption that may not be valid. To put it in higher-level terms, by giving the fuzzer knowledge of the expected input, you're telling it to create input in the way that the program expects to receive it. The whole point of fuzzing, though, is to test the program by giving it unexpected input. This is the classic debate between "dumb" fuzzers that have no knowledge of the expected input format and "smart" fuzzers that do. The reality is that neither type is sufficient on its own and to achieve the best results, both types of fuzzers should be used to test the application.
If you haven't started already, I strongly suggest that you make fuzz testing part of your testing process. The material presented here doesn't even scratch the surface of the power and possibilities of fuzzing. If you're interested in learning more, I recommend reviewing the book Fuzzing: Brute Force Vulnerability Discovery by Michael Sutton, Adam Greene, and Pedram Amini.