GNU/翠星石 on Nostr: nprofile1q…kqsd9 nprofile1q…s56am >How does something access your device ...

nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqyr4cf3y9urc0h4t0mtsul8w8af67xdu5nej8qedqe7hlgy4pjc8qqykqsd9 (nprofile…qsd9) nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqypy89xljq8c8zg843c9deas6p6l4emf5nny45956wspjzew8q92g59s56am (nprofile…56am) >How does something access your device Bluetooth without permitting connection first?
The way demon rectangles are designed is to have the bluetooth card regularly announce its hardware MAC address, so the device is in the "discoverable" state and can quickly pair with bluetooth devices like speakers or headphones - only if bluetooth is in the "off" state that such announcement is not made.

The result is that anyone walking past with https://f-droid.org/en/packages/net.wigle.wigleandroid/ running can store the MAC address, location and time, but more relevantly, there are bluetooth stingrays in stores that collects such metadata and exploits it.

Later bluetooth versions are meant to have privacy MAC's, with a random MAC being announced generally, but I guess that the current random MAC would need to be stored if you decided to pair with a device, with that MAC needing to persist for as long as that device is to be paired to.

I'm not sure if MAC's are encrypted and if not, having bluetooth headphones that only support a static MAC would allow for long term identification for any listener that intercepts the packets containing the static MAC (bluetooth devices inherently receive all bluetooth packets in range, but are designed by default to drop any packets that don't have a relevant MAC).

Often the privacy MAC implementation is intentionally or mistakenly screwed up; https://news.osu.edu/study-uncovers-new-threat-to-security-and-privacy-of-bluetooth-devices/ (unfortunately the article refers to the boring exploiting of devices as to "hack", when hacking is playful cleverness)

>Don't you need to "allow" a device to connect by Bluetooth?
No - for demon rectangles in the default "discoverable" state, external devices can connect and request paring; https://www.simplymac.com/accessories/why-am-i-getting-unwanted-bluetooth-pairing-attempts (LLM slop, but the first few sentences are relevant).

The "allow" permits the current connection to finish the pairing handshake, while disallow rejects the pairing handshake until the asking device tries again.


The handshake is extremely complicated and when implemented with garbage proprietary software, there are always protocol vulnerabilities.

One example of a possible vulnerability is; https://wiibrew.org/wiki/BlueBomb#How_it_works - often with these proprietary bluetooth stacks, an exploit can consist of starting the pairing handshake, inserting a stage0 executable of the correct architecture into one of the data packets of the handshake (which makes the bluetooth stack load the executable data into memory) and then sends an invalidly encoded packet that exploits the bs and causes it to jump execution to the stage0 executable in memory (whoops, the data is executable), which can then be used to do anything - for example to upload a larger executable via bluetooth that does a lot of things - all without even a connection request popping up (the bluetooth will stop working as a side effect, but nobody will notice due to how often bluetooth stops working).

For some Android devices, I guess that sometimes the bluetooth stack is run as root and also is excepted from SELinux (as it's hard enough to get it working without SELinux), meaning a successful exploit would allow for full device compromise.