Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

strange CRC algorithm

To discuss DES MD5 El-Gamal RSA PGP and others....
Locked
ka6sqg

strange CRC algorithm

Post by ka6sqg »

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.
Top
dion
Member
Posts: 61
Joined: Tue Jul 31, 2007 8:38 am

Post by dion »

i also was trying to understand crc reversing article here :

Code: Select all

hxxp://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html
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:

Code: Select all

02 00  763c			
04 00  ec78	[color="#008080"]ec78/2 = 763c[/color]
08 00  98f3			
10 00  71e5			
20 00  e3ca	[color="#008080"]e3ca/2 = 71e5[/color]
40 00  8797			
80 00  4f2d			
00 01  9e5a	[color="#008080"]9e5a/2 = 4f2d[/color]
00 02  7cb7		
00 04  f96e	[color="#008080"]f96e/2 = 7cb7[/color]
00 08  b2df			
00 10  25bd
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:

Code: Select all

02 00 763c	
      0000	[color="#FF0000"]763c ^ 763c = 0000[/color]
04 00 ec78	[color="#FF0000"]ec78/2 = 763c[/color]
      a001	[color="#FF0000"]ec78 ^ 4c79 = a001[/color]
08 00 98f3	[color="#FF0000"]98f3/2 = 4c79[/color]
      a001	[color="#FF0000"]98f3 ^ 38f2 = a001[/color]
10 00 71e5	[color="#FF0000"]71e5/2 = 38f2[/color]
i might be wrong, so might be other might have something to say about it.
Top
Locked

Return to “RCE Cryptographics”