Reverse Engineering Quadcopter Protocols

Necessity is the mother of invention, but cheap crap from China is the mother of reverse engineering. [Michael] found a very, very cheap toy quadcopter in his local shop, and issued a challenge to himself. He would reverse engineer this quadcopter’s radio protocol. His four-post series of exploits covers finding the right frequency for the radio, figuring out the protocol, and building his own remote for this cheap toy.

[Michael] was already familiar with the capabilities of these cheap toys after reading a Hackaday post, and the 75-page, four language manual cleared a few things up for him. The ‘Quadro-Copter’ operated on 2.4GHz, but did not give any further information. [Michael] didn’t know what channel the toy was receiving on, what data rate, or what the header for the transmission was. SDR would be a good tool for figuring this out, but thanks to Travis Goodspeed, there’s a really neat trick that will put a 2.4GHz nRF24L01+ radio into promiscuous mode, allowing [Michael] to read the transmissions between the transmitter and quadcopter. This code is available on [Michael]’s github.

A needle in an electromagnetic haystack was found and [Michael] could listen in on the quadcopter commands. The next step was interpreting the ones and zeros, and with the help of a small breakout board and soldering directly to the SPI bus on the transmitter, [Michael] was able to do just that. By going through the nRF24 documentation, he was able to suss out the pairing protocol and read the stream of bytes that commanded the quadcopter.

What [Michael] was left with is a series of eight bytes sent in a continuous stream from the transmitter to the toy. These bytes contained the throttle, yaw, pitch, roll, and a ‘flip’ settings, along with three bytes of ‘counters’ that didn’t seem to do anything.  With that info in hand, [Michael] took an Arduino Nano, an nRF04L01+ transceiver, and a Wii nunchuck to build his own transmitter. If you’re looking for a ‘how to reverse engineer’ guide, it generally doesn’t get better than this.

You can check out a video of [Michael] flying his Wiimoted quadcopter below.

21 thoughts on “Reverse Engineering Quadcopter Protocols

          1. Which CGMS? I don’t recognize your name from one of the numerous people who have hacked up receivers for the Dexcom G4 – although there are so many people in that community I might have just lost you in the noise. If that’s the case, sorry.

  1. Protip for the future: first step to reverse engineering nRF24-based toy quadcopter protocols is to try the many protocols already supported by the popular nrf24multipro (https://github.com/goebish/nrf24_multipro) arduino firmware for full-size RC transmitter modules. The one desccribed in this article and Michael’s code on github is the YD717 mode supported by nrf26multipro, except that latter implementation seems cleaner and more flexible.

    https://github.com/m-melchior/QC-360-A1/blob/master/src/Arduino/myRF24RC/myRF24RC.ino
    https://github.com/goebish/nrf24_multipro/blob/master/nRF24_multipro/YD717.ino#L72

    Same applies for A7105 based toy quadcopters, there’s transmitter code for those. I was suprised how much more flying precision I could get with a real transmitter compared to the stock ones that come with the toy. You can also reprogram the quad itself to support multiple stabilisation modes and use them like flight simulators to learn rc piloting.

    1. That applies to a lot. You can make informed guesses, and then see if the guess fits. If it does, it speeds things up. If it doesn’t, the information you already have will rapidly dismiss the guess.

      So if you think that IC is such and such, if the ground pin is wrong, then no sense going further. But if it is ground, checking for other pin matches is faster than tracing it all out and then looking up ICs. Sometimes the field of candidates is small.

      Michael

  2. Protip for the future: first step to reverse engineering nRF24-based toy quadcopter protocols is to try the many protocols already supported by the popular nrf24multipro arduino firmware for full-size RC transmitter modules. The one desccribed in this article and Michael’s code on github is the YD717 mode supported by nrf26multipro, except that latter implementation seems cleaner and more flexible.

    compare github.com/m-melchior/QC-360-A1/blob/master/src/Arduino/myRF24RC/myRF24RC.ino
    to github.com/goebish/nrf24_multipro/blob/master/nRF24_multipro/YD717.ino#L72

    Same applies for A7105 based toy quadcopters, there’s transmitter code for those. I was suprised how much more flying precision I could get with a real transmitter compared to the stock ones that come with these toys.

  3. When you see “counters that don’t do anything” in a streaming protocol, a reasonable first guess is that they might be used in some sort of a missing packet detection scheme.

  4. Even the high-end drones with cryptography aren’t that hard to RE. The firmware isn’t protected by DRM so you just implement frequency or trunking compatibility and log everything, or just build entirely from binary or source analysis.

  5. I’m trying to detect a drone with an XN297 transceiver chip using grc and a HackRF. However, I can’t seem to get a clear waveform. Can anybody help me out? I’m willing to compensate for the help.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.