Blue2thprinting

The talk addresses a practical gap in Bluetooth research. When a chip is found to have an over-the-air code execution flaw, nobody knows which products use it. The speaker walks through the supply chain from chip makers to module makers to product makers, explaining why that mapping is hard. Past Bluetooth bugs in Texas Instruments, Broadcom and other silicon set the stakes.

The core of the talk is a survey of "toothprinting" methods for working out which silicon a device runs. Passive methods read the company identifier in Bluetooth addresses and the manufacturer-specific advertising data, where byte order mismatches were common. Semi-active and active methods send link-layer version requests and unusual feature-page requests, which can expose chip steppings and sometimes cause crashes or leaked memory. GATT reads expose services, UUIDs and firmware strings, and some vendors' magic UUIDs point to a specific manufacturer. Each method has limits. Response rates were often low, GATT reads are slow, and on Broadcom devices the subversion field tracked silicon revision rather than firmware version.

The main takeaway is that no single data point is reliable. A precise fingerprint combines several signals, and any method needs validating against devices with known chips before it can be trusted. The speaker's data came from years of sniffing traffic with a Raspberry Pi, and he closes by inviting collaborators to help build the tooling and pointing to a bibliography of Bluetooth security research.