My motorcycle has a Bluetooth instrument cluster. It pairs with the manufacturer's phone app and shows turn-by-turn navigation right on the dash, which sounds great until you actually use it. The nav is routed through a maps provider I don't love, the app is clunky, and there's no way to extend any of it.

I kept thinking: it's just my bike talking to my phone over Bluetooth. How locked down can it really be? So one weekend I decided to find out, and a few weeks later I had Google Maps navigation running on the cluster through an app I wrote myself.

Here's how that went.

There are no docs

Of course there aren't. It's a proprietary protocol, and the only reference that exists is the manufacturer's own app, in compiled form. So step one was just watching.

I started with a GATT walk on the live bike, which is the Bluetooth equivalent of knocking on every door to see what's there. The cluster exposes one vendor service with two characteristics: one the phone writes to, one the bike sends notifications back on. That's the entire conversation surface.

Then I captured the actual bytes going across. Android can log every Bluetooth packet through its HCI snoop log, so I paired the phone with the bike, rode around, and pulled the capture. Now I had real traffic, and absolutely no idea what any of it meant.

Reading the app to read the protocol

You can stare at hex forever and still guess wrong. The faster path was the app itself. I pulled the APK, ran it through JADX to decompile it, and got something close to readable source. Most of the class names weren't even obfuscated, which was a gift.

From there it was cross-referencing: take a message I saw on the wire, find the code that builds it, and work out what each byte is. Frida helped a lot here. It lets you hook a running app and watch functions get called with their real arguments, so I could catch the exact moment the app turned "next turn is a left in 200m" into bytes and shipped them to the bike.

Slowly the shape came out. Every message is exactly 30 bytes: a fixed header byte, an ASCII character for the message type, a body, a checksum, and a terminator. I confirmed the checksum the right way, by finding the function that computes it in the decompiled source, instead of reverse-guessing it from samples. The bike turned out to be response-driven too. It sends nothing until the phone writes to it first, which is why a passive listener captures total silence and had me convinced the thing was dead the first time I tried.

Being wrong, on the record

The part I'm actually proud of isn't the protocol. It's how often I was wrong along the way and caught it.

Early on, a Bluetooth analyzer confidently labeled the bike's characteristics as a known digital-key security spec. I almost wrote that down as fact. It was just the tool pattern-matching on a UUID and guessing. The real thing was a plain vendor service with nothing fancy about it.

I also assumed for a while that the bike had its own SIM and was quietly phoning telemetry home to the manufacturer's cloud, which shaped a whole chunk of my thinking about where data came from. Then I actually checked the hardware and the spec sheet. No SIM. The bike talks to nothing but the paired phone. That one assumption had been steering me wrong for days.

So I started keeping a running log of every claim: what I assumed, what turned out to be true, and what evidence corrected it. Reverse engineering is mostly the discipline of not believing yourself too early.

Then I built the app

Once the protocol was understood, the fun part. REDLINE is an Android app in Kotlin and Jetpack Compose. It intercepts Google Maps turn-by-turn notifications, encodes each maneuver into the cluster's frame format, and writes it over Bluetooth, so the dash shows Google's directions instead of the stock app's. On top of that it reads the telemetry the bike emits and turns it into a live dashboard, records every ride with stats and a speed graph, exports trips, and renders a clock to the cluster when nav is idle.

It's about 14k lines, 205 tests, and runs entirely on the phone with no account and no cloud. The same frame inspector I used to reverse the protocol ships inside the app, because the work isn't really finished.

What it taught me

The protocol was never the hard part. The hard part was staying honest: treating the analyzer's label as a hypothesis, checking the hardware instead of trusting the spec in my head, writing down the wrong turns so I wouldn't repeat them. That habit has quietly made me better at regular software work too, where the bug is almost never where you first assume it is.

If you want the full breakdown, the frame formats, the tooling, and the walked-back assumptions, it's all written up here: https://www.arjunp.pro/projects/suzuki-connect-re.html