Post by thread:[EE]:Re: CRC Checksum - Can't figure it out

Hi, It's gone to be difficult to hack this poly. It seems to be a 16 bit CRC but, who knows? I have tested your code with the standards CRC16 and CRC CCITT (reverse included),... and nothing happens. How do you know that 1F has something to do with length? What happend if you send a complete word? Can you send more examples? Dennis. {Original Message removed}

On Mon, 1 Jul 2002, Dennis Crawley wrote: >Hi, >It's gone to be difficult to hack this poly. >It seems to be a 16 bit CRC but, who knows? I have tested your code with the standards CRC16 and CRC CCITT (reverse included),... and nothing happens. >How do you know that 1F has something to do with length? >What happend if you send a complete word? Can you send more examples? > >Dennis. You should be able to decode it yourself. Send messages with 1 letter or other character in them, each, and collect the differing parts. Then do some analysis. I think that ten messages should be enough for a start. The two character signature suggests a simple checksum or xor and shift hash, not necessarily CRC. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Still no luck with this checksum problem. I'm out of ideas. Does anybody know of a better or more appropriate place I can go (like other message boards) that are geared more towards the subject of math issues like checksums and CRC's??? I think I need a big math wiz to help me figure this one out. :-) thanks. -Dan {Original Message removed}

Sounds interesting. But don't try to make it more complicated than it is. Maybe it is just a sum of the bytes. I looked at your sample data, but it was too "all over the place". stick with one mode for sample data and maybe even one character. And then maybe try one character in position one, then position two and lastly position three, leaving all positions except the one blank. "A ", " A ", " A". Then "A" as the last character, just so you can be sure where the last character of the text ends and maybe the check sum begins. It may not be necessary to fully understand what it is doing. All you want to do is to be able to predict the proper check sum for your data. Bill {Original Message removed}

You could try one of the embedded system newsgroups. However, if you could provide more sample data, perhaps one of us could solve it here. -Shawn Does anybody >know of a better or more appropriate place I can go (like other message >boards) that are geared >more towards the subject of math issues like checksums and CRC's??? >I think I need a big math wiz to help me figure this one out. :-) >thanks. > -Dan _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Just disassemble the binary for the DOS program and figure out what algorithm it uses. We all speak assembly here, right? I've heard that Intel will ship you an X86 assembly reference for free. Good luck --Brendan {Original Message removed}

Have you seen RFC 1331? Is this for a ppp link or some other link? Here's the jist of the FCS/CRC code from RFC 1331: /* ************************************************************************ * * pppfcs - Calculate a new fcs given the current fcs and the new data. * Note: FCS calcs are performed on converted (de-stuffed) data! * From: RFC 1331 Appendix B */ #define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */ unsigned int pppfcs ( register unsigned int fcs, register unsigned char *cp , register int len ) // Worked w/"register" { assert( sizeof (unsigned int) == 2 ); assert( ((unsigned int) -1) > 0 ); while (len--) { // -------- fcs ----------------------------- // ---- Temp2 -------------------- // -- Temp1 -- fcs = (fcs >> 8) ^ fcstab [ (fcs ^ *cp++) & 0xff ] ; // Worked OK } // return (fcs); // } // ***** End: pppfcs ********************************* Requied look-up table: /* From: RFC1331.htm http://www.armware.dk/RFC/rfc/rfc1331.html * FCS lookup table as calculated by the table generator in section * B.2. */ // static u16 fcstab[256] = { static unsigned int fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, // 1 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, // 5 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, // 10 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, // 15 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, // 20 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, // 25 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, // 30 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 // 32 }; Sample call: PPP_TempUInt = pppfcs( PPPINITFCS, // Req'd init value Gp2ChrPtrC, // Pointer to PPP string 14); // Len // Complementing req'd (see RFC1662 App C.2) PPP_TempUInt = PPP_TempUInt ^ 0xFFFF; // Complement This code compiled and ran okay under the Borland version 3.1 compiler under DOS on a PC. I did originally foa an embedded PC project that was viewing data on a ppp (point to point protocol) link. Jim {Original Message removed}

On Mon, 8 Jul 2002, Brendan Moran wrote: >Just disassemble the binary for the DOS program and figure out what >algorithm it uses. We all speak assembly here, right? I've heard that >Intel will ship you an X86 assembly reference for free. Presumably in a gift wrapping with a pair of handcuffs and a copy of the DMCA ? Peter -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Thanks, That's something to chew on for a while. Also, off list Brendan Moran offered to crack open the DOS program for me. He thinks either he or a friend of his might be able to see what it is doing when it sends the serial data. No word from him yet. This situation is looking kinda doubtful to me. My cousin and I managed to come up with a sloppy workaround by making a VB app that can send key presses to the DOS program. But that is just sloppy and weird. It would be much better to figure out the protocol instead. I guess we'll see if Brendan comes up with anything or not. -Dan {Original Message removed}