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

[LiamJ74]

Context

Testing BleGattSoundTrigger (from #139) against a real-world "Licensed 3rd Party Find My Device" accessory: a RAVEMEN ABF01 bike finder. The GATT write completes successfully (Write Response, no error), but the accessory never actually plays a sound.

What real capture shows the actual protocol to be

Captured the iPhone's own HCI trace for a successful Play Sound against this same accessory (PacketLogger + Apple's iOS Bluetooth logging profile). Two things stood out:

1. The characteristic AirGuard documents (4F860003) isn't the one this accessory uses. The iPhone subscribes to indications on all four fd44 characteristics (4F860001-4) plus one on a second, vendor service (FD43 / 94110001), then writes two opcodes in sequence to 4F860002:

   • 01 00 02 (a handshake/query write - the client always sends this first)
   • 01 09 02 (the actual start-sound opcode)

   There's no separate stop opcode - the client just disconnects after ~30s and that ends the sound. The accessory also proactively sends unsolicited indications on 4F860002 reporting its own state (01 0D 02 = idle, 01 0C 02 60 00 00 00 = sounding).

2. Reproducing this exact byte sequence from Android still doesn't work. Implemented the full sequence above (all 4+1 indications, both writes, in order) - GATT-level success throughout, but the accessory stays silent. Captured Android's own HCI snoop log (Enable Bluetooth HCI snoop log in Developer Options) for the same attempt and compared it against the iPhone's trace side by side:

   • The iPhone, immediately after connecting, issues HCI_LE_Start_Encryption with a stable, pre-shared LTK (the same value across multiple separate sessions) and RAND/EDIV both zero - i.e. no SMP pairing exchange happens at all. The key is already known to both sides out-of-band, presumably derived from the same account-level Find My master key that produces the OF rolling public keys.
   • The Android capture shows zero encryption or SMP activity whatsoever for the same connection. The GATT write is accepted at the ATT level regardless (no permission bit enforces encryption on the characteristic), but the accessory's firmware appears to gate the actual sound on the link being encrypted with its expected key - a check that has nothing to do with ATT permissions.

Android's public BluetoothGatt/BluetoothDevice API has no method to request encryption with an app-supplied LTK - createBond() is the only path to an encrypted link, and it negotiates a fresh key via standard SMP pairing rather than using a pre-known one. As far as I can tell this makes it impossible for a non-rooted third-party Android app to replicate what Find My/the native app does here, for this class of accessory.

(For due diligence: also tried directly injecting the captured LTK into a rooted test device's Bluetooth bond store, to confirm this conclusively by side-stepping the API gap entirely. Ran into the OS's own Bluetooth HAL and a userspace BlueZ stack fighting over the same radio, which crashed the test device before producing a clean result - so this is corroborating evidence, not a confirmed proof.)

Why post this

Not claiming this is unfixable - just documenting what was actually observed in case:

• it explains other "connects fine, never sounds" reports against third-party accessories,
• someone has a workaround I haven't thought of (a different Android-side approach, a way to get the account's derived LTK into the stack, etc.),
• it's useful context for anyone picking this up later.

Happy to share more of the raw capture if useful. Credit to SEEMOO Lab's AirGuard for the original fd44/DULT/AirTag protocol reverse-engineering that #139 (and this investigation) built on.

[LiamJ74]

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.

[LiamJ74]

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.

[parawanderer]

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