3 ms·

The main Android detection here can probably be defeated using a tool like Pry-Fi on a rooted device, https://play.google.com/store/apps/details?id=eu.chainfir

The main Android detection here can probably be defeated using a tool like Pry-Fi on a rooted device, https://play.google.com/store/apps/details?id=eu.chainfire.pryfi&hl=en https://play.google.com/store/apps/details?id=eu.chainfire.p... You can also set specific MACs per-AP so it'll defeat probe-based attacks too theoretically. This should get it by 4/5 attacks here. Their RTS/CTS method in particular sounds like it'll be impossible to defeat without Wifi chipset manufacturers simply removing their hardcoded MAC and switching to letting the OS pick it - unless there's a possibility of triggering that change via a driver already, might be time to start looking at datasheets on wifi chips.

teacup50 10y ago
At least for Broadcom (nee Cypress) WiFi chipsets used in a lot of these devices, the canonical MAC used by hardware is encoded in one of three places: - Onboard SPROM: easily modified by a driver, but shouldn't be rewritten to achieve randomized MACs; you'll blow through your flash write cycles. - Onboard OTP (one-time programmable memory): also easily modified, but it's one-time writable; you can only set bits to 1, never 0. - External NVRAM / NVRAM image (e.g. supplied by the driver): totally controlled by the driver/host OS, can be set to whatever you want. Changing this behavior would require changing the firmware image uploaded to the WiFi chipset by the driver.
- problems 10y ago
  Ah, interesting, are these firmwares typically signed or is it something that could be reverse engineered and modified by anyone?
  - teacup50 10y ago
    In theory you can supply your own firmware.
    - scintill76 10y ago
      Some Sony Android phones apparently use your third model, with Linux pushing the firmware image to the wifi card. The MAC address is in that image, but not baked in to the distributed file, so something has to fetch the unique MAC from somewhere and write it in to be sent to the wifi chip. And the MAC seems to be unprotected by signatures. At least this is what I gathered from looking at CyanogenMod source awhile back. mac-update[0] reads the MAC (multiple of them, apparently) from some files on /data[1] (which I think are put there by a proprietary blob that got them from a separate partition dedicated to storing provisioning data), copying the firmware image from /system and writing the patched version to /data (which path the kernel loads from to send into the wifi card.) As I recall, changing my MAC address "permanently" was as easy as changing the MAC file on /data, but I don't have the phone anymore. [0] https://github.com/CyanogenMod/android_device_sony_qcom-common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.c https://github.com/CyanogenMod/android_device_sony_qcom-comm... [1] https://github.com/CyanogenMod/android_device_sony_qcom-common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.h https://github.com/CyanogenMod/android_device_sony_qcom-comm...

teacup50 10y ago

At least for Broadcom (nee Cypress) WiFi chipsets used in a lot of these devices, the canonical MAC used by hardware is encoded in one of three places: - Onboard SPROM: easily modified by a driver, but shouldn't be rewritten to achieve randomized MACs; you'll blow through your flash write cycles. - Onboard OTP (one-time programmable memory): also easily modified, but it's one-time writable; you can only set bits to 1, never 0. - External NVRAM / NVRAM image (e.g. supplied by the driver): totally controlled by the driver/host OS, can be set to whatever you want. Changing this behavior would require changing the firmware image uploaded to the WiFi chipset by the driver.

problems 10y ago
Ah, interesting, are these firmwares typically signed or is it something that could be reverse engineered and modified by anyone?
- teacup50 10y ago
  In theory you can supply your own firmware.
  - scintill76 10y ago
    Some Sony Android phones apparently use your third model, with Linux pushing the firmware image to the wifi card. The MAC address is in that image, but not baked in to the distributed file, so something has to fetch the unique MAC from somewhere and write it in to be sent to the wifi chip. And the MAC seems to be unprotected by signatures. At least this is what I gathered from looking at CyanogenMod source awhile back. mac-update[0] reads the MAC (multiple of them, apparently) from some files on /data[1] (which I think are put there by a proprietary blob that got them from a separate partition dedicated to storing provisioning data), copying the firmware image from /system and writing the patched version to /data (which path the kernel loads from to send into the wifi card.) As I recall, changing my MAC address "permanently" was as easy as changing the MAC file on /data, but I don't have the phone anymore. [0] https://github.com/CyanogenMod/android_device_sony_qcom-common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.c https://github.com/CyanogenMod/android_device_sony_qcom-comm... [1] https://github.com/CyanogenMod/android_device_sony_qcom-common/blob/40c07439a871c94bfb386dc4435787f040ef8d17/mac-update/mac-update.h https://github.com/CyanogenMod/android_device_sony_qcom-comm...