Is this CRC-32, if not, what could it be?

Question

Edit: It turns out that this is a custom checksum algorithm, not a CRC-32. For the curious here is a snippet of C code calculating the 21 FF 1D E4 checksum in the below example.

I am working with some hex files that seem to be protected by a CRC-32 of sorts, but recalculating using the standard CRC-32 and other known parameters failed to produce a match.

All I know is, the data spans 116 bytes and four additional bytes for the checksum. I can produce tons of examples of message-key pairs, I just cannot find any relation between them.

I don't want to fill this post with hex dumps so I pasted a couple more here: http://mathb.in/12246.

11 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 21 FF 1D E4

Could this be a CRC-32 with some strange settings, or is it completely different? What would be a way to determine how the checksum is produced?

Update: I was able to make minute changes of 1 bit in the messages:

00000000000000000000000000000000000000000000000000000000, 32C9A1E6 
00000000000000000000000000000000000000000000000000000001, BD25904E 
00000000000000000000000000000000000000000000000000000002, B437A286
00000000000000000000000000000000000000000000000000000003, 8AB790EE
00000000000000000000000000000000000000000000000000000004, 2DDC3AEB
00000000000000000000000000000000000000000000000000000005, 208B3859 
00000000000000000000000000000000000000000000000000000006, 87E0925C 
00000000000000000000000000000000000000000000000000000007, E59391AE
00000000000000000000000000000000000000000000000000000008, B07292FC
00000000000000000000000000000000000000000000000000000009, 830EA655 

Changing anything without updating the checksum appropriately creates a message that is rejected.

If this cannot be a CRC-32 due to the superposition principle (exclusive-or check), would there be any way to perform an analysis to find any properties or patterns in pairs of message and checksums?

Answer 1

Assuming that you got the messages and check values correct in your linked examples, then it is not a CRC. For a CRC or any linear function over GF(2) of the message, it should be that if message 1 exclusive-or'ed with message 2 is equal to message 3 exclusive-or'ed with message 4, then the same should be true of the check values.

There is only one byte that differs in your messages. Since 45 ^ 4A == 43 ^ 4C, then the associated check values when exclusive-or'ed should also be equal. They are not.

If you did have a CRC, then you could use reveng to try to tease out the CRC parameters.