Trying to decipher a strange CRC algorithm I've encountered. Here's the most useful set of test vectors I've been able to generate:


fe80 0100 1001 = 228c
fe80 0200 1001 = 669b
fe80 0400 1001 = eeb6
fe80 0800 1001 = 2ec4
fe80 1000 1001 = 7e0b
fe80 2000 1001 = df96
fe80 4000 1001 = 4c84
fe80 8000 1001 = ba8b

For a usual CRC, you'd expect that a shift in one direction or the other of one of these, XORed with the next would give you zero (in the case where it was only a shift) or the CRC polynomial. And this *almost* works here, but not quite:

fe80 0100 1001 228c
2383 (prev<<1 xor next)
fe80 0200 1001 669b
2380 (close to 2380, but not quite)
fe80 0400 1001 eeb6
(1)f3a8 (way off, but note that the high bit of the above is set, so maybe this is the case where the bit rolls off and contributes)
fe80 0800 1001 2ec4
2383 (just like the first)
fe80 1000 1001 7e0b
2380 (and again back to the pattern)
fe80 2000 1001 df96
(1)f3a8 (just like before when the high bit of previous was set)
fe80 4000 1001 4c84
2383 (and again just like the first)
fe80 8000 1001 ba8b

So the XOR result cycles around, and only when you choose this shift direction... so it appears to be a CRC-like shift register, and yet it isn't quite and after a few days of poking at it I'm looking for more help.

i also was trying to understand crc reversing article here :


so, looking at first 2 test for crc from the article, it's a bit off from what you did.

the 1st test is, in my own sentence, if crc even then preceding one is obtained by simply right-shifting it.

this is the sample from the article:


but in your sample set, the test seems to fail.

2nd test, extracting the polynomial.
i don't think they're actually did <<1 xor next.
here is the sample set from the article:



i might be wrong, so might be other might have something to say about it.