BLE token appears to increment with each broadcast

[jack-webb]

I re-scanned my remote for its BLE advertising token today, and the token it advertised is different to the one when I first did this a few months ago. I ran a few more tests and it appears the BLE advertising token of my remote is incrementing roughly with each broadcast.

I wrote a script for scanning tokens using python, was originally looking ways to sniff the token directly on a bluetooth-capable host. I ran the script whilst pressing the power button (projector unplugged ofc). Script is here: https://github.com/jack-webb/XBleet

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xEDD731E3B22440FFFFFF3043524B544D

[master][~/xbleet]$ pipenv run python XBleet/main.py
^[[ADiscovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xEDD731E3B22440FFFFFF3043524B544D

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xEFD731E3B22440FFFFFF3043524B544D

...

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xF2D731E3B22440FFFFFF3043524B544D

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xF3D731E3B22440FFFFFF3043524B544D

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xF4D731E3B22440FFFFFF3043524B544D

[master][~/xbleet]$ pipenv run python XBleet/main.py
Discovered BLE device(s):
Device name: BLuetooth 4.0 RC, Address: 1C:F3:01:F9:9B:8F
Manufacturer 0x46
Data 0xF6D731E3B22440FFFFFF3043524B544D

It looks like this is happening to others too - see this comment from a few days ago. The first token bytes are somewhat sequential, which I could see happening over a few attempts at capturing with EFR. Interestingly, for me both the original token and an 'incremented' token spoofed with EFR Connect worked to turn on my projector, which it doesn't for the linked comment.

Also, please add a Bluetooth label for issues so we can tell which are and are not bluetooth related :)

[manymuch]

Yes, I also have observed that. No idea why, maybe the first token bytes could be arbitrary.

[helgek]

I think I can provide a bit more potential background although I also don't have a final answer yet to why my device (Elfin projector) behaves like this:

When I turn my projector on using the BLE advertising data that I'm using every time to turn on the projector this works regardless that the original XGIMI remote also changes the first byte every time the device is being turned on again. It's also counting up, so I assume it will count up to FF and then (hopefully) start with 00 again. I ran an automation to repeat on / off cycles of the projector 30 times (with delays of 30 seconds between turning on and off the projector) and my same advertising data always worked despite the XGIMI remote using slightly different advertising data every new turn on/off cycle.

But now there's an interesting exception to this pattern: By coincidence I found out that when I turn off the projector (I used the XGIMI remote, I haven't tested the following scenario yet using a software based remote command over WiFi to turn off the projector) and I send my own advertising data shortly after the projector led was turned off (e.g. within about 3-5 seconds) the projector would not turn on again (maybe because it's still busy with the going to sleep routing) + the projector would from this moment onwards not accept my own advertising data anymore. Even after 1 hour my advertising data would not turn the projector on anymore.

Nevertheless the projector would turn on again using the XGIMI original remote. So obviously this hex byte changes both in the remote and the projector every time you turn it on (or off) and in this special constellation described above the projector would obviously only turn off with this unique (current) advertising data.

When I turned the projector on and off again afterwards using the XGIMI original remote and I waited again about 30 seconds at least before I tried my own advertising again, the projector would again react to my own advertising data as it did before.

Since I successfully ran the simulation of turning on/off the projector 30 times with the same advertising data with some delay between each turn on/off cycle I'm confident that I can rely on the same advertising data. Nevertheless it would of course be interesting to better understand the exact mechanism in the device and the XGIMI remote control. I'm definitely curious to see what will happen when the projector and the XGIMI remote have reached FF and if the HEX byte will start with 00 again and not change any other part of the advertising data.

One more thought: In case the advertising data should remain the same forever except for the first HEX byte then one could of course think of additional tweaks to achieve maximum reliability for the projector wake-up :

1. One could send the advertising data with all HEX byte variants (although I'm not sure to how many the projector would listen too if all variants would be broadcasted within a too short period of time).
2. One could look into potential ways to track the current HEX byte that was exchanged between the projector and the XGIMI remote (I'd assume this might even happen if you don't use the XGIMI remote at all to turn the projector on or off, but of course I don't know what would happen if not even a remote is paired to the projector).