Understand RC car control from decoded messages

Vasko

unread,

Feb 7, 2022, 8:23:25 AM2/7/22

to rtl_433

Hey,

I can demodulate all the messages exchanged between car and RC Controller. My question is related to understanding their content and find a generalized approach how to control all the cars from the same model.

One controller can control all the cars of the same model provided that they have done pairing procedure before. I am not understanding how the messages are being formed based on the pairing procedure.

The pairing procedure is basically done as follows:

Controller is transmitting certain message on pairing channel
The car is responding on the same channel
When controller gets the message from the car, it transmits certain message (different from previous messages) on channels used for communication, also this message is further used as a stop message for the car. Note: communication channels are different for each car model.

This finishes the pairing procedure
After that they have a certain instance of messages that work with this car
So the idea is to understand how to generalize it. Any experience with hacking RC cars? Any help would be highly appreciated.

Recorded data:

Recorded data for Cruz Ramirez_page-0003.jpg

PDF file with messages added in the attachment.

Recorded data for car hacking.pdf

Benjamin Larsson

unread,

Feb 7, 2022, 8:34:56 AM2/7/22

to rtl...@googlegroups.com

On 2022-02-07 14:23, Vasko wrote:
> Hey,
> I can demodulate all the messages exchanged between car and RC
> Controller. My question is related to understanding their content and
> find a generalized approach how to control all the cars from the same
> model.
>
> One controller can control all the cars of the same model provided that
> they have done pairing procedure before. I am not understanding how the
> messages are being formed based on the pairing procedure.
>
> The pairing procedure is basically done as follows:
>

> 1. Controller is transmitting certain message on pairing channel
> 2. The car is responding on the same channel
> 3. When controller gets the message from the car, it transmits certain

> message (different from previous messages) on channels used for
> communication, also this message is further used as a stop message

> for the car. /Note: communication channels are different for each
> car model. /

>
> This finishes the pairing procedure
> After that they have a certain instance of messages that work with this car
> So the idea is to understand how to generalize it. Any experience with
> hacking RC cars? Any help would be highly appreciated.
>
> Recorded data:
>

> Recorded data for Cruz Ramirez_page-0001.jpg

> Recorded data for Cruz Ramirez_page-0002.jpg

> Recorded data for Cruz Ramirez_page-0003.jpg
> PDF file with messages added in the attachment.

Well I have a hard time following what you are doing. Either post some
signal recordings with a matching flex command to get to the bit stream
or elaborate in more detail.

That aside the pairing logic can have a huge complexity. Your time is
probably better spent looking at the code logic for the car or controller.

MvH
Benjamin Larsson

Vasko

unread,

Feb 7, 2022, 9:02:59 AM2/7/22

to rtl_433

Hey Benjamin,

Thanks for the answer. I understand that it can have huge complexity. I think it only makes sense if they are using some common approach or something hopefully not that complex, since the toy is not that expensive at all.

The thing is that the signals are in the GHz domain, so I am using HackRF together with nRF chips to decode them more or less easily, but I was hoping you can help with the meaning of the signals, since the demodulation part is not a problem in this case.

I am using HackRF to check for initial frequences that the car is transmiting during the pairing and the communication. Afterwards I extract the initial 5 bytes of the message (I refer as address) and listen to the data exchanged with nRF tuned for those frequencies and for the addresses accordingly. I am combining output from different devices into this file.

I have decided to record bunch of data from different pairing and communication instances. For each pairing instance I am recording the data I have described here:

> The pairing procedure is basically done as follows:
>
> 1. Controller is transmitting certain message on pairing channel
> 2. The car is responding on the same channel
> 3. When controller gets the message from the car, it transmits certain
> message (different from previous messages) on channels used for
> communication, also this message is further used as a stop message
> for the car. /Note: communication channels are different for each
> car model.

And also one of the regular commands - move RIGHT.

To better explain lets take this pairing instance (all the pairing instances are devided by the empty line space). Here is one whole pairing instance:

First message is the message transmitted by the controller (when first time turned on - pairing mode). It is transmitted on channel 60 (PAIRING CHANNEL).
Underneath you can see its bit representation. Important to note: the first 5 bytes of this message correspond to hex values represented in the table above in PAIRING_ADDRESS (I refer to it as address)
Second message is the response from the car. It is transmited with the same 5 bytes (address) as the message from controller and the same channel (PAIRING CHANNEL).
Third message is the response from the controller. It is transmitted with first 5 bytes corresponding to COMM ADDRESS and it is being transmitted on COMM CHANNELS (channels used for communication) indicated in the table of the paragraph. Note: Same message is used as a STOP command (command being sent after any regular command to indicate that the user released the RC controller button)
Forth message is the regular message used to control the car to move RIGHT.

Hope this helps clarify things.
They use some unlabeled controllers for the board of RC controller and of the car - no code is available aswell. I can try checking the communication lines, but I assume I will just see exchange of the data, not the logic how the data is being generated.

Best,

Vasko

Benjamin Larsson

unread,

Feb 7, 2022, 9:18:46 AM2/7/22

to rtl...@googlegroups.com

On 2022-02-07 15:02, Vasko wrote:
> Hey Benjamin,
> Thanks for the answer. I understand that it can have huge complexity.

[...]

> no code is available aswell.

There is always code. It just depends on how hard it is to get it.

Anyway 2.4GHz sounds like something out of the Nordic Semi 5 Series.
Their chips have flaws IIRC. I would look in that direction. At least
try do document the components.

The pairing logic is tricky even if it is easy. With source you have a
fighting chance. Anyway I would look into the drone community maybe they
have something similar.

> Best,
> Vasko
>
MvH
Benjamin Larsson

Christian Z.

unread,

Feb 7, 2022, 10:27:21 AM2/7/22

to rtl_433

It might be easier to dissect the codes in a BitBench (example below). There is not too much entropy, so there should be (some) plain text data.

A first question would be if this is the raw on-the-air data, or if some framing and checksum is already removed? I.e. are the bytes aligned and should there be a checksum still?

https://triq.net/bitbench#c=%5BData%20comparison%20Car%20160617%5D&c=%5BPAIRING%20CHANNEL%2060%20COMM%20CHANNELS%2041%2C54%2C69%5D&c=C54C09192BE2B0401A022E0D936EEBFF&c=C54C09192BE1BFB4F6022E022C0A43FE&c=8D4C09192BE3A60000022C1A81B28FFF&c=8D4C09192BE3A601160A481B29B1DFFF&c=C54C09192BE2B0401A022C1ED94FA7FF&c=C54C09192BE1BFB4F6022C11662B0FFF&c=8D4C09192BE2B08034022C17C4A0D7FF&c=8D4C09192BE2B081220A48166CA387FF&c=C54C09192BE2B0401A022C1ED94FA7FF&c=C54C09192BE1BFB4F6022C11662B0FFF&c=8D4C09192BE2B0C02E022C10CFFB37FF&c=8D4C09192BE2B0C1380A481167F867FF&c=C54C09192BE2B04814425C16695EC7FF&c=C54C09192BE1BFB4F6425C116559C7FF&c=8D4C09192BE07D0000022C166A6987FF&c=8D4C09192BE07D01160A4817C26AD7FF&c=%5BNote%3A%20In%20previous%20pairing%20instance%20the%20controller%20was%20paired%20to%20the%20car%20120617%5D&c=C54C13AB16FAA2401A022C11652FE7FF&c=C54C09192BE1BFB4F6022C11662B0FFF&c=8D4C09192BE5B881220A481EDED62FFF&c=8D4C09192BE5B88034022C1F76D57FFE&f=TYPE%3F8h%20ADDR%3F8h8h8h8h%208h8h%208h8h%208h8h%208h8h%208h8h%208h

(try a format of just v to get a feel for entropy

or remove one it from the left, shift: -1, which then looks somewhat more structured, I guess)

Vasko

unread,

Feb 7, 2022, 11:20:07 AM2/7/22

to rtl_433

Hey Christian,

This is all live - on the air data. Nothing is removed except 1 byte preamble of 1s and 0s and first 5 bytes were taken as address and specified in the table above. I think ending can be considered just as 1's, sometimes 0 appear at the end, but the data is already noisy there.

I have just looked that there is some consistency among data, thats how I came up with the certain addresses (so it will be more or less aligned) and make sense - it the end I am getting exactly 22 bytes (including preamble). This is how it looks on the air when captured with hackRF:

Bytes corresponding to picture:

F555555ED5950C54C13AB16FAA24814425C19D53E87F

11110101010101010101010101011110110101011001010100001100010101001100000100111010101100010110111110101010001001001000000101000100001001011100000110011101010100111110100001111111

Great tool! I was playing a bit, but to be honest not sure how to continue. This is with addresses added to the beginning and also comments on instances:

Best,

Vasko

Christian Z.

unread,

Feb 7, 2022, 12:20:38 PM2/7/22

to rtl_433

As this is raw data, I would expect the last byte to be a checksum. Try to find similar messages, then try different alignments to get a change in the last byte that somehow fits (sum or xor, or if it's CRC it will be very random).

Currently that last byte (not the 0xff) always ends with 1's -- I'd say the alignment needs to shift 2 or 3 bits to the right.

Reply all

Reply to author

Forward