applecontinuity

Overview ¶

Package applecontinuity decodes Apple Continuity BLE advertisement payloads — the Manufacturer-Specific-Data blob Apple devices broadcast for Handoff, AirDrop, Nearby Info / Action, AirPods proximity pairing, iBeacon, Hey Siri, and the other ad-hoc connectivity primitives that make the Apple ecosystem feel "magical" on a sniffer.

Wrap-vs-native judgement

Native. The Continuity protocol is undocumented by Apple
but has been extensively reverse-engineered: Mertens et
al. (furiousMAC, 2019), Stute et al. (TU Darmstadt 2019-
2024), AppleJuice, hexway/apple_bleee, and the
Wireshark dissectors all converge on the same TLV
structure and the same per-type field semantics. The
wire format is a tight Type/Length/Value walker — no
crypto, no variable-length integers, no compression at
this layer. Operators paste the Manufacturer Specific
Data bytes (post-Apple-Company-ID 0x004C) from a
Wireshark BLE capture, a Sniffle/CatSniffer dump, an
hcidump trace, or any BLE scanner and inspect every
documented field.

What this package covers

• Outer envelope tolerance: the input may be the raw TLV stream (e.g. "1005...10 05..."), the post-CompanyID manufacturer data ("4C00 10 05..."), or the full advertising-data record ("0BFF4C00 10 05..."). The walker auto-detects each form and strips down to the TLV bytes.

• TLV walking: each message inside the stream is (Type[1] + Length[1] + Value[Length]). Multiple messages per advertisement are common (e.g. Nearby Info + Handoff frequently appear together).

• Type table (per furiousMAC + AppleJuice + Wireshark): 0x02 iBeacon (RFC-equivalent: Apple's own spec, publicly documented as the iBeacon protocol) 0x03 AirPrint 0x04 AirDrop 0x05 HomeKit 0x06 Proximity Pairing (AirPods / Beats / etc.) 0x07 Hey Siri 0x08 AirPlay Source 0x09 AirPlay Target 0x0A Magic Switch (Apple Pencil) 0x0B Watch Connection 0x0C Handoff 0x0D WiFi Settings Target 0x0E Tethering Target (Instant Hotspot) 0x0F Nearby Action 0x10 Nearby Info

• Per-type body decoding (best-effort, headline fields):

• iBeacon (0x02, length 21): UUID (16 bytes hex) + Major (uint16 BE) + Minor (uint16 BE) + TX Power (int8 dBm). The canonical Apple-issued spec.

• Handoff (0x0C, variable): Clipboard-state byte + IV (2 bytes) + AuthTag (1 byte) + Encrypted Payload.

• Nearby Info (0x10, variable): high nibble of byte 0 = StatusFlags, low nibble = ActionCode (15-entry name table); byte 1 = DataFlags; remaining bytes = AuthTag.

• Nearby Action (0x0F, variable): ActionFlags byte

• ActionType byte (15-entry name table for setup flows: Wi-Fi join, AirPods setup, HomePod auto-setup, Apple TV setup, etc.) + AuthTag + optional ActionParameters.

• AirDrop (0x04, length 18): Status byte + 8 bytes of Apple ID / phone / email hash material.

• Proximity Pairing (0x06, variable): Device model byte

• status flags + battery levels (Left + Right + Case for AirPods) + UTP (Unknown Transport Pairing) + Lid state.

• Hey Siri (0x07, length 5): Hash bytes used to wake Siri across devices.

• Other types: surfaced with Type + TypeName + Length

• raw hex body. Operators who need full dissection of AirPlay, HomeKit, or Watch frames can read the bytes.

• Multi-TLV summary: a per-advertisement summary string (e.g. "Nearby Info + Handoff") for triage.

What this package does NOT cover (deliberately out of scope)

• The BLE Link-Layer / Advertising PDU framing — that's `ble_classify` / `ble_findmy_*`.

• The AppleID / phone / email / OfflineFinding key reversal — encrypted material is surfaced as hex; the decryption side belongs in a separate Spec.

• Handoff payload decryption — IV + AuthTag are surfaced but the cipher-text is opaque without the pairing key.

• The Bluetooth Low Energy GAP / GATT layer beyond the advertising data record.