Help needed cracking CRC-8

I use my Arduino to capture and decode 434Mhz signals from the Ambient F007th wireless Thermo-Hygrometers.

Thanks to these forums I have a sketch that accurately reports data 97% of the time, you can see my sketch and analysis of the data bursts here. https://github.com/AMcAnerney/Arduino-F007th-Sketches

Now I am trying to work out the CRC in the final byte so I can add error checking to the sketch to eliminate the 3% of misreadings.

From the 1,000 + unique data captures I have selected three sets with a single bit difference - I hoped I would be able to break the code from them but failed. Time consuming attempts to match it manually using the CRC-8 examples given on WIki have also been unsuccessful.

Set 1 FF 45 77 14 80 31 A5 FF 45 77 14 81 31 E6 FF 45 77 14 82 31 23 FF 45 77 14 84 31 98 FF 45 77 14 88 31 DF

Set 2 FF 45 7B 44 80 30 FD FF 45 7B 44 81 30 BE FF 45 7B 44 82 30 7B FF 45 7B 44 84 30 C0 FF 45 7B 44 88 30 87

Set 3 FF 45 B2 54 80 30 D8 FF 45 B2 54 81 30 9B FF 45 B2 54 82 30 5E FF 45 B2 54 84 30 E5 FF 45 B2 54 88 30 11

Does anybody have any ideas or suggestions? Let me know if there is any more data required.

Thank you all in advance.

Sorry, Just realised that my sketch drops the first 01 between the header and the first byte of data. If the header is included in the checksum it would be FD, not FF!

Since I posted I have discovered an 8 year old post in a different forum regarding checksum algorithm reverse engineering. Following their method I discovered that there is a consistent relationship between the single bit changes across the sets of data I provided above and other sets I have located within my other data points. I also noticed that one of the data points in set 3 is wrong.

Set 1

^ = applying XOR

A5 ^ E6 = 43 A5 ^ 23 = 86 A5 ^ 98 = 3D A5 ^ DF = 7A

Set 2

FD ^ BE = 43 FD ^ 7B = 86 FD ^ C0 = 3D FD ^ 87 = 7A

Set 3

D8 ^ 9B = 43 D8 ^ 5E = 86 D8 ^ E5 = 3D D8 ^ 11 = C9!! (I suspect that this is a data blip and it should be A2 rather than 11)

Now I have also noticed when comparing the XORs that the relationship between sequential bits is either 0x00 OR 0x31, the latter I know is a common CRC-8.

Now I am stuck again, I do not know how this relates to the packet data. Any ideas?

Reveng finds a 16bit solution (with or without the leading ff or fd bytes):

C:\Users\Jim\Desktop\reveng-1.1.0>reveng -w 16 -a 8 -s ff4577148031a5 ff457714823123 ff4577148131e6 reveng: searching: width=16 poly=0x0001 refin=false refout=false width=16 poly=0x0043 init=0xf6ba refin=false refout=false xorout=0x0000 check=0x2fe0 name=(none)

With fd leading:

C:\Users\Jim\Desktop\reveng-1.1.0>reveng -w 16 -a 8 -s fd4577148031a5 fd457714823123 fd4577148131e6 reveng: searching: width=16 poly=0x0001 refin=false refout=false width=16 poly=0x0043 init=0xf4ba refin=false refout=false xorout=0x0000 check=0x2566 name=(none)

See http://reveng.sourceforge.net/

Thanks Jim for running reveng and posting the result.

I have now been to sourceforge.net and read the reveng manual but am still a bit unclear as to what the result means. (I also tried running reveng myself on my virtual box but could not make it work).

In relation to the ff results

check=0x2fe0, what is the check? Is the first width and poly (16 and 0x0001) part of the query to reveng, or part of the result? If I wanted to incorporate this detail into an error checking sketch how do I use this data?

Thanks again.

This is the command format I used to run reveng:

reveng -w 16 -a 8 -s ff4577148031a5 ff457714823123 ff4577148131e6

The command states to use a 16-bit shift register, that the character width is 8 bits (default and not needed) and to search the following three strings for an appropriate algorithm. You may have to read up on how CRC computations work to figure everything out, e.g. Cyclic redundancy check - Wikipedia

Note: this works for the first 3 or so messages in every set, but not all messages. You may have some errors in the messages, as suggested by your post, or you are still missing something. The fact that the same polynomial keeps coming up is encouraging. The highest order bit of the polynomial “signature” is dropped by convention, so the actual feedback polynomial 0x0043 reported by reveng for your data means to use bits 15 and 6, 1 and 0 as the feedback terms.

There are several websites that will calculate the CRC for an arbitrary polynomial and other options, and even write the C code for you, but it may take several tries to get it right. This is because there is no standard for the bit order (LSB first or MSB first), either for the individual bytes or for the entire message (hence the “reverse” options in reveng). In addition, there are the possibilities of XORing the data with initial or final values (INIT, XOROUT). Because of this, it often doesn’t matter if “extra” constant bytes appear in the message, like FF or FD, as they get swallowed up by the INIT or XOROUT terms.

C Code generator site: https://ghsi.de/CRC/index.php
To get started with the above site, enter “10000000001000011” as your polynomial and leave out the leading FF or FD bytes of the messages. You will see that for the first three entries in each group the messages always result in the same CRC value, which could be taken care of using the “XOROUT” term.

Two other CRC calculator sites are
http://www.zorc.breitbandkatze.de/crc.html

I wondered about the “check” and wrote to Greg Cook (author of reveng) about it. Here is what he said:

The Check value is the CRC of the ASCII string “123456789” in the specified algorithm. It’s there as a check that the algorithm has been implemented correctly. This field was introduced by Ross Williams in chapter 16 of his 1993 paper “A Painless Guide to CRC Error Detection Algorithms” http://www.repairfaq.org/filipg/LINK/F_crc_v34.html#CRCV_005. As indicated there, it is a ‘non-normative’ field - the other fields are authoritative in the event of a discrepancy.

Edit: Note also that some remote sensors swap the nibbles within the bytes, so that is something to try. Good luck and let us know how you get on!

I played with your data a bit more but am not convinced that the solution has been found. It also seems unlikely that a 16-bit shift register would be used. So, I tried bit-reversing each of the message bytes and looking for a CRC-8, but that didn't work either.

Nevertheless it does appear to be a CRC algorithm of some sort, and you should definitely take a look at this very interesting post on cracking CRCs http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

Here's, probably, the best tool on CRC RevEnging: http://reveng.sourceforge.net/ Has very nice documentation too

Here's, probably, the best tool on CRC RevEnging: http://reveng.sourceforge.net/

See reply #3