Protocols guru wanted.

[mrdebug]

I have to extract and implement a protocol from a device, without the documentation.
I'm monitoring the rs232 to watch the data exchange between the pc and the device.
I have grab 3 sequences of bytes.

Address 1
[0x01][0x01][0x81][0x7E][0x08][0x00][0x75][0x80][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 2
[0x02][0x02][0x81][0x7E][0x08][0x00][0x74][0x7F][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 56
[0x38][0x38][0x81][0x7E][0x08][0x00][0x3E][0x49][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 123
[0x7B][0x7B][0x81][0x7E][0x08][0x00][0xFB][0x05][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]

In your honest opinion which is the checksum?

[koahnig]

@mrdebug

My honest opinion is, it would be better to ask someone with a crystal ball or someone professional working at NSA or similar services. My expectation for the latter category that they tend to stay silent, if they are monitoring the forum.

More seriously, you obviously have at least a bit more information than you share. You know an approximate update rate and the kind of numbers to be expected. E.g. if it is a kind of voltmeter you know at least the kind of measurement and can try to measure with a different device. Or even better the device is communicating already with some type of application and you can see the actual results.

Personally I would care last for detecting the checksum, because it gives you simply the integrity of a byte stream and in most case the checksum operates without details on actual data content. After decrypting the data content and knowing where it is located, you can bother about the checksum. Possibly there sequences still around and you are not knowing their meaning and only a part of them are the checksum.

I have seen formats in the past, where I can wish you only to be paid by the hour on a regular basis and not by the end result.

[mrdebug]

Thanks you for you reply.
Now I can understand (not all but a lot) what the pc andhe the device are saying. I can recognize not all the entire sequence but a lot of it.
I think that the bcc is the seventh and eighth byte in the sequence but I don't understood how to calculate it.

Address 1
[0x01][0x01][0x81][0x7E][0x08][0x00][0x75][0x80][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 2
[0x02][0x02][0x81][0x7E][0x08][0x00][0x74][0x7F][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 56
[0x38][0x38][0x81][0x7E][0x08][0x00][0x3E][0x49][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]
Address 123
[0x7B][0x7B][0x81][0x7E][0x08][0x00][0xFB][0x05][0xE8][0x03][0x17][0xFC][0x00][0x00][0x00][0x00]

After having understood how to calculate the bcc I will can send request without to use the original software.

[hskoglund]

@mrdebug About that checksum, looks like a 16-bit additive CRC, so let's try:

auto calcCrc = [](QByteArray ba) { unsigned int crc = 2;
                                   for (int i = 0; (i < ba.length()); i += 2)
                                   {
                                       unsigned char lo = ba[i];
                                       unsigned char hi = ba[i + 1];
                                       crc += lo + hi * 256;
                                   }
                                   return crc & 0xFFFF; };

qDebug() << calcCrc(QByteArray::fromHex("[01][01][81][7E][08][00][75][80][E8][03][17][FC][00][00][00][00]"));
qDebug() << calcCrc(QByteArray::fromHex("[02][02][81][7E][08][00][74][7F][E8][03][17][FC][00][00][00][00]"));
qDebug() << calcCrc(QByteArray::fromHex("[38][38][81][7E][08][00][3E][49][E8][03][17][FC][00][00][00][00]"));
qDebug() << calcCrc(QByteArray::fromHex("[7B][7B][81][7E][08][00][FB][05][E8][03][17][FC][00][00][00][00]"));

Sure enough, all 4 qDebug() returns 0 :-)

[mrdebug]

many thanks for your help.
I have decompiled (not completely, at 50%) the protocol.
In my honest opinion there isn't a typical crc calculation but avery ugly check.
For exsample the first 8 bytes are calculated with this pattern:
d= (e,f,g,a)

[hskoglund]

@mrdebug Agreed, it's not a fancy CRC like in Zip file or so, just simple 16 bit additions, better just to call it a checksum.

Note however that UDP and TCP checksums are computed in the same way i.e. at least 40 years old technology but seems to work fine on internet...