tags:

views:

2806

answers:

4

Let's assume that I have some packets with a 16-bit checksum at the end. I would like to guess which checksum algorithm is used.

For a start, from dump data I can see that one byte change in the packet's payload totally changes the checksum, so I can assume that it isn't some kind of simple XOR or sum.

Then I tried several variations of CRC16, but without much luck.

This question might be more biased towards cryptography, but I'm really interested in any easy to understand statistical tools to find out which CRC this might be. I might even turn to drawing different CRC algorithms if everything else fails.

Backgroud story: I have serial RFID protocol with some kind of checksum. I can replay messages without problem, and interpret results (without checksum check), but I can't send modified packets because device drops them on the floor.

Using existing software, I can change payload of RFID chip. However, unique serial number is immutable, so I don't have ability to check every possible combination. Allthough I could generate dumps of values incrementing by one, but not enough to make exhaustive search applicable to this problem.

dump files with data are available if question itself isn't enough :-)

Need reference documentation? A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS is great reference which I found after asking question here.

In the end, after very helpful hint in accepted answer than it's CCITT, I used this CRC calculator, and xored generated checksum with known checksum to get 0xffff which led me to conclusion that final xor is 0xffff instread of CCITT's 0x0000.

+1  A: 

You would have to try every possible checksum algorithm and see which one generates the same result. However, there is no guarantee to what content was included in the checksum. For example, some algorithms skip white spaces, which lead to different results.

I really don't see why would somebody want to know that though.

Martin Cote
I can see why somebody would want it - if they're reverse engineering a file format in order to produce those files. I've done it.
Paul Tomblin
Correct. I have serial RFID protocol with some kind of checksum. I can replay messages without problem, and interpret results (without checksum check), but I can't send modified packets because device drop them on the floor.
dpavlin
+1  A: 

It might not be a CRC, it might be an error correcting code like Reed-Solomon.

ECC codes are often a substantial fraction of the size of the original data they protect, depending on the error rate they want to handle. If the size of the messages is more than about 16 bytes, 2 bytes of ECC wouldn't be enough to be useful. So if the message is large, you're most likely correct that its some sort of CRC.

DGentry
True, but messages are well below 256 bytes, and checksum is checked on rather simple hardware device, so my best guess for now is that it's some kind of CRC.
dpavlin
To be exact, my longest message is 70 bytes. There is hole in packet before length which might extend possible lengths over one byte, but I haven't seen any real-life messages longer than 70 bytes yet.
dpavlin
+6  A: 

There are a number of variables to consider for a CRC:

Polynomial
No of bits (16 or 32)
Normal (LSB first) or Reverse (MSB first)
Initial value
How the final value is manipulated (e.g. subtracted from 0xffff), or is a constant value

Typical CRCs:

LRC:    Polynomial=0x81; 8 bits; Normal; Initial=0; Final=as calculated
CRC16:  Polynomial=0xa001; 16 bits; Normal; Initial=0; Final=as calculated
CCITT:  Polynomial=0x1021; 16 bits; reverse; Initial=0xffff; Final=0x1d0f
Xmodem: Polynomial=0x1021; 16 bits; reverse; Initial=0; Final=0x1d0f
CRC32:  Polynomial=0xebd88320; 32 bits; Normal; Initial=0xffffffff; Final=inverted value
ZIP32:  Polynomial=0x04c11db7; 32 bits; Normal; Initial=0xffffffff; Final=as calculated

The first thing to do is to get some samples by changing say the last byte. This will assist you to figure out the number of bytes in the CRC.

Is this a "homemade" algorithm. In this case it may take some time. Otherwise try the standard algorithms.

Try changing either the msb or the lsb of the last byte, and see how this changes the CRC. This will give an indication of the direction.

To make it more difficult, there are implementations manipulate the CRC so that it will not affect the communications medium (protocol).

From your comment about RFID, it implies that the CRC is communications related. Usually CRC16 is used for communicated, though CCITT is also used on some systems.

On the other hand, if this is UHF RFID tagging, then there are a few CRC schemes - a 5 bit one and some 16 bit ones. These are documented in the ISO standards and the IPX data sheets.

IPX:  Polynomial=0x8005; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6B: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
ISO 18000-6C: Polynomial=0x1021; 16 bits; Reverse; Initial=0xffff; Final=as calculated
    Data must be padded with zeroes to make a multiple of 8 bits
ISO CRC5: Polynomial=custom; 5 bits; Reverse; Initial=0x9; Final=shifted left by 3 bits
    Data must be padded with zeroes to make a multiple of 8 bits
EPC class 1: Polynomial=custom 0x1021; 16 bits; Reverse; Initial=0xffff; Final=post processing of 16 zero bits

Here is your answer!!!!

Having worked through your logs, the CRC is the CCITT one. The first byte 0xd6 is excluded from the CRC.

selwyn
Thanks, I'm trying it right now! :-)
dpavlin
I'm slowly loosing my hair (again). I tried to use CCITT with my data, but it doesn't work for me. Can you share a snippet of implementation and/or reproduce CRC on http://www.zorc.breitbandkatze.de/crc.html or http://www.lammertbies.nl/comm/info/crc-calculation.html
dpavlin
Ignore me, final xor is 0xffff not 0x0000 as with ccitt... I xored ccitt checksum with checksum itself, and that lead me in right direction...
dpavlin
A: 

I Need calculate the checksum operation.. I have the source and the result. but I dont know the operation that do.. If you could Help me .. please reply.. Thank You

Example :

HostIP="192.9.200.154" CheckSum="fl/L+Zc7a8ACiGm3APAb/dPBMaZ0ruFY"/

How It convert the Ip Address to Checksum?...