5

Need help in figuring out the checksum used for this small data packet. Packet is 48 bits long, I already have figured out most of the bits. Least 8 bits change even if there is a single bit change in rest of the packet. So I'm guessing this must be some sort of checksum. Tried all checksum algorithms I know of and nothing fits.

The packet is question is RF transmission being send by a motion sensor (history below). The bits are,

4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 
7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
-----------------------------------------------------------------------------------------------
p p p p p s s s 0 0 m t 1 i i i i i i i i 1 i i i i i i i i 1 i i i i i i i i 1 c c c c c c c c


p = Preamble (11111), helps is demodulating the signal by providing enough transitions.
s = Some sort of status (only changed when sensor was initializing after power up)
m = '1' When motion is detected.
t = '1' when tamper switch is pressed.
i = Unique sensor ID which is also printed on the back of the sensor.
c = These bits change whenever any of the other bit change. I'm guessing this is checksum.

Notes:

  • Fixed 0's and 1's may very well be some other status reporting, which just don't change in case of motion sensor.
  • ID (i) is embedded in the packet at non-byte offsets. It seems like ID is embedded as '1' followed by 8-bits, maybe the protocol was originally designed for octadecimal.
  • This transmission does not seem to be using any rolling code. Its always the same.
  • This is over 10 years old system, I don't expect it to using anything complicated.

Example packets that I have captured for three different sensors are,

FA 19 D4 3E 3B A7 (11111010 00011001 11010100 00111110 00111011 10100111)
F9 29 D4 3E 3B EE (11111001 00101001 11010100 00111110 00111011 11101110)
F9 39 D4 3E 3B 44 (11111001 00111001 11010100 00111110 00111011 01000100)

FC 29 D4 C7 11 D4 (11111100 00101001 11010100 11000111 00010001 11010100)
F9 39 D4 C7 11 19 (11111001 00111001 11010100 11000111 00010001 00011001)
F9 29 D4 C7 11 B3 (11111001 00101001 11010100 11000111 00010001 10110011)
FA 19 D4 C7 11 FA (11111010 00011001 11010100 11000111 00010001 11111010)

F9 29 AE 8E DF 57 (11111001 00101001 10101110 10001110 11011111 01010111)
F9 39 AE 8E DF FD (11111001 00111001 10101110 10001110 11011111 11111101)

This is no hacking or anything like that. This all started as simple exercise to use SDR and GnuRadio to demodulate some RF transmission. Once properly demodulated, it was challenging to figure out the packet format, but this checksum issue is now driving me nuts.

Any help is really appreciated.

chis
  • 51
  • 3

2 Answers2

6

(I don't have quite enough reputation for a comment so please excuse a very partial answer.)

You need to consider whether some of the bits are not part of the packet data but part of an encoding for transmission. e.g. the 1's at regularly spaced bit positions 8, 17, 26, 35 could well be there to prevent a run of 0's getting too long. (Knowing the modulation scheme could help.)

For example, it might be that your message data is actually:

1sss00mt iiiiiiii iiiiiiii iiiiiiii cccccccc

It could then be transmitted as:

'1111' byte[0] '1' byte[1] '1' byte[2] '1' byte[3] '1' byte[4]

Any checksum might then be based on the message data alone.

Ian Cook
  • 2,548
  • 11
  • 18
  • That's a good point. I tried it that as well, no luck. Also tried brute forcing simple add/sub and bit operations, still no luck. My best guess is that it at least involves XOR, since changing one specific bit is toggling three specific bits in the checksum (regardless of the rest of the bits). – chis Jun 23 '14 at 01:40
2

Many checksums, especially with small packets of data, are very simple to keep load down on the teeny-tiny brains of embedded devices.

Also consider that the checksum must be fast and simple to verify.

Generally, the checksum is designed so that the final result is 0 (zero), as that's super simple to check.

Some things to try:

  • add all the BYTES (8 bit chunks), example result & 0xFF (lower 8 bits), is it zero? or perhaps always a constant?

  • subtract the bytes. Start with zero, subtract each chunk. Do you get zero again? or a constant value for each packet?

  • xor the bytes, same as above.

  • Often, the microcontrollers might have a 4 bit bus... repeat the previous checks while using 4 bits at a time. Very slight chance it might have 16 bit bus, but for smaller devices, unlikely.

  • Another thing to keep in mind is that you may have the polarity reversed on the signal you demodulated. Perhaps the 1's are 0's and vice-versa? Many devices are active-logic-low, meaning they show zeros on their bus when signalling/indicating something rather than ones. (although I believe the checksum final result could be all 1's for this scenario)

                    Add Sub Xor 4A 4S 4X
FA 19 D4 3E 3B A7 : 07  F9  95  4  C  C    ; hmmm, dunno yet 
F9 29 D4 3E 3B EE : 5D  A3  EF  F  1  1    ; drat, nothing jumps out yet
F9 39 D4 3E 3B 44 : C3  3D  55  C  4  0    ; awww, maaaaaaannn!

FC 29 D4 C7 11 D4 :                        ; these entries left as an
F9 39 D4 C7 11 19 :                        ; exercise for the reader...
F9 29 D4 C7 11 B3 :
FA 19 D4 C7 11 FA :                        ; also, I'm being lazy tonight
                                           ; and these are painful to compute
F9 29 AE 8E DF 57 :                        ; by hand.
F9 39 AE 8E DF FD

What you need are many packets from a single sensor under steady-state conditions. Do you get the same packet data every time? or perhaps there's a counter or I'm Alive kind of value?

Of course, then do this for every sensor, looks for trends. But I'd be curious as to what (if any) changes during steady-state.

lornix
  • 266
  • 2
  • 5
  • I already have tried all of the things you mentioned, manually. Might have something. I can try to code something up to make sure I didn't miss anything. Regarding steady state change, as I mentioned there is no counter/rolling code sort of thing. Once the motion stops or tamper switch is back to original state, it re transmits the same old data and the same old checksum (I know its not really good for a security sensor) – chis Jun 20 '14 at 01:54
  • Well, Pooh! I know it would bug me to not know what those last bits represent, but it looks like you've got most of the packet decoded and could use the data as sensor results. (My inner OCD whines and says we need to knooooowww {sigh} ) – lornix Jun 20 '14 at 01:57
  • One more thing, three of the pairs have 29/39 in second bytes. But the checksum change is multiple bits with no apparent pattern. That made me wonder if it's more than simple xor/add/subtract. So I also tried few CRCs, specially CRC8 with few different polynomials. But still nothing fits. And I doubt it could be using anything more sophisticated like SHA for checksum. – chis Jun 20 '14 at 02:08