Possible new continuity type 0x16? #10
Description
Howdy - thanks for this repo, it's an excellent resource!
It looks like iOS devices with 18.3+ greatly reduce their bluetooth advertisements when locked, which makes it more difficult when using BLE for presence detection (I maintain bermuda which does exactly this via home assistant).
In some testing I was able to see only one form of advertisement being sent while a friend's recent iphone was idle. NRFConnect shows:
This looks to be the only data it advertises while in this state, and the adverts seem to be fairly consistently at 2 second intervals.
Observing over time shows that the address is changed periodically, along with the last 8 (or maybe only 7) octets of the ad:
MAC|Raw Advert|Timing
47:6E:DD:0D:54:BE|0x02 011A 0D FF 4C00 16 08 0012232F85D11C3D |13:30ish
50:07:54:97:64:D4|0x02 011A 0D FF 4C00 16 08 00CDAACBE1E61749 |14:23 - 14:33 = 10m to 23m
73:08:BB:67:B5:A3|0x02 011A 0D FF 4C00 16 08 002169FD3C06B7CE |14:46 - 14:52 = 6m to 19m
78:C2:A4:1A:C0:96|0x02 011A 0D FF 4C00 16 08 00822ECC9EE5E41F |14:52 - 14:54
Given the MAC rotation timings of between 10 and 19 minutes (which are simply the timings of when I did scans in nrfconnect, hence the ranges), I expect it's probably rotating the MAC in accordance with the timers for Resolvable Private Addresses, of 15 minutes.
Unfortunately, the MAC address do not resolve with the device's IRK, so I don't yet know a way to tie the adverts to a given device, other than noting the change-over time to relate each string of adverts to each other.
My interpretation is that these are Continuity adverts with a type code of 0x16, which I don't think has been documented yet. My reading of this site and searches elsewhere have not turned up anything yet that matches (assuming I am interpreting the payload correctly!)
- If these are indeed a new continuity type 0x16, perhaps they could be added to the repo (and perhaps the dissector, which I've yet to play with)
- Do you have any ideas on how I might investigate further to see if we can work out how the MAC and/or payload are derived or could be resolved to a device?
- I have access to the device's IRK, and can almost certainly obtain the owner's iCloud email/phone.
- I have access to another users's IRK, adverts and may possibly be given their iCloud email/phone.
- While I have these users' consent to work with their (non-public) data, I don't have (and don't plan to seek) their permission to share it, which does limit the collaborative options somewhat.
- I only have access to the friend's device periodically, but I may be able to get other users to try out scripts or steps.
I have cobbled together a python script that I've been using to validate IRKs against MAC addresses etc, so given some ideas on what to experiment with I can probably stumble around doing some testing. I notice from previous continuity analysis, it seems that hashing the user's iCloud email and phone number seems a common pattern Apple have used previously, but I'm at a bit of a loss of where to start strategically, or if there's likely just an impossibility to resolve details from the most recent iOS builds.
Ideally what I am hoping for is a way to determine if one of these adverts belongs to a given IRK or known iCloud details - that is, to provide consensual device tracking for a device owner who has given those details to a tool's configuration.