7

I’ve been doing a fair bit of DIY home automation (RF; 433MHz) lately across many different devices - which worked well for all except one. It's basically a pool robot with some really crappy remote control.

I collected some data using a BladeRF SDR and GNU Radio. The "other 3" column is basically the action, while "other 1" seems to be some serial and "other 2" defines the robot if you have multiple in use I guess (some friend of mine who has the same has a different value there). I'm not sure what purpose the count suits but I would guess it's so the robot knows when the range gets too wide eventually (missing some information?). I've narrowed down the bytes and their meanings, however I fail at calculating the correct CRC (checksum) for the data.

OLD - PLEASE SEE UPDATE BELOW!!

Here is some sample data:

<other1                  > <other2> <other3> <count > <crc   >      
10110100 00111110 10001111 11001000 00000001 11110111 01011110
10110100 00111110 10001111 11001000 00000001 11111000 01010011
10110100 00111110 10001111 11001000 00000001 11111001 01010100
10110100 00111110 10001111 11001000 00000001 11111010 01010001
10110100 00111110 10001111 11001000 00000001 11111011 01010010
10110100 00111110 10001111 11001000 00000001 11111100 01010111
10110100 00111110 10001111 11001000 00000001 11111101 01011000
10110100 00111110 10001111 11001000 00000001 11111110 01010101
10110100 00111110 10001111 11001000 00000001 11111111 01010110
10110100 00111110 10001111 11001000 00000001 00000000 01100111
10110100 00111110 10001111 11001000 00000001 00000001 01101000
10110100 00111110 10001111 11001000 00000001 00000010 01100101
10110100 00111110 10001111 11001000 00000001 00000011 01100110
10110100 00111110 10001111 11001000 00000001 00000101 01100100
10110100 00111110 10001111 11001000 00000001 00000111 01100010
added data:
10110100 00111110 10001111 11001000 00000010 00000110 01100100
10110100 00111110 10001111 11101010 00000010 01100101 10011010
10110100 00111110 10001111 11101010 00000001 01100100 10011100
10110100 00111110 10001111 11101010 00000001 01100011 10011101
10110100 00111110 10001111 11101010 00000001 01100110 10011010

There is a count for each request that must be changed and some commands to be sent, e.g. the "other 3" column could read 00000010 instead of 00000001.

It would be very helpful if somebody could give me some hints on where to look at. I've tried different techniques like XOR across the bytes or calculating modulo etc. - I even tried different CRC algorithm brute force tools - unfortunately to no success yet.

EDIT: I've put the data into excel and added some function (it basically compares each 4 bit with the ones from above - the last transmission). I've done that as I recognized the CRC stayed the same once. This was the case when both action and count were raised by 1. Please have a look:

data

UPDATE:

I've found some other more detailed spec. from the same vendor on the net after searching for hours and it came out the so thought CRC is in fact a parity. I also fine tuned my gnu radio capture flowgraph and collected some new data. Please disregard the data above and have a look here:

other 1> other 2                > other 3> other 4    > parity
10110100 001111101000111111101010 00000001 011110101001 0101
10110100 001111101000111111101010 00000001 011110111001 0110
10110100 001111101000111111101010 00000001 011111001001 0011
10110100 001111101000111111101010 00000001 011111011001 0100
10110100 001111101000111111101010 00000010 011111101001 0100
10110100 001111101000111111101010 00000010 011111111001 0011
10110100 001111101000111111101010 00000010 100000001001 0011
10110100 001111101000111111101010 00000010 100000011001 0100
10110100 001111101000111111101010 00000001 100000101001 0100
10110100 001111101000111111101010 00000001 100000111001 0011
10110100 001111101000111111101010 00000001 100001001001 0110
10110100 001111101000111111101010 00000001 100001011001 0101
10110100 001111101000111111101010 00000010 100001101001 0101
10110100 001111101000111111101010 00000010 100001111001 0110
10110100 001111101000111111101010 00000010 100010001001 1011
10110100 001111101000111111101010 00000010 100010011001 1100
10110100 001111101000111111101010 00000001 100010101001 1100
10110100 001111101000111111101010 00000001 100010111001 1011
10110100 001111101000111111101010 00000001 100011001001 1110
10110100 001111101000111111101010 00000001 100011011001 1101

And here is it again as fancy excel:

enter image description here

Does anybody know how to calculate that parity? I've tried splitting the data etc. and using usual parity calculations but unfortunately with no success yet.

Improve this question
8
  • 1
    You don't have enough information here, as the only thing you ever show changing besides the check value is the last byte, the count. Therefore you cannot distinguish the impact of the preceding bytes vs. some static starting value of the algorithm. You can make some guesses and perhaps test them, or even perhaps find a theory too beautiful to not be likely, but all you can truly reverse from the given data alone is the role of the last byte in creating the check value.
    – Chris Stratton
    Sep 22, 2017 at 19:38
  • 2
    @ChrisStratton You are right. I've added some data changing other values. Is it helpful?
    – Omegavirus
    Sep 22, 2017 at 21:44
  • 1
    Nice. I'd be surprised, but it's possible there is some rolling code. Did you confirm if simple replay of old captures is effective? Think you will need to self-answer this one, but it will be useful reference.
    – Sean Houlihane
    Sep 23, 2017 at 9:54
  • @SeanHoulihane I thought so too at first. But after some failed attempts I managed to resend data and it was accepted so I concluded there's no rolling code or something like that. I mean, that way it would be possible to capture whole 'sketches' of actions and replay it, but that doesn't work as that count must be raised appropriately all the time (there is a difference of some amount that is accepted still - as said I assume because of data being loste for range issues etc.) because if not, the robot looses 'sync' and needs to be brought back and plugged into his docking station.
    – Omegavirus
    Sep 23, 2017 at 10:01
  • 1
    @MikaelFalkvidd That's a good idea and usually my starting point when available. Unfortunately as it's an european device there is no FFC id or similar available.
    – Omegavirus
    Sep 23, 2017 at 11:18

1 Answer 1

Reset to default
5

Oh man, don't ask me how but I think I figured it out.

Let's have a look:

enter image description here

Basically you split the data up into packets of 4 bits each. You then concat each first, second, third and fourth letter together separately. This can be seen in the 1, 2, 3 and 4 columns. Afterwards you count the 1s in each of them (the number of ones is written beside each of them). If they are even it's a 0 for the parity bit, if they are odd it's a one. So before you are finished you now have to binary add 1 to the result from before (!). That matched every single time and I was successfully able to generate my own frames that way. Problem solved it seems. Perfect. Thanks a lot everybody for contributing.

Improve this answer
5
  • 1
    In other words, the check nibble is an XOR of all of the preceding ones.
    – Chris Stratton
    Sep 24, 2017 at 1:13
  • 1
    @ChrisStratton Pardon this question but what exactly needs to be XOR'd? I've tried each parity block from the categories but that didn't work.
    – Omegavirus
    Sep 24, 2017 at 7:26
  • 1
    XOR each of the nibbles into an accumulator which is initially zero and you will have your answer. This leaves you with a one in each bit position if the number of ones in that position is odd.
    – Chris Stratton
    Sep 24, 2017 at 15:50
  • 1
    Mere optimization - you figured out the requirement yourself:-)
    – Chris Stratton
    Sep 24, 2017 at 19:36
  • @ChrisStratton Right, however the XOR approach is obviously the correct one and I implemented it easily that way in python. Anyway, the +1 at the end was still necessary. Do you know why?
    – Omegavirus
    Sep 24, 2017 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.