This post sums up my steps for understanding the BANNED Redi Check MAV222 (aka Redi Check Model ET-732) checksum algorithm. I'm posting this, hoping it'll help others that are interested in figuring out, how the algorithm works. Note: this is not a generic recipe on how to proceed when reverse engineering something like a checksum algorithm.
Thanks to the previous posts in this thread, we already know, that the temperature values are tranmitted more or less in plain text. However, there wasn't much information available on what information the checksum contains, and how it behaves. I started by making a list of questions regarding the checksum.
In order to figure out, how the checksum behaves, it is beneficial to gather as much data as possible as a starting point. For deterministic results I tried to set up an environment, which is completely under control, including
I decided to replace the thermometers with variable resistors. In case anyone wants to reproduce this: the resistance is non-linear. At low temperatures (0..25°C) it takes several 100 KOhm, (around 0°C even MOhm) to increase / decrease the temperature by 1°C. At higher temperatures it takes just several KOhm to increase / decrease the temperature by 1°C. Furthermore, I used a stabilized external power supply, instead of batteries.
For gathering the actual data, I wrote a simple Linux kernel module, which prints the received data and checksum bits on the console. The output looks like this:
Code: Select all
Since the microcontroller used in the transmitter is a quite simple device (4 bit Microcontroller - WindRiver: W541E260), it is likely, that the checksum calculation is a relatively simple operation, as well (e.g. using logical AND, OR, XOR, bitshift, etc.). A
containing the assembler instruction set reinforces this assumption. Although it's in Chinese, it still contains the english acronyms of the instructions, including the registers they work on and whether they set carry-over or zero flags.
My first attempt in deciphering the checksum was to look at checksum as a whole. I was looking for patterns, e.g. what happens to checksum, if temperature is increased by 1°C:
However, to me there was no obvious pattern. Therefore, I started to look at the behaviour of individual checksum bits:
As one can see in this example, the bold checksum bits in column csum seem to toggle with the bold data bits in column data. Therefore, it's likely, that this checksum bit depends on the data bit. However there's an irregularity at t=592, as the bit doesn't toggle there. If you encounter such irregularities, don't scrap your assumption immediaely. Instead, try to figure out, what the root cause of the irregularity might be. Upon closer inspection of this row, it becomes clear, that another data bit (which was previously always zero) toggled to one (data, bold bit). Therefore, it's likely that the considered checksum bit not only depends on one but several data bits, which are XORd with each other.
From this point on, it makes sense to systematically analyze, which checksum bit depends on which data bit. In case you want to retrace the steps for determining the dependencies, I recommend to look at the following temperature changes:
Furthermore, plug and unplug the thermometer probes to toggle an additional bit.
After a systematic evaluation, it turns out that each checksum bit depends on approximately 7-9 data bits. In total this makes over 120 individual XOR operation. At this point it's possible to calculate the checksum. However, there are still three issues
To address issue 3), I decided to see, if there's a pattern in how the XOR operations are applied. My approach was to make a table for better visualization:
If you check the green column and have a look at the column next to it, it seems, that the XOR bit pattern is shifted "upwards". However this pattern changes at column data, bit 3. Therefore it's not a simple bitshift operation. Upon closer inspection, it becomes clear, that the bit pattern changes, whenever bit 3 of csum is "1" and the bit pattern is shifted left ("up" in the picture). This is a behaviour typical for a linear feedback shift register. I decided to verify this assumption, by implementing a shift register in software. The "green" column is the initial bitmask (0x3331). When executing the shift register step by step, one can determine, which bit positions should be fed back. The final result is that the feedback pattern is 0001 0000 0010 0001 (= 0x1021).
To address issue 2, I decided not only to generate the XOR mask for data nibbles data...data, but also to generate the XOR mask for nibble data. By also including nibble data, issue 2 could be resolved. This means that the checksum not only includes the temperature (contained in nibbles data ... data), but also nibble data.
With all this informaiton, it's now relatively easy to write code for generating the checksum:
The C code provided in the previous post performs exactly aforementioned steps with some optimizations :)