Part 2: Communication interfaces
The Ronin provides (and internally uses) multiple different communication interfaces, but which mostly seem to use a single data format (“application layer”, if you will).
CAN Bus
Both the flat contacts on the side mounts of the head unit, as well as the dupont pins on the focus wheel can be used to access the Controller Area Network Bus, used by most parts of the device internally. The relevant pins on the side mount are H and L (CAN is a differential protocol, so these stand for High and Low), but the focus wheel gives you access to only the H pin.
Having only one pin isn’t usually enough to transmit a valid CAN message (you need to drive the both pins in the differential pair), but it’s definitely possible to read from it. A cheap logic analyzer confirmed that we were dealing with a CAN bus and gave us the first look at the messages passing between the devices.
The most important part, of course, are the data bytes and one thing really quickly stood out: the vast majority of them began with 0x55. Could this be a message header? One CSV export and dirty Python script later and that theory seemed pretty good – the messages, naively reconstructed by concatenating packets until a 0x55 byte in the first field was hit, were very consistent in their length, which is usually a good sign. What the data meant was still anybody’s guess at this point, but more on that later.
Bluetooth (mobile app)
Rather annoyingly for a web developer like me, the Ronin Android app uses Bluetooth and not a TCP/IP protocol over Wi-Fi, which is what I’m mostly familiar with. Naturally, knowing nothing about Bluetooth, my first instinct was to decompile the app and try to learn about the protocol by reading the source code. But if there’s anything I know less about than Bluetooth, it’s reverse-engineering ARM assembly, which is what the app primarily consisted of (all the Java I saw was a thin wrapper to load a bunch of .so files).
Quite soon, however, I came to the incredible, but in hindsight unsurprising discovery, that not only could good old Wireshark analyze Bluetooth captures – it came with a utility for capturing traffic from Android devices in real time! Despite being back on home turf, however, I still very quickly discovered that I had gotten far too spoiled reverse-engineering web apps with nice English JSON fields, as all I saw was another endless stream of byte strings. But look at the beginning! It’s always 0x55! And it’s about the same length too… Could it be?
Yes, it could. Despite the different protocols surrounding it, the data contained in both the Bluetooth and CAN bus messages is exactly the same. But what is it? Well that’s what Part 3 is for!