As already noted, one goal with the CRC algorithms is to make the byte ordering count, i.e. a file should be processed sequentially, unless you have a non-continuous, unsorted hex file and want to compute the resulting CRC when the hex file is loaded into the processor memory.

This makes CRC-16 or CRC-32 excellent for detection of corruption during transfers. But the strictly mathematical function of CRC means that it is very easy to "reverse-engineer" a CRC value.

If you have a large file, you can modify the file and still get the same CRC for the full file if you have access to two (CRC-16) or four (CRC-32) bytes after each other somewhere in the file, that you may also modify.

Putting up the equations and solve what value to place in the two (or four) bytes are easy and lightning quick. But even brute-force methods are possible since CRC-16 or CRC-32 are so small.

Because of this, you really should not make use of CRC-16 or CRC-32 to make sure that two file versions are identical. And CRC should not be used to verify that a *.exe file hasn't been virus-infected.

A hex file isn't likely to be virus-infected, but if you think about version control, you should still consider complementing the CRC value with more properties to avoid false matches. It may sound good that a new build has 1/65536 or 1/4294967296 chance of a collision with the previous version, but the birthday paradox means that you can quickly manage to get two builds with the same CRC.