They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app.
>Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.
If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
Looking at the apps I had to purge from family members' phones, I don't think that will be a problem.
> If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
Accessing geolocation APIs will show an indicator and add an entry to a log (at least on Android). I don't believe accessing BLE APIs do the same.
As if people would care about that...
Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
Using Core Bluetooth API it is trivial, but you need to either: a) create an app that does it and user has to download it b) modify SDKs existing in apps (e.g. Ad SDKs)
Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti.
Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years.
So to attack iOS device: - user has to download the app - app has to broadcast fake BLE - some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you