• C

32-bit CRC calculation

Write c code to calculate CRC using polynomial: x^32+x^30+x^28+x^23+x^18+x^17+x^16+x^15+x^8+x^7+x^6+x^3+x^2+1 for the message in which each character has been stored in an array of (unsigned char) messageBuffer[MESSAGE_LENGTH].  After calculate the CRC, store back the message with CRC appended to it into (unsigned char) messagewithcrcBuffer[MESSAGE_LENGTH+4].

I know how CRC works but I am unsure how I can get each character from the array and convert to number then concanate all the numbers(for complete message) to be moded by the polynomial to get crc.  Can someone help me, please?
RonnagornAsked:
Who is Participating?
 
Jaime OlivaresConnect With a Mentor Software ArchitectCommented:
you have to reserve a proper buffer size, with enough space to store any message.

This is an example
    #define MAX_ESTIMATED_LENGTH   300

Declare proper variables
    char buffer[MAX_ESTIMATED_LENTGHT];
    int len, i;
    unsigned long int crc;

Now you have to copy the message from somewhere to the buffer:
     strcpy (buffer, somemessage);
     len = strlen(buffer);

Now calculate the CRC (I assume you have your calculation function ready) using a for loop:
     crc = 0;
     for (i=0; i<len; i++) {
         crc = CalcCRC32(buffer[i], crc);   /* use previous crc in your calculus */
     }

     
0
 
Sjef BosmanGroupware ConsultantCommented:
Homework?? There are LOTS of examples on the internet, see also CRC16.

In C, a character IS a number, the character a has the value 97. If declared as

    char c= 'a';

then

    printf("%d\n", (int)c)

will yield 97.
0
 
ankuratvbCommented:
To concatenate the numbers as a number,you can use:

unsigned long var3;
unsigned int var1=97, var2=98;
int shift=sizeof(int)*8;
var3= ((unsigned long)var1<<shift) | var2;

var3 would contain 9798.

from:
http://www.experts-exchange.com/Programming/Programming_Languages/C/Q_21108427.html#11904200

Using this approach,you'd be limiting your input string to the range of a long.
0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
Jaime OlivaresSoftware ArchitectCommented:
Forgot to append the crc to your buffer. Some casting tricks:

*((unsigned long int *)(buffer+len)) = crc;
len += 4;

Now your buffer has the crc appended and the 'len' variable reflects total lenght including crc.


0
 
RonnagornAuthor Commented:
Ok, thanks jaime i have done the crc calculation and put it together with message and sent them.  Now, at the receiving end, how do i check for crc error.  Write now what i'm doing is get each character by character and concatenate them into big numbers and mod it with the crc which I get after all the characters from message come out.  I think it's kinda wrong.....but I'm not sure.  Anyone know?
0
 
Jaime OlivaresSoftware ArchitectCommented:
At the receiving end, you have to extract the crc from the buffer first. You have to know the lenght of the message to know where the CRC is located:

int len;
unsigned long int crc, crc1;

len =  ....   <-- some method to obtain the lenght

Another casting trick:

crc1 = *((unsigned long int *)(buffer+len));

Now do crc calculation using the for loop and store it into 'crc', exactly as done during transmision.
Finally compare 'crc' with 'crc1'.
0
 
Sjef BosmanGroupware ConsultantCommented:
Now the fun of CRC-16, and I assume it's the same for CRC-32: just process every byte of the array, including the crc-bytes. The resulting crc-value should be ...... zero! No casting required, but the bytes will have to be put into the string in the right sequence.
0
 
Jaime OlivaresSoftware ArchitectCommented:
That's an interesting method, not tried. Since crc is exactly at the end of the string could work, I guess. Maybe you can tell us if Little Endian or Big Endian is required.
0
 
Sjef BosmanGroupware ConsultantCommented:
I knew it, the question was too obvious. Eh, I don't know, but I can try... I did, eh, doesn't work. But I'm very sure it worked! I'll be back... :(

0
 
Sjef BosmanGroupware ConsultantCommented:
Aaaaaahhhhhh! Gotcha! These little grey cells still work :)

The CRC-32 algorithm I've got produces
    378420CF
for the string
    The quick red fox jumped over the lazy brown dog.

This result is the inverted value of the actual CRC. Why? Beats me. Anyway, if you add the inverted values of the bytes produces to the CRC-algorithm, so ~CF, ~20, ~84, ~37, you get ~0, i.e. 0xFFFFFFFF. If they would have left the inversion out, everything would have worked as it used to do (in the old days, as granpoh says).

So your answer: lower byte first.
0
 
Jaime OlivaresSoftware ArchitectCommented:
>So your answer: lower byte first.
So the solution will work with Intel platforms, casting trick needed at transmition, not needed at reception.

About the result of 0xFFFFFFFF. I think it is related with the last XOR needed at crc calculation:
In pseudo code:

    crc = 0xFFFFFFFF
    while (nextByte in buffer)
        crc = (crc>>8)   XOR   crc_table[ (crc  XOR  nextByte)   AND   0xFF]
    crc = crc XOR 0xFFFFFFFF
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.