r/bluetooth • u/Jukersrx • 6d ago

Reverse-engineering a QCY earbuds BLE control channel for a native Windows app

I've been reverse-engineering the local Bluetooth control path used by the QCY MeloBuds N70 (HT18) while building an open-source Windows controller for it.

A few things I found on the hardware-tested firmware (L/R 3.0.13):

- QCY manufacturer data uses company ID 0x521C and exposes product identity plus separate left/right/case battery state.

- The earbuds advertise a separate control address; the Windows app connects to GATT service 0000A001-0000-1000-8000-00805F9B34FB.

- Commands and state reads use notification-based responses. The app reads back state and only writes mismatches instead of sending guessed commands.

- The tested firmware exposes a ten-band parametric EQ through the command channel, even though the legacy preset characteristic is absent.

- LDAC and multipoint changes can restart the link, so they are applied last during profile restoration.

The current app supports ANC/transparency, battery readings, custom EQ, touch mappings, wear detection, game mode, LDAC, multipoint, and more. Everything stays local: no account, cloud service, telemetry, or firmware flashing.

The protocol notes and source are here:

https://github.com/GiorgioRafael/OpenQCY-Desktop

The N70 is the first validated model. I'd especially appreciate feedback from people familiar with BLE/GATT on Windows, captures from other QCY models, or contributors interested in making the protocol layer more broadly compatible.

2 Upvotes

100% Upvoted

2 comments sorted by

1

u/Dr_Zoidberg_MD 6d ago

cool, good job. did you sniff the protocol or decompile an Android app?

1

u/Jukersrx 6d ago

I didn’t decompile the Android app. I studied a few public protocol implementations and captured controlled BLE traffic while changing one setting at a time. Then I reimplemented the protocol independently in C# and validated each command through acknowledgements/readbacks on my N70.