I have a pair of chinese rave glasses that can display scrolling text, bitmaps, or animations. They also make you look way too cool for school.
They speak Bluetooth to a shady APK, I've put it on a disconnected phone and I'm reverse engineering the protocol. https://queer.af/media/kPpwoBGP0l_uV41DNcs
By the way, this is from Cyberdog, if anybody wants a pair: https://www.cyberdog.net/products/rave-glasses
I also have one of these collars, which is next once I finish this: https://www.cyberdog.net/collections/accessories-light-up/products/future-collar?tag=
Here's the catch: the GATT collection only includes a single descriptor (0004), and it's not writable.
Wireshark shows that the app, when you toggle them off and on, sends a GATT Command write (0x52) to handle 0x0003, with value: 01 00 02 06 09 02 05 03.
I'm not sure how to coerce BlueZ to let me do this.
@embr bluepy is somewhat unstable but I had success with it talking to BLE devices
@embr @uint8_t oooh ble I did that once upon a time! Wireshark should be able to do a capture (I know it works on Linux, hcidump or sudo wireshark, suspect it works on macos and maaaaybe on Windows too? You can capture in another app and load in Wireshark for analysis anyways.)
It's possible that your Android ble stack is caching stuff that it retrieved when the device first paired, so you might get more handle descriptors if you can get it to forget that cache and capture the initial handshake. It's also possible/likely that the sketchy apk just has handles hardcoded.
You can probably poke at struct internals to force bluepy or the C BlueZ bindings to send writes to the handles you already figured out even if the GATT server doesn't provide a valid query response describing them.
I am not finding any of my old source code to refer to alas ... Will dig a little bit more.
Also, I now want a pair of those glasses.:)
Generalistic Mastodon instance for open-minded people. Instance Mastodon généraliste pour personnes ouvertes d'esprit.