Reverse engineering checksum calculation for Proflame 2 RF remote

Question

Intro

The SIT Proflame family of fireplace controllers is used in many brands of fireplaces. It uses an RF remote that transmits on 315MHz.

I would like to be able to generate valid command packets for arbitrary serial numbers to control my fireplace using a custom microcontroller with RF transmitter. Ultimately I intend for this to be used with a Home Assistant integration I'm creating, so that anyone can use it to control their fireplaces in this way, hence the need to be able to do it for arbitrary serial numbers.

Much of the calculation of the checksum is already known. What is not known what exactly causes the checksum values for remotes with different serial numbers to be different. The hope is that the serial number of the remote somehow is used to modify the checksum calculation and this modification can be reverse engineered. This is what this question is about.

Given the information available on the web it feels we are very close to being able to achieve this. The missing step is to find out what goes into making the checksum calculation unique for each remote's serial number.

Unfortunately I don't understand this well enough yet to come up with my own solution, so any pointers would be appreciated.

Details

Previous efforts

There have been previous efforts to reverse engineer the protocol and its checksum algorithm.

What I assume to be the original research by John Ellinwood is available here: https://github.com/johnellinwood/smartfire

A more detailed discussion around the checksum calculation and potential bit masks is available here: https://github.com/merbanan/rtl_433/issues/1905

Packet format

Sample Packet: a4ed02013ecab5

Serial	Version	Command 1	Command 2	Checksum 1	Checksum 2
a4ed	02	01	3e	ca	b5

This structure is reverse engineered. The version field is my guess as all packets I've seen reported so far are from Proflame 2 remotes and that field is consistently 0x02 on those packet captures. There is a Proflame 1 remote that shares the same FCC ID (Schematics, Block Diagaram) and housing design as the version 2 remote.

The packet length is fixed and does not vary, the serial and version bytes never changes for any one given remote.

What we know about checksum calculation

The following information has been reverse engineered so far:

1. Checksum 1 and Checksum 2 are independent of each other and correspond to Command 1 and Command 2 respectively (i.e. if Command 1 changes but Command 2 does not, Checksum 1 will change but Checksum 2 will not).

2. Checksum 1 and 2 are calculated in the same way. The checksum can be calculated with the following expression:

   checksum = (init ^ ((cmd&0xf0) << 1) ^ (cmd&0xf0) ^ ((cmd&0xf0) >> 4) ^ (cmd&0x0f) ^ ((cmd&0x0f) << 5)) & 0xff (Source)

   The value for init is the missing piece. The init value is different for Command 1 and Command 2 calculations.

3. Packets with the same command bytes generate different checksums on different remotes. Therefor it could be assumed that the serial number is a factor in determining the init value for each calculation.

4. For the data that we already have in the form of packet captures it is easy to brute force the values of init. So we can technically already calculate the checksum for remotes that we have known valid packet captures for.

I'm trying to figure out whether we could randomly generate a serial number, hopefully derive the necessary values for checksum calculation, and then send valid commands to the controller to pair our custom remote with it. The controller can pair with a new remote by putting the receiver into pairing mode and sending one "on" and one "off" signal from the remote. This would allow us to replace a defective or lost remote.

Sample Data

Here is a compilation of packet captures from different remotes: Proflame 2 packet captures on GitHub gists

For convenience, the corresponding (brute forced) init values (referred to as C and D in the original research) for the serials in this file are:

Serial	Init1 (C)	Init2 (D)
21dd	7d	8b
47eb	61	a7
7d14	7e	9e
a4ed	eb	28
bf39	dd	1c

What else has been tried

Guessing a CRC algorithm for the checksums using reveng did not yield any matches for a variety of combinations of message format (using the full packet, using serial bytes separately or combined, including and excluding the version).