search

wiglenet / wigle-wifi-wardriving

Nethugging client for Android, from wigle.net
https://wigle.net
BSD 3-Clause "New" or "Revised" License
649 stars 199 forks source link

Record Bluetooth UUID128s #623

Open XenoKovah opened 10 months ago

XenoKovah commented 10 months ago

Analogous to #614, one of the other types of data that can be advertised by BLE and BT Classic is a 128-bit UUID (which come in both "incomplete list" and "complete list" forms, like UUID 16s. (And once again those constants are also available in https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/core/ad_types.yaml as 6 and 7 respectively.)

There are some assigned UUIDs, where the base pattern is "0000XXXX-0000-1000-8000-00805f9b34fb", where the XXXX can either be one of the same 16-bit Service UUIDs (https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/uuids/service_uuids.yaml) or Member UUIDs (https://bitbucket.org/bluetooth-SIG/public/src/main/assigned_numbers/uuids/member_uuids.yaml) mentioned in #164. Essentially the 16-bit UUIDs from #164 are just a more compact way of advertising this longer 128-bit UUID.

In other cases the UUID128 will be more thoroughly randomized and not an assigned number. In that case it can sometimes be used to associate a device with a particular vendor or product model (e.g. Fitbit examples in my recent talk slide 87).

But in other cases the UUID may be associated with a particular silicon vendor (e.g. the Nordic UART service 6E400001-B5A3-F393-E0A9-E50E24DCCA9E, which AFAIK is currently only found on devices using Nordic chips (i.e. AFAIK no other vendor had decided to copy that interface for usage on other chips)).

Consequently once again this information is potentially valuable for research on inferring product companies, chip maker companies, or classes of device (e.g. UUID128s associated with printers or headphones.)

This picture from #614 shows an example of BT Classic with UUID128s advertised in addition to UUID16s:

bobzilladev commented 10 months ago

This data is rare enough that local collection or central aggregation of this data isn’t going to be priority for the project. This ticket will be left open in case someone in the community would like to take on the first step of adding local collection of this data to the app. Its implementation might be included as part of this other UUID issue.