-1

Good day to all hackers. I've been trying to figure out a checksum algorithm for RF transmissions, but after many hours, still no luck. The device I'm trying to "hack" is "Milux RF thermostat", branded as LHZ Lucht, manufactured by Watts... it communicates on 433mhz. I managed to understand the protocol to get meaningless (=hex) values from it. Of course I couldn't find anything about the above on google. I'm including some captured transmissions - the last byte is the checksum. Start is always FFFFFE (probably for sync reasons), so not sure if that would be included in the checksum. I tried "reveng" to reverse-engineer CRC, some common algorithms (sum, xor, etc.), but no luck.

FFFFFE0200A31F00BF010C6494
FFFFFE0200A31F00BF010F6458
FFFFFE0200A31F00C4010D64F0
FFFFFE0200A31F00C100AB0084
FFFFFE0200A31F00C400A800AA
FFFFFE0200A31F00CC010F6450
FFFFFE0200A31F00CE010F64F8
FFFFFE0200A31F00CE010E641E
FFFFFE0200A31F00CE00670048
FFFFFE0200A31F00CE010D64D2
FFFFFE0200A31F00CE00650062
FFFFFE0200A31F00CE00640084
FFFFFE0200A31F00CE010C6434
FFFFFE0300A31F00BF010C6472
FFFFFE0300A31F00BF010D6494
FFFFFE0300A31F00BF010E6458
FFFFFE0300A31F00BF010F64BE
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CE010F641E
FFFFFE0300A31F00CE010D6434
FFFFFE0300A31F00CE010E64F8
FFFFFE0300A31F00CE010C64D2
FFFFFE0200A31F00CE000000A8
FFFFFE0200A31F00CC010E64B6
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010C647A
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010D649C
FFFFFE0300A31F00CC010F64B6
FFFFFE0300A31F00CC010E6450
FFFFFE0300A31F00CC010C647A
FFFFFE0200A31F00CC010E64B6

Any help appreciated!

user1599438
  • 158
  • 1
  • 1
  • 5
  • FYI, you have many duplicated messages in your list. There are only 27 unique messages out of the 51 there. – Mark Adler Aug 02 '15 at 15:58
  • I'm voting to close this question as off-topic because the question should be addressed to the manufacturer. – user207421 Feb 09 '16 at 09:01

1 Answers1

0

The last byte is not a CRC-8 of the preceding message.

The last byte is however a linear function of the bits that precede it, at least across the example messages provided. "Linear" here means the each of the eight bits in the last byte is an exclusive-or of some subset of the bits in the preceding message.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Could you please explain the "linearity" a little bit? I was looking at samples that differ at one character only, but the difference to the checksum wasn't linear. Also if you take the first two samples for example FFFFFE0200A31F00BF010C6494 FFFFFE0200A31F00BF010F6458 the difference is only the C and F (on the position of the least significant nibble of the ckecksum), but the checksum is quite different (the first nibble is different, too). XORing the bits wouldn't do that... – user1599438 Aug 03 '15 at 01:59
  • It's what I said. Each of the eight check bits at the end is the exclusive-or of a different subset of the bits in the message that precede. At least that hypothesis is not contradicted by the data you provided. The way to tell is to exclusive-or two different pairs of messages to get the same message result and see if the last byte is also the same. – Mark Adler Aug 03 '15 at 02:12
  • You're a genius, you're on to something here! XORing 0200A31F00CC010F6450 ^ 0200A31F00CE00650062 and 0200A31F00CE00640084 ^ 0200A31F00CC010E64B6 gives exactly the same result (2016A6432). Is that what you meant? Also it works for all other examples. This is very helpful. I have no idea how to figure out what is the right subset of bits though... is this some kind of commonly used algorithm that maybe has a name or something? – user1599438 Aug 03 '15 at 09:30
  • Exactly. It is called a "linear function", in this case over the finite Galois Field 2, GF(2). You did not provide anywhere near enough data to determine the subsets of bits. (Most of your message bits don't even change in the provided data.) The check value is likely generated by a simple algorithm that combines the bytes of messages using exclusive-ors and shifts/rotations. It might just take some trial and error to find it. – Mark Adler Aug 03 '15 at 14:01
  • Thanks for your help. I tried various common algorithms, but nothing gets me anywhere. Unfortunately I don't have better messages. I'm now focusing on two messages that have only 1 bit difference 0300A31F00BF010C6472 and 0300A31F00BF010D6494 (the difference is the C/D, 3rd byte from the end). The checksum differs in 5 bits though... I can't work out any combination of xor/shift/etc. that would produce 5 bits difference from just 3 characters (I'm assuming that the first part of the message doesn't have any impact, because it's the same in both cases)... Am I going the right direction? – user1599438 Aug 04 '15 at 10:05
  • Yes. Here is a hint. The linear function is _ax+b_, where _a_ is an 8 by _n_ matrix, _n_ being the number of bits in the message, so _x_ is an _n_-bit vector. _b_ is an 8 bit constant exclusive-ored with the result. Given two messages _x_ and _y_, if we exclusive-or the messages, _x+y_, the exclusive-or of the check values is _a(x+y)_. The _b_ cancels. So you should start by trying to find the algorithm on exclusive-ors of pairs of messages. Then you are only trying to find _a_. If you solve that, then finding _b_ will be trivial. – Mark Adler Aug 04 '15 at 13:36