>>4916>any knowledgeable network administrator can now get your real MAC address even when you're spoofing it
Some corrections after refreshing myself on this: I should add the disclaimer that your real MAC address can be obtained by any knowledgeable passive observer--mark out net admin above--/only if/ you are using an affected Android device (96% of the sample set) and are not connected to an AP (access point). iPhones and roughly 4% of the sample set of Android devices are unaffected by the simple passive deanonymization techniques described in the article. However, if an adversary knows your real MAC address then it's game over--even if you're using a laptop, raspi, pocketchip, etc. This is because existing client device chipsets (i.e. isn't an AP) will respond to RTS frames (yes, you read that correctly) with a CTS frame, alerting the adversary that the targeted device/individual is within range. This behavior is impossible for the OS to block, as well.>>4917>Would having custom hardware negate this?
Yes, but you'd have to make it yourself since all existing 802.11 chipsets are thought to be vulnerable.>>4918
And make sure that your existing wireless chip is in the DOWN state if still connected.
Basically, it boils down to don't use smartphones unless the real MAC address can't be tracked back to you (buy with cash) and do likewise when purchasing WLAN cards if your threat model includes state actors. Also don't rely on the manufacturer's MAC randomization as that is only used for unauthenticated and unassociated probe requests (i.e. before you are connected to an AP). Even then, though, the situation's kinda fuarrrked because as soon as your real MAC address is compromised you can be tracked no matter where you go, provided that your adversary has the resources to pursue you in this manner of course; I'll let Lain imagine the myriad avenues available to this end.