Chirp does not modify the checksum in the .img file after editing and saving. The checksum is recomputed on the fly on upload, so it's not like the radio will see a bad checksum as a result, but there's info in the file as to whether it was likely edited.
Unless of course, the cable is bad... :)
BrickMaker.img checksums don't match. So there you go, and I think that increases the probability that it _is_ the bits. Still just guesses and probabilities...
If it _was_ right out of the radio, then that tells me that the data got corrupted between the radio and the computer (i.e. in the cable, USB adapter, etc). Sounds like we should make CHIRP check the checksum after a clone for at least that radio.
Some statistics: Of 248 .img files in the directories where I'm saving these, my tool says 21 checksums don't match. I did do some poking around in the Browser tool exploring the ability to modify bits. And some uploading to the radio to make sure the whole proposition of editing settings is feasible. And some of them might just be normal Memory channel edits. I didn't think I'd saved 21 edited files, but it's been almost two months, and that's what it looks like, unless I'm missing something.
...or the cable is silently corrupting data on the way in and this is the first time it has corrupted something that mattered.
If I were you, I'd modify the driver to check the checksum after download, and then do a bunch of downloads of a good radio with the original cable and see if they occasionally don't match.
--Dan