Reverse engineer BLE LED strip protocol

Question

I am trying to create a custom application to control some Bluetooth-controlled LED strips. That is, I would like to reverse engineer how they are controlled without having any datasheet -- I'll figure out the control software itself later. There are a number of tutorials out there, but I have come up against a problem when trying to command them myself.

The LED strips are made by GUPUP (?) and the documentation I've been able to find just describes how to use them with their own app.

I have learned a bit about BLE and GATT and have gotten to the point where I can see a powered-up strip on nRF Connect (on an iPhone) and the services it advertises. There is just the one with an unnamed Notify characteristic and an unnamed Read/Write characteristic:

These are consistent with what I see in LightBlue (another iPhone Bluetooth scanner):

There are plenty of tutorials out there where at this point, I would just write to the writable characteristic and change the color, but I get stuck here. When I try to write to it, not only does the strip not react, the value of the characteristic doesn't even seem to change. The log files from the apps show the write requests, but I can't get the value to be anything other than what you see there: 3031 3233 3435 3637 3800

Meanwhile, I can change the color using either the provided remote (which looks like the same one all Bluetooth LED products come with, but cannot control another Bluetooth LED I have) or the manufacturer's app ("Allbest Home" for iPhone). Those changes do not alter the writable characteristic's value, either, but they do trigger a message sent back on the Notify characteristic when I change something.

So unless I am scanning and/or writing to the characteristic wrong, it seems like these LED strips are controlled in some way that is more complex than just asynchronously writing RGB-encoded bytes. Not sure if it's a coincidence, but the characteristic value that won't change seems to just be the null-terminated string "012345678" in ASCII.

Any clues or leads for me to follow? Is there a time-based protocol (send this, then that, then the next thing, etc.)? Is it actually accepting my writes, processing them, but then overwriting the characteristic with "012345678" immediately after? In that case, I'd need to guess at the proper structure of the characteristic value since I can't get any feedback on successful requests other that a change in the lights themselves.

I have seen third-party apps for controlling similar LED strips, so there must be people out there who have cracked them, but I am out of guesses for what to search for.

I have ordered a Nordic BLE sniffer, but thought I'd post this while I wait in case someone has some insight.

Answer 1

UPDATE AND SOLUTION

After getting the Nordic nRF52840 Dongle working to sniff BLE packets, I was able to capture and decipher enough ATT packets from the manufacturer's app to the LED controller to learn what I needed to. I was also able to write a Windows console app to send commands. Here are some takeaways in case someone sees this in the future:

• The nRF dongle can be fiddly. The instructions from Nordic for getting it running and capturing to Wireshark are good, but there would be times where it just quit (didn't appear in the list of Wireshark options). Restarting usually fixed this - I think maybe there were problems with assigned COM ports.
• Make sure the target (GATT server) is not connected to anything else, even the nRF Connect app before you try to capture packets.
• It turns out that, yes, the controller does just write out "012345678" on the writable characteristic whether you send a successful command or not.
• FWIW, here are some example commands for this particular brand of LED strips (GUPUP):
  • The final two bytes of all commands are CRC, specifically CRC-16 (MODBUS, big endian, normal). I found this out by using this site. If you are revere engineering a different set of commands that have CRC bytes, you can input the command and check this site's outputs against captured packets.
  • Turn on: A0110401b121
  • Turn off: A011040070e1
  • Change color: A01506RRGGBBnnnn where RR, GG, and BB are hex values for the color and nnnn are the two CRC bytes
  • Change brightness: A01304xxnnnn where xx is 0 to 100 in hex
  • etc.
• This video walks through how to create a C# console app for Win 10 that talks to the a BLE device. Be warned, .NET and Visual Studio change so often that it doesn't take long for certain parts of code tutorials to go stale. In my case (in March 2024), I was unable to add Windows.Devices as done in the video. There are a few fixes for this out there that are already also stale, but what worked for me was to change the target .NET version (the TargetFramework field in the .csproj XML file) from 'net8.0' to 'net6.0-windows10.0.19041.0'. I have no idea how proper or sustainable this is - it was just the first thing I tried that worked.

Good luck, fellow reverse engineers!