Determining CRC algorithm from data + CRC - embedded application.

Answer 1

The code you posted from loc_34FA6 down is basically the following:

unsigned short
crc16_update(unsigned short crc, unsigned char nextByte)
{
    crc ^= nextByte;

    for (int i = 0; i < 8; ++i) {
        if (crc & 1)
            crc = (crc >> 1) ^ 0xA001;
        else
            crc = (crc >> 1);
    }

    return crc;
}

This is a CRC-16 with a 0xA001 polynomial. Once you find out the range of data for which the CRC-16 applies, you initialize CRC to 0xFFFF and the call this function for each byte in the sequence. Store the return value and pass it back in the next time through. The value returned at the end is your final CRC.

I'm not sure what the prologue is doing...

Answer 2

More generally, part of the concept of CRC is that the when you compute the CRC of some data file, and then append the CRC on the end, you get a file who's CRC is some value that depends on the length of the file, but not it's contents. (For some CRC algorithms, it doesn't even depend on the file length.)

So, if you suspect the app you're trying to reverse-engineer is using say CRC16, and you have a program that computes CRC16, and you have multiple samples of the same length, just compute the CRC16 of those data files (which include the checksum). If it comes back with the same checksum data every time (for files of the same length), then they must contain a CRC checksum using the same width and polynomial.

For example, I once had to reverse engineer some files where the developer thought he was being clever by changing the CRC32 algorithm by changing two constants. I didn't have to find the object code that verified the checksum, disassemble it and then figure it out the hard way. This simple test nailed it.