Now if you compare the apps that ship with each model, you’ll see they’re nearly identical. This suggests the hardware all comes from the same manufacturer, meaning unlocking one model may actually unlock many. QuadKit was built for communicating with quadcopters, but with a generic approach not coupled to the requirements of any one brand or model, should my one-size-fits-all hypothesis fail. By making it open source, there’s flexibility for developers to provide their own support for individual models.

My first approach was to reverse engineer the mobile apps to see how they worked.

Starting with what I knew, I attempted to get a sense of the app’s structure using class-dump to get a list of class interfaces. By SSH’ing into a jailbroken device, I could use various tools like dumpdecrypted and Clutch to produce a decrypted binary while the app ran in memory, then use class-dump to get a comprehensive list of headers. This gave me a decent sense of the app’s architecture.

By hosting an lldb-server to remotely debug the app while it ran in memory, I was able to use the class-dump headers to know where to send messages and where to record results. This gave me a sense of where and how data was sent and received.

Disassembling the decrypted binary using Hopper then allowed me to view something that kind of resembled source code. This revealed the front-end being written in native code, but all the useful networking logic in C (and possibly Assembly, but that may have just been part of the disassembly process). The result was too garbled to be of much use, mostly nightmarish stuff like this:

After spending about a week trying to rewrite everything in Objective-C (and not getting very far), I decided to do some research into looking for an approach which wouldn’t require source code. Unsurprisingly, the hardware hacking community has been all over toy quadcopters for a few years now, and I found a huge number of quality resources basically documenting what I was trying to do, usually using an Arduino. By finding the right radio frequency then reverse engineering the communication protocol, Michael Melchior was able to use a Wii remote to fly his toy quadcopter.

Thanks to the immense amount of available documentation and guidance, I was able to follow Jim Hung’s article on Reverse Engineering a Hubsan X4 Quadcopter (as well as his super handy protocol specification) to flesh out a Swift framework which followed the same protocol, but, instead of communicating over radio, sent data over socket connections.

An interesting point which reenforces the one-size-fits-all hypothesis from before is that although everything he wrote was for a completely different brand of quadcopter, it aligned perfectly with the data I was seeing. If this actually turns out to be the case, I imagine there could be a lot more potential for others to use QuadKit to help build quadcopter software.

What’s next?

QuadKit is publicly available on Github, with step-by-step instructions for how to contribute, as well as how to record data from your quadcopter using free tools. In the future, I’d like to work on adding first-person video support, specifically for models which come with cameras, which could make the platform even more compelling.

As for SCARAB, I’d like to re-investigate watchOS in the near future, as there may be a lot of potential for interesting new ways to provide controller input outside of dual analog stick-style control schemes. For the time being, it can be downloaded for free now from the App Store.

If you have any questions or liked/disliked something here, feel free to contact me via email at hi@gabrieloc.com or on Twitter at @_gabrieloc!