Play Sound silently no-ops on a real third-party accessory (RAVEMEN ABF01) - likely needs BLE encryption Android can't provide #193

Activity

1. LiamJ74 commented on Sep 13, 2026

   

   LiamJ74

   on Sep 13, 2026

   ContributorAuthor

   More actions

   Update: found the exact protocol byte-for-byte (from a real iOS sysdiagnose), still no sound on Android

   Since opening this issue I captured a full iOS sysdiagnose (system logarchive, not just the BLE HCI trace) while triggering "Play Sound" against the same RAVEMEN ABF01. locationd tags every write to the 4F860002 characteristic with an internal task name, which resolves the exact command sequence unambiguously (previously this was reverse-engineered from raw bytes alone, without knowing what each write actually meant to iOS):

   0x01 0x09 0x02  →  "HE(T) Get Multi Status"     (sent first - a status query, not a start)
   0x01 0x00 0x02  →  "HE(T) Play Sound Sequence"  (sent second - this is the actual trigger)
   0x01 0x01 0x02  →  "HE(T) Stop Sound"           (sent ~2.7s after Play Sound Sequence)
   

   This is a correction to what was previously documented: the order was reversed (the "status" opcode was assumed to be the real start), and there is in fact an explicit stop opcode (previously assumed to not exist, with the real client just disconnecting instead).

   I implemented this exact corrected sequence in a test build (same 4-characteristic indication subscription, then the three writes above in the right order, each gated on the previous one's write callback firing before sending the next). Every write is acknowledged by the accessory at the ATT level, in the same order as the real iPhone. The accessory still does not make any sound.

   This is stronger evidence for the conclusion in the original post: the accessory's firmware is almost certainly gating on link encryption (a pre-shared LTK Apple devices obtain out-of-band, e.g. via iCloud Keychain sync from the accessory's initial pairing), not on the specific bytes written. Getting the application-layer protocol byte-perfect changes nothing, because the write itself is accepted and acknowledged either way - it's what the firmware does after accepting it that differs based on whether the link is encrypted.

   Not claiming this closes the door on a fix - just documenting that the protocol-level explanation can be ruled out now that it's been replicated exactly, leaving link encryption as the remaining candidate.
2. LiamJ74 commented on Sep 13, 2026

   

   LiamJ74

   on Sep 13, 2026

   ContributorAuthor

   More actions

   Update: attempted to directly prove the link-encryption theory via a rooted device, blocked by a kernel limitation

   To try to directly confirm the link-encryption theory rather than just infer it, I attempted the following on a separate rooted Android device (Magisk, with the Kali NetHunter chroot installed), specifically to avoid touching any device with real paired accessories:

   1. Captured a real LTK for this exact accessory from an iOS HCI trace (HCI_LE_Start_Encryption, correlated to the same connection handle that then discovered the FD44 GATT service - so this is confirmed to be the accessory's actual key, not another paired device's).
   2. Cleanly stopped Android's own Bluetooth HAL service (stop vendor.bluetooth-1-0-qti, not just svc bluetooth disable which leaves the HAL process running) to free up the internal chip's UART without the two Bluetooth stacks fighting over it.
   3. Tried to attach BlueZ to the now-free internal chip (btattach -B /dev/ttyHS0 -P qca), intending to use btmgmt's LTK-injection support (ltk-add) to load the real key without going through SMP pairing, then issue the GATT writes from bluetoothctl/gatttool to see if the accessory would actually sound with a correctly-encrypted link.

   Step 3 failed cleanly: Failed set serial line discipline: Invalid argument. This device's Android kernel does not build in the standard Linux N_HCI line discipline (CONFIG_BT_HCIUART) that BlueZ's userspace tooling needs to attach to a UART-connected Bluetooth controller - it's been left out in favor of the vendor's own userspace HAL implementation, which is a closed path with no equivalent LTK-injection capability exposed to apps or shell.

   So: root access alone isn't sufficient to test this hands-on, on stock Android kernels at least. Getting further would need a custom-built kernel with that line discipline enabled, which is out of scope for this investigation. Documenting this so it's clear this avenue was tried, not skipped - and so anyone else who has a device with a custom kernel/BlueZ-capable Bluetooth setup knows what to try to get a fully hands-on confirmation.
3. parawanderer commented on Sep 13, 2026

   

   parawanderer

   on Sep 13, 2026

   Last edited by parawanderer

   Owner

   More actions

   An initial overview from @parawanderer and Claude Code, having read this against the DULT draft, a vendor Find My SDK and AirGuard's source.

   Your conclusion holds for the owner path. 4F860002 is the owner's configuration control point. In a vendor Find My SDK (ble_fmy.c), a paired accessory treats an unencrypted connection as a non-owner and disables 4F860002 for it, and switches to owner mode only once encryption succeeds. The comment there says any phone on the paired Apple ID can encrypt, so the bond key belongs to the account. Zero EDIV and Rand is also what an LE Secure Connections bond looks like on reconnection, which fits a stored bond being resumed rather than a key derived fresh each time.

   4F860003 is a different interface with a different gate. It is the non-owner control point: 01 00 03 there mirrors your 01 00 02 on the owner side, and it is what AirGuard writes. Per the DULT accessory draft, non-owner Sound_Start works over an unencrypted link but "SHALL only be available … when the accessory is in the separated state", and is answered with Invalid_command otherwise. Every test here had the owner's iPhone next to the accessory, which is the one state where that write cannot work.

   @parawanderer's understanding from #139 is that @ubrt got a third-party accessory to ring through that path while it was separated from its owner. @ubrt can confirm. If so, the non-owner path may cover most users of this app, who usually have no Apple device near their tag.

   The test that would settle it for the ABF01: take every device signed in to its Apple ID out of range (or turn Bluetooth off on each), wait for it to go separated, then write 01 00 03 to 4F860003 while subscribed to indications on it, and read the Command_Response rather than listening for a sound.

   One small correction: in that SDK, 94110001 is the firmware update (UARP) characteristic rather than a vendor service.

   Your findings are now summarised in docs/owner-connected-tags.md (#202), which is the index for ringing a tag near its owner. If you'd like, feel free to open PRs adding to that document yourself. #201 now tracks the owner-connected case as a whole.

   Interactively co-authored by Claude Code and @parawanderer
4. parawanderer

   added a commit that references this issue on Sep 13, 2026

   Merge pull request #202 from parawanderer/docs/owner-connected-ringing

   ...

   883939b
5. parawanderer

   added a parent issue on Sep 13, 2026

   • Play Sound on a tag that is near its owner (owner-connected mode) #201
6. parawanderer

   added

   @hardwareTalking to tags and accessories directly over Bluetooth: scanning, ringing, protocol capturesTalking to tags and accessories directly over Bluetooth: scanning, ringing, protocol captures

   @appIssues regarding the OpenTagViewer Android appIssues regarding the OpenTagViewer Android app

   on Sep 13, 2026
7. LiamJ74 commented on Sep 26, 2026

   

   LiamJ74

   on Sep 26, 2026

   ContributorAuthor

   More actions

   Update: got the injection mechanically working, but it crashes the Bluetooth stack rather than producing sound

   Further progress on the rooted-device proof-of-concept from the previous update.

   What's confirmed working now:

   • Captured the accessory's current LTK from a real iOS HCI trace multiple times (it rotates - both the BLE address and the LTK change on the order of minutes, not the hours/days an earlier single-session comparison suggested).
   • Using Frida on a rooted phone (custom kernel, hci_uart/btqca/btbcm present), hooking write() on the process that owns the Bluetooth UART revealed something not obvious from any documentation: this HAL does not write a full H4-framed HCI packet in one write() call. It writes the 1-byte H4 type (0x01 Command, 0x02 ACL Data) in its own separate call, then the packet body in the next call, with no type byte. Any tooling assuming one write() = one packet (ours included, initially) will silently never match anything.
   • Once that framing was accounted for, we could reliably detect the first ATT-layer packet on any new connection handle and, in response, construct and send a genuine HCI_LE_Start_Encryption (opcode 0x2019) directly to the controller - using the real captured LTK - without ever calling createBond() (which the accessory refuses outright, see the previous update).
   • The write succeeds: the controller accepts the raw HCI command and there's no ATT-level error.

   What happens next: the Bluetooth HAL process crashes.

   Shortly after the injected command, the process handling the UART terminates and Android restarts it automatically (recovered cleanly, no reboot needed). No sound. The most likely explanation: Bluedroid's own state machine tracks in-flight HCI commands and expected responses per connection, and receiving an Encryption Change event it never itself requested - for a command it has no record of sending - is enough to violate an internal invariant it isn't written to tolerate.

   So the encryption command genuinely reaches the controller with the correct key material, which is further confirmation of the root cause - but doing this cleanly from a normal HAL process appears to need real cooperation from the Bluetooth stack (a proper local HAL/stack patch that intends to do this, rather than injecting from outside it), not a hook layered on top after the fact. Still an open problem, not a dead end - picking this up again.

   👀React with 👀1Reacted by Shane B.
8. Hello1024 commented on Oct 11, 2026

   

   Hello1024

   on Oct 11, 2026

   More actions

   Keep going AI, you can do it!

   Might be handy to test playing sound from a linux laptop first where you get far more control of the bluetooth stack.... Figure out exactly what needs to be sent, and later figure out if android can be made to do the sending...

   👍React with 👍1Reacted by Shane B.
9. parawanderer commented on Oct 13, 2026

   

   parawanderer

   on Oct 13, 2026

   Owner

   More actions

   @LiamJ74 — thanks for looking into this; the captures and the rooted attempts above are the most direct evidence anyone has produced on this question. If you want to go looking for the source of the certificate in your own iCloud account, a script for that now exists — sweep_keychain_for_bytes.py in the FindMy.py fork's examples. It signs in, recovers the trust circle, and searches every keychain view the account can read for a byte needle you supply, reporting where a match is. One caveat before you build anything on it: sign-in itself is currently broken ecosystem-wide (-80045, Apple refusing at the first step since 2026-10-12), so the script may not get past sign-in until that is understood.

   Drafted by Claude Code, reviewed by @parawanderer
10. saamdotexe

    added 2 commits that reference this issue on Oct 22, 2026

    Record the two Find My control points, from @LiamJ74's parawanderer#193…

    ...

    5acb246

    Merge pull request parawanderer#202 from parawanderer/docs/owner-conn…

    ...

    f7d5c03