⇠ Luna’s Blog

Bluetooth Low-Energy Spec Violations

2021-05-13 · Luna

Note: This was originally a Twitter thread, and has been lightly edited for presentation here.

I fell down a rabbit-hole of “I want to learn more about this tech” so I’ve been running a Bluetooth Low-Energy (BLE) scanner on my laptop for the last couple of days... I found there’s a device somewhere in the vicinity of my home that seems to be violating the spec?

Generally speaking (I’m skipping over a lot of the protocol details), BLE advertising packets have a length, a byte indicating the packet type, and then length-1 bytes of payload data. Naturally, that payload gets handled differently depending on what the packet type is.

The spec has a packet type 0xFF for “Manufacturer Specific Data”, where the payload is allowed to be whatever the vendor needs for their purposes. Among numerous other uses, it’s how items on Apple’s “Find My” network broadcast details of their existence.

Critically though, the spec for these Manufacturer-Specific packets states that the first 2 bytes of the payload contain the manufacturer’s Company Identifier Code (CIC), from the list of Assigned Numbers.

excerpt from the Bluetooth Core Specification Supplement, Part A, Section 1.4 “Manufacturer Specific Data” “The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier.” (Core Spec Supplement, Part A, Section 1.4)

Apple’s CIC is 004C, so their packets all start with 4C 00 (little-endian byte order). Oculus’s is 058E, their packets all start with 8E 05. You get the idea. The full list is available here.

I’ve seen plenty of packets from the usual suspects, Apple, Samsung, Sony, etc. But I spotted a few packets today with a CIC of 0A01, which is “Cleveron AS”. I’ve never heard of them before - apparently they’re an Estonian logistics company?

A while later, I spotted a packet with a CIC of 0B01, which is.... not assigned. It’s not on the list. And these packets followed a similar structure to the others.

The first set all started with 01 0A 41, followed by either 00 or 08, and then 5 seemingly-random bytes. The latter set were almost the same, just starting with 01 0B 01 instead. It’s probably safe to assume they’re the same device, the same vendor, and they’re omitting the CIC.

Interestingly, these were also broadcasting the existence of a Service with a UUID of FEBE, which is apparently assigned to Bose Corporation. (Note: Bose’s CIC is 009E, this Service UUID is from a completely separate list, and one company can register multiple Service UUIDs)

So my interpretation is that Bose are violating the spec as it pertains to Manufacturer Specific Data, but are still capable of identifying Bose devices as needed (I guess there’s some smartphone app for their headphones?), via their Service UUID that’s broadcasting alongside it.

I’m also suspicious of the device that’s advertising Service FE61 (which is assigned to Logitech International SA) but whose Manufacturer-Specific Data reports a CIC of 0003 (IBM Corp.)