Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,741,401 Members 38,584 Now Online
XDA Developers Android and Mobile Development Forum

Understanding Pry-Fi and 802.11 probe requests

Tip us?
 
cernekee
Old
(Last edited by cernekee; 4th February 2014 at 07:10 AM.)
#1  
Senior Member - OP
Thanks Meter 350
Posts: 175
Join Date: Jun 2013
Default Understanding Pry-Fi and 802.11 probe requests

Over the past year or so, a number of news stories have discussed the possibility of tracking smartphone users in public via wifi probes. The recent announcement of Pry-Fi inspired me to do a little research to see exactly what information was being revealed, and what could be done about it.

The easiest way to observe the information leak in question (and later, to find out if it has been successfully plugged) is to follow part 4 of Vivek Ramachandran's WLAN Security Megaprimer. He describes the process of setting up a virtual machine running Backtrack Linux (now replaced by Kali Linux), and using aircrack-ng and wireshark to observe WLAN activity.

The whole series is worth watching, but here are a few basic survival commands:

Code:
Select Code
# enable RF monitor mode on wlan0 (your interface might have a different name)
airmon-ng start wlan0

# compile a list of known networks and their BSSIDs; hit ^C to quit
airodump-ng mon0

# tune the WLAN card to the channel of interest (seen in the above list)
iwconfig wlan0 channel 1

# start wireshark and then begin sniffing
wireshark
Android uses the standard wpa_supplicant infrastructure found on Linux PCs to manage the WLAN interface and its database of known access points (APs). The configuration is stored in /data/misc/wifi/wpa_supplicant.conf. I was not able to find this mirrored anywhere else (e.g. in a SQLite database).

The wpa_supplicant daemon is controlled through commands sent over its standard socket interface by $AOSP/frameworks/base/wifi/java/android/net/wifi/WifiInfo.java, its JNI helpers, and libhardware. If your ROM supports it, you can observe what wpa_supplicant is doing by running wpa_cli from a shell, then in another window, running 'adb logcat -s "wpa_supplicant:*"'. Some useful wpa_cli commands include:

Code:
Select Code
# show each outbound message (other levels include: info, debug, excessive)
log_level msgdump

# initiate a scan and dump results (note that the results also show up in
# logcat if the log_level is sufficiently high)
scan
scan_results

# show current status
status

# show known networks
list_networks

# disable scan_ssid on entry #2 from list_networks
set_network 2 scan_ssid 0
save

# reread the wpa_supplicant.conf file
reconfigure
On my N5 running KK 4.4 I needed to preface most commands with "IFNAME=wlan0", but on my N7 running JB 4.2.2 only the bare commands were accepted. YMMV so try both if in doubt.

Here are some observations gathered from experimenting with Nexus 7 (2012) running JB 4.2.2:
  • There is an entry in wpa_supplicant.conf for every known network.
  • Any network added manually with the '+' icon will have scan_ssid=1. Any network picked from the list of scan results will not have a scan_ssid property.
  • When wifi is enabled and the user is in the Settings->Wifi activity, Android will perform a network scan about every 8 seconds.
  • When wifi is enabled and the user is doing something else, and the interface is not currently associated with an AP, Android will perform a network scan about every 15 seconds.
  • On each scan, wpa_supplicant will send out probe requests. Every probe request contains the interface's MAC address.
  • wpa_supplicant will send probe requests containing an explicit ESSID name for each entry that has scan_ssid=1. If there are no such entries, the SSID parameter in the probe request will always be empty (signifying a broadcast probe request).
  • If wpa_supplicant.conf contains a very common ESSID name (like "linksys" or "netgear") then your device will try to associate with any other AP that uses that name. i.e. as expected, it matches the ASCII ESSID rather than the BSSID MAC address
  • If your device associates with a network, it leaks a whole bunch more data (and could be victimized by a malicious network). So if privacy/security are important, you'll want to carefully control the conditions under which your device associates with wifi networks.
  • N.B. The baseband side might not be any more trustworthy, but that is beyond the scope of this discussion.

The latter two items potentially leak sensitive data: your MAC address uniquely identifies your smartphone, and an ESSID list can reveal networks to which you have connected in the past (home networks, work networks, etc). In some cases the network names may be unique enough to translate back to a specific geographical location. The ESSID is just an ASCII string, not the AP's MAC address, so it may introduce some degree of ambiguity.

If you're monitoring wpa_supplicant via wpa_cli and logcat, and you used "log_level msgdump", you can see which ESSID names your device is broadcasting:

Code:
Select Code
D/wpa_supplicant(19967): wlan0: Control interface command 'SCAN'
D/wpa_supplicant(19967): wlan0: Setting scan request: 0 sec 0 usec
D/wpa_supplicant(19967): Scan SSID - hexdump(len=7): 61 74 74 77 69 66 69
D/wpa_supplicant(19967): wlan0: Starting AP scan for wildcard SSID
D/wpa_supplicant(19967): WPS: Building WPS IE for Probe Request
D/wpa_supplicant(19967): WPS:  * Version (hardcoded 0x10)
D/wpa_supplicant(19967): WPS:  * Request Type
D/wpa_supplicant(19967): WPS:  * Config Methods (4388)
D/wpa_supplicant(19967): WPS:  * UUID-E
D/wpa_supplicant(19967): WPS:  * Primary Device Type
D/wpa_supplicant(19967): WPS:  * RF Bands (1)
D/wpa_supplicant(19967): WPS:  * Association State
D/wpa_supplicant(19967): WPS:  * Configuration Error (0)
D/wpa_supplicant(19967): WPS:  * Device Password ID (0)
D/wpa_supplicant(19967): WPS:  * Manufacturer
D/wpa_supplicant(19967): WPS:  * Model Name
D/wpa_supplicant(19967): WPS:  * Model Number
D/wpa_supplicant(19967): WPS:  * Device Name
D/wpa_supplicant(19967): WPS:  * Version2 (0x20)
D/wpa_supplicant(19967): P2P: * P2P IE header
D/wpa_supplicant(19967): P2P: * Capability dev=24 group=00
D/wpa_supplicant(19967): P2P: * Listen Channel: Regulatory Class 81 Channel 6
D/wpa_supplicant(19967): nl80211: Scan SSID - hexdump(len=7): 61 74 74 77 69 66 69
D/wpa_supplicant(19967): nl80211: Scan SSID - hexdump(len=0): [NULL]
The red lines show probe requests that leak the "attwifi" ESSID and your MAC address. The blue line shows a probe request with an empty (broadcast) ESSID, which still leaks your MAC address.

So, what can we do about these leaks? I'll post a list of suggestions and see what else the XDA community comes up with:
  • Check your wpa_supplicant.conf for any entries with scan_ssid=1. If the network has SSID broadcasts disabled, you need this property; if you are the administrator you can re-enable SSID broadcasts on the AP and then eliminate scan_ssid=1. Vivek's videos explain why disabling SSID broadcast on the AP does not actually provide any security benefits.
  • Disable "Keep Wi-Fi on during sleep." This option is found under Settings -> Wi-Fi -> (menu) -> Advanced. If wifi is disabled while the phone is in your pocket sleeping, it will not broadcast its MAC address every 15 seconds. This isn't a comprehensive solution but it reduces the scope of the problem.
  • Run Smarter Wi-Fi Manager. SWM uses your coarse (cellular/GPS?) location to decide whether or not to enable the WLAN radio. Pros: open source; eliminates many possible information leaks. Cons: I believe this requires location services enabled, which may supply location data to other apps and/or impact battery life.
  • Run Pry-Fi. Pros: I have verified through Wireshark that this indeed randomizes the MAC addresses in the Probe Request packets. Cons: Not open source (and it's a "security" app that runs as root); causes strange interactions with the standard Android UI. Other potential side effects are unknown as the code has not yet been analyzed.
  • Modify the ROM. It may be possible to tweak wpa_supplicant or the kernel WLAN driver to send random or generic (ff:ff:ff:ff:ff:ff?) MAC addresses in their probe requests. For wpa_supplicant this may be doable through Cydia Substrate. It is likely that a well-done ROM modification would have few or no side effects on usability. However, it may require each individual wpa_supplicant driver or kernel WLAN driver to be modified.
  • Modify the UI. It would be nice if the Settings -> Wi-Fi interface clearly distinguished entries with scan_ssid=1. Maybe these could be shown in red with a simple Xposed module or ROM tweak.

Any other ideas?
The Following 9 Users Say Thank You to cernekee For This Useful Post: [ Click to Expand ]
 
kenshin33
Old
#2  
Senior Member
Thanks Meter 55
Posts: 154
Join Date: Mar 2009
Location: Montreal
Quote:
Originally Posted by cernekee View Post
  • Check your wpa_supplicant.conf for any entries with scan_ssid=1. If the network has SSID broadcasts disabled, you need this property; if you are the administrator you can re-enable SSID broadcasts on the AP and then eliminate scan_ssid=1. Vivek's videos explain why disabling SSID broadcast does not actually provide any security benefits.


  • Modify the ROM. It may be possible to tweak wpa_supplicant or the kernel WLAN driver to send random or generic (ff:ff:ff:ff:ff:ff?) MAC addresses in their probe requests. For wpa_supplicant this may be doable through Cydia Substrate. It is likely that a well-done ROM modification would have few or no side effects on usability. However, it may require each individual wpa_supplicant driver or kernel WLAN driver to be modified.

Wha do you mean by: " tweak wpa_supplicant or the kernel WLAN driver to send random or generic (ff:ff:ff:ff:ff:ff?) MAC addresses in their probe request" ?
just the prob request??
Some devices (Galaxy nexus -torro in particular-) have already that, each boot gives a random mac address (unless specified as a boot arg).
But this is not an ideal solution b/c it can bring other problems (exhaust dhcp pools, duplicate macs on same network ..... etc).
The same problem would apply to anyone with a laptop and frequents regularly some coffe shop or library ...


(I use LLama -doesn't need location service on- to enable/disable Wifi)
 
cernekee
Old
(Last edited by cernekee; 3rd February 2014 at 12:25 AM.)
#3  
Senior Member - OP
Thanks Meter 350
Posts: 175
Join Date: Jun 2013
Quote:
Originally Posted by kenshin33 View Post
Wha do you mean by: " tweak wpa_supplicant or the kernel WLAN driver to send random or generic (ff:ff:ff:ff:ff:ff?) MAC addresses in their probe request" ?
just the prob request??
Well, the main problem (from my standpoint at least) is that any time wifi is enabled, the device will broadcast its MAC address. Even if there aren't any familiar networks in range. This is what allows for surreptitious tracking.

So if the probe request is either eliminated, or modified to avoid giving out identification information, this problem is avoided.

Quote:
Some devices (Galaxy nexus -torro in particular-) have already that, each boot gives a random mac address (unless specified as a boot arg).
But this is not an ideal solution b/c it can bring other problems (exhaust dhcp pools, duplicate macs on same network ..... etc).
Also, a production device might not be rebooted very often.

A reasonable tradeoff might involve changing to a randomized MAC address when the wifi device is brought up, possibly rate-limited to once or twice a day. This could potentially be done by wrapping wpa_supplicant with a script (or just hacking the source code).

There are a couple of MAC address changer apps on Google Play, but unfortunately nothing on F-Droid. Obviously this operation requires root.

Edit: RandoMAC may be a starting point

Another option might involve adding a "change MAC address every N hours" feature to an existing app, such as AFWall.

Quote:
The same problem would apply to anyone with a laptop and frequents regularly some coffe shop or library ...
If you're actually passing data traffic on a public wifi service, it becomes significantly harder to prevent information leaks and avoid leaving traces of your presence.

FWIW I noticed that mac80211 in the kernel will perform a passive scan if no SSIDs are supplied by the caller:

Code:
Select Code
		if ((req->channels[0]->flags &
		     IEEE80211_CHAN_PASSIVE_SCAN) ||
		    !local->scan_req->n_ssids) {
			next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
		} else {
			ieee80211_scan_state_send_probe(local, &next_delay);
			next_delay = IEEE80211_CHANNEL_TIME;
		}
So I tried modifying driver_nl80211.c in wpa_supplicant so that it passes in 0 SSIDs, 0 extra IEs, and 0 frequencies. Yet the bcmdhd kernel driver (which implements a "full mac" in firmware, rather than using mac80211) still sent the probe requests.

wpa_supplicant / wpa_cli also recognizes a "DRIVER PASSIVE-SCAN" command which does not seem to have an effect.
 
kenshin33
Old
#4  
Senior Member
Thanks Meter 55
Posts: 154
Join Date: Mar 2009
Location: Montreal
Quote:
Originally Posted by cernekee View Post
Well, the main problem (from my standpoint at least) is that any time wifi is enabled, the device will broadcast its MAC address. Even if there aren't any familiar networks in range. This is what allows for surreptitious tracking.

So if the probe request is either eliminated, or modified to avoid giving out identification information, this problem is avoided.



Also, a production device might not be rebooted very often.

A reasonable tradeoff might involve changing to a randomized MAC address when the wifi device is brought up, possibly rate-limited to once or twice a day. This could potentially be done by wrapping wpa_supplicant with a script (or just hacking the source code).

There are a couple of MAC address changer apps on Google Play, but unfortunately nothing on F-Droid. Obviously this operation requires root.

Edit: RandoMAC may be a starting point

Another option might involve adding a "change MAC address every N hours" feature to an existing app, such as AFWall.



If you're actually passing data traffic on a public wifi service, it becomes significantly harder to prevent information leaks and avoid leaving traces of your presence.

FWIW I noticed that mac80211 in the kernel will perform a passive scan if no SSIDs are supplied by the caller:

Code:
Select Code
		if ((req->channels[0]->flags &
		     IEEE80211_CHAN_PASSIVE_SCAN) ||
		    !local->scan_req->n_ssids) {
			next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
		} else {
			ieee80211_scan_state_send_probe(local, &next_delay);
			next_delay = IEEE80211_CHANNEL_TIME;
		}
So I tried modifying driver_nl80211.c in wpa_supplicant so that it passes in 0 SSIDs, 0 extra IEs, and 0 frequencies. Yet the bcmdhd kernel driver (which implements a "full mac" in firmware, rather than using mac80211) still sent the probe requests.

wpa_supplicant / wpa_cli also recognizes a "DRIVER PASSIVE-SCAN" command which does not seem to have an effect.
wl_android.c doesn't seem to do anything with it
there are some refs in wl_cfg80211.c
 
cernekee
Old
#5  
Senior Member - OP
Thanks Meter 350
Posts: 175
Join Date: Jun 2013
Quote:
Originally Posted by kenshin33 View Post
wl_android.c doesn't seem to do anything with it
there are some refs in wl_cfg80211.c
Well, this part of wl_android_priv_cmd() looks discouraging:

Code:
Select Code
	else if (strnicmp(command, CMD_SCAN_ACTIVE, strlen(CMD_SCAN_ACTIVE)) == 0) {
		/* TBD: SCAN-ACTIVE */
	}
	else if (strnicmp(command, CMD_SCAN_PASSIVE, strlen(CMD_SCAN_PASSIVE)) == 0) {
		/* TBD: SCAN-PASSIVE */
	}
Also, I may have missed something obvious, but it isn't clear to me that wl->active_scan can ever get set to false:

Code:
Select Code
$ git grep active_scan drivers/net/wireless/bcmdhd | cat
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:		err = wl_cfgp2p_escan(wl, ndev, wl->active_scan, num_chans, default_chan_list,
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:		passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	beacon_proberesp = wl->active_scan ?
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	wl->active_scan = true;
drivers/net/wireless/bcmdhd/wl_cfg80211.h:	bool active_scan;	/* current scan mode */
drivers/net/wireless/bcmdhd/wl_iw.c:wl_iw_set_active_scan(
drivers/net/wireless/bcmdhd/wl_iw.c:			ret = wl_iw_set_active_scan(dev, info, (union iwreq_data *)dwrq, extra);
drivers/net/wireless/bcmdhd/wl_iw.c:	(iw_handler)wl_iw_set_active_scan,
I think this line just sends a message to the firmware, so it isn't clear what is happening under the hood:

Code:
Select Code
dev_wlc_ioctl(dev, WLC_SET_PASSIVE_SCAN, &as, sizeof(as));
The other bcmdhd mystery is how the MAC address gets set. When the interface is down, after a fresh boot, it has a fixed MAC address. But as soon as I run "ifconfig wlan0 up" it gets populated with the real MAC address. Changing the MAC address at runtime sometimes seems to stick; other times it doesn't.
 
kenshin33
Old
#6  
Senior Member
Thanks Meter 55
Posts: 154
Join Date: Mar 2009
Location: Montreal
Quote:
Originally Posted by cernekee View Post
Well, this part of wl_android_priv_cmd() looks discouraging:

Code:
Select Code
	else if (strnicmp(command, CMD_SCAN_ACTIVE, strlen(CMD_SCAN_ACTIVE)) == 0) {
		/* TBD: SCAN-ACTIVE */
	}
	else if (strnicmp(command, CMD_SCAN_PASSIVE, strlen(CMD_SCAN_PASSIVE)) == 0) {
		/* TBD: SCAN-PASSIVE */
	}
Also, I may have missed something obvious, but it isn't clear to me that wl->active_scan can ever get set to false:

Code:
Select Code
$ git grep active_scan drivers/net/wireless/bcmdhd | cat
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:		err = wl_cfgp2p_escan(wl, ndev, wl->active_scan, num_chans, default_chan_list,
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:		passive_scan = wl->active_scan ? 0 : 1;
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	beacon_proberesp = wl->active_scan ?
drivers/net/wireless/bcmdhd/wl_cfg80211.c:	wl->active_scan = true;
drivers/net/wireless/bcmdhd/wl_cfg80211.h:	bool active_scan;	/* current scan mode */
drivers/net/wireless/bcmdhd/wl_iw.c:wl_iw_set_active_scan(
drivers/net/wireless/bcmdhd/wl_iw.c:			ret = wl_iw_set_active_scan(dev, info, (union iwreq_data *)dwrq, extra);
drivers/net/wireless/bcmdhd/wl_iw.c:	(iw_handler)wl_iw_set_active_scan,
I think this line just sends a message to the firmware, so it isn't clear what is happening under the hood:

Code:
Select Code
dev_wlc_ioctl(dev, WLC_SET_PASSIVE_SCAN, &as, sizeof(as));
The other bcmdhd mystery is how the MAC address gets set. When the interface is down, after a fresh boot, it has a fixed MAC address. But as soon as I run "ifconfig wlan0 up" it gets populated with the real MAC address. Changing the MAC address at runtime sometimes seems to stick; other times it doesn't.
seen it somewhere ... if you can find check one of the latest commit in anroid_kernel_samsung_tuna cm's github (they fixed the issus of random mac address each boot, they're still random but not that random).

I think in wl_cfg80211.c in one the init functions either one or the other is set (active/passive).
My guess is that the driver is on active scan by default an there's no "obvious" way of changing it, try fiddeling with those and see what happens
 
cernekee
Old
(Last edited by cernekee; 3rd February 2014 at 06:53 AM.)
#7  
Senior Member - OP
Thanks Meter 350
Posts: 175
Join Date: Jun 2013
Quote:
Originally Posted by kenshin33 View Post
seen it somewhere ... if you can find check one of the latest commit in anroid_kernel_samsung_tuna cm's github (they fixed the issus of random mac address each boot, they're still random but not that random).
Thanks for the pointer. It led me to this commit.

However, there is a difference between my platform (Nexus 7 2012) and their platform: they implement struct wifi_platform_data->get_mac_addr(). On the N7, dhd_custom_get_mac_address() returns -EOPNOTSUPP, so it goes off and queries the hardware for the MAC address:

Code:
Select Code
#ifdef GET_CUSTOM_MAC_ENABLE
	ret = dhd_custom_get_mac_address(ea_addr.octet);
	if (!ret) {
		memset(buf, 0, sizeof(buf));
		bcm_mkiovar("cur_etheraddr", (void *)&ea_addr, ETHER_ADDR_LEN, buf, sizeof(buf));
		ret = dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, buf, sizeof(buf), TRUE, 0);
		if (ret < 0) {
			DHD_ERROR(("%s: can't set custom MAC address , error=%d\n", __FUNCTION__, ret));
			return BCME_NOTUP;
		}
		memcpy(dhd->mac.octet, ea_addr.octet, ETHER_ADDR_LEN);
	} else {
#endif /* GET_CUSTOM_MAC_ENABLE */
		/* Get the default device MAC address directly from firmware */
		memset(buf, 0, sizeof(buf));
		bcm_mkiovar("cur_etheraddr", 0, 0, buf, sizeof(buf));
		if ((ret = dhd_wl_ioctl_cmd(dhd, WLC_GET_VAR, buf, sizeof(buf),
			FALSE, 0)) < 0) {
			DHD_ERROR(("%s: can't get MAC address , error=%d\n", __FUNCTION__, ret));
			return BCME_NOTUP;
		}
		/* Update public MAC address after reading from Firmware */
		memcpy(dhd->mac.octet, buf, ETHER_ADDR_LEN);
#ifdef GET_CUSTOM_MAC_ENABLE
	}
#endif /* GET_CUSTOM_MAC_ENABLE */
Adding printk()s to debug, the first time I see my real hardware address is at the memcpy(). Maybe this is set by the bootloader, or stored in an EEPROM, or something. Unfortunately I didn't see "cur_etheraddr" anywhere else in AOSP.

Another complicating factor: this function (dhd_preinit_ioctls()) runs every time the wlan0 device is opened. wpa_supplicant does the equivalent of an "ifconfig wlan0 up" when it starts. bcmdhd will accept a new MAC address when the interface is already up, but if you change the address while the interface is down, it will be reset back to the original address when it comes back up again. This is the opposite of most standard Linux network drivers.

A consequence of this quirk is that if the user does not check "Scanning always available", which keeps wpa_supplicant running in the background even when wifi is disabled, there is a race between Pry-Fi and wpa_supplicant. wpa_supplicant usually wins the race, leaking the device's true MAC address once before Pry-Fi kicks in.

I suspect that leaving the interface up all of the time will have a noticeable effect on battery life. And while users probably do not disable/enable wifi by hand too often, they might run other utilities that do so, expanding the window of vulnerability.

A more effective technique could involve hooking something like wpa_driver_nl80211_init() in wpa_supplicant so that it tries changing the MAC address before and after bringing up the interface (to cover both types of drivers).

Edit:

Quote:
My guess is that the driver is on active scan by default an there's no "obvious" way of changing it, try fiddeling with those and see what happens
Setting wl->active_scan to false doesn't affect the result, nor does invoking "wldev_ioctl(dev, WLC_SET_PASSIVE_SCAN, &ps, sizeof(ps), 1)" with ps = 1 from wl_android.c.

wl_iw.c doesn't even get compiled into the kernel, so those ioctls probably won't help either.
 
kenshin33
Old
(Last edited by kenshin33; 3rd February 2014 at 08:03 AM.)
#8  
Senior Member
Thanks Meter 55
Posts: 154
Join Date: Mar 2009
Location: Montreal
Quote:
Originally Posted by cernekee View Post
Thanks for the pointer. It led me to this commit.

However, there is a difference between my platform (Nexus 7 2012) and their platform: they implement struct wifi_platform_data->get_mac_addr(). On the N7, dhd_custom_get_mac_address() returns -EOPNOTSUPP, so it goes off and queries the hardware for the MAC address:

Code:
Select Code
#ifdef GET_CUSTOM_MAC_ENABLE
	ret = dhd_custom_get_mac_address(ea_addr.octet);
	if (!ret) {
		memset(buf, 0, sizeof(buf));
		bcm_mkiovar("cur_etheraddr", (void *)&ea_addr, ETHER_ADDR_LEN, buf, sizeof(buf));
		ret = dhd_wl_ioctl_cmd(dhd, WLC_SET_VAR, buf, sizeof(buf), TRUE, 0);
		if (ret < 0) {
			DHD_ERROR(("%s: can't set custom MAC address , error=%d\n", __FUNCTION__, ret));
			return BCME_NOTUP;
		}
		memcpy(dhd->mac.octet, ea_addr.octet, ETHER_ADDR_LEN);
	} else {
#endif /* GET_CUSTOM_MAC_ENABLE */
		/* Get the default device MAC address directly from firmware */
		memset(buf, 0, sizeof(buf));
		bcm_mkiovar("cur_etheraddr", 0, 0, buf, sizeof(buf));
		if ((ret = dhd_wl_ioctl_cmd(dhd, WLC_GET_VAR, buf, sizeof(buf),
			FALSE, 0)) < 0) {
			DHD_ERROR(("%s: can't get MAC address , error=%d\n", __FUNCTION__, ret));
			return BCME_NOTUP;
		}
		/* Update public MAC address after reading from Firmware */
		memcpy(dhd->mac.octet, buf, ETHER_ADDR_LEN);
#ifdef GET_CUSTOM_MAC_ENABLE
	}
#endif /* GET_CUSTOM_MAC_ENABLE */
Adding printk()s to debug, the first time I see my real hardware address is at the memcpy(). Maybe this is set by the bootloader, or stored in an EEPROM, or something. Unfortunately I didn't see "cur_etheraddr" anywhere else in AOSP.

Another complicating factor: this function (dhd_preinit_ioctls()) runs every time the wlan0 device is opened. wpa_supplicant does the equivalent of an "ifconfig wlan0 up" when it starts. bcmdhd will accept a new MAC address when the interface is already up, but if you change the address while the interface is down, it will be reset back to the original address when it comes back up again. This is the opposite of most standard Linux network drivers.

A consequence of this quirk is that if the user does not check "Scanning always available", which keeps wpa_supplicant running in the background even when wifi is disabled, there is a race between Pry-Fi and wpa_supplicant. wpa_supplicant usually wins the race, leaking the device's true MAC address once before Pry-Fi kicks in.

I suspect that leaving the interface up all of the time will have a noticeable effect on battery life. And while users probably do not disable/enable wifi by hand too often, they might run other utilities that do so, expanding the window of vulnerability.

A more effective technique could involve hooking something like wpa_driver_nl80211_init() in wpa_supplicant so that it tries changing the MAC address before and after bringing up the interface (to cover both types of drivers).

Edit:



Setting wl->active_scan to false doesn't affect the result, nor does invoking "wldev_ioctl(dev, WLC_SET_PASSIVE_SCAN, &ps, sizeof(ps), 1)" with ps = 1 from wl_android.c.

wl_iw.c doesn't even get compiled into the kernel, so those ioctls probably won't help either.
custom_get_mac_address doesnt'seem to do much
from grouper's :
Code:
Select Code
int
dhd_custom_get_mac_address(unsigned char *buf)
{
        int ret = 0;

        WL_TRACE(("%s Enter\n", __FUNCTION__));
        if (!buf)
                return -EINVAL;

        /* Customer access to MAC address stored outside of DHD driver */
#if defined(CUSTOMER_HW2) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35))
        ret = wifi_get_mac_addr(buf);
#endif

#ifdef EXAMPLE_GET_MAC
        /* EXAMPLE code */
        {
                struct ether_addr ea_example = {{0x00, 0x11, 0x22, 0x33, 0x44, 0xFF}};
                bcopy((char *)&ea_example, buf, sizeof(struct ether_addr));
        }
#endif /* EXAMPLE_GET_MAC */

        return ret;
}
wifi_get_mac_addr(buf);
si an external function defined in wl_android.c

Code:
Select Code
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35))
int wifi_get_mac_addr(unsigned char *buf)
{
        DHD_ERROR(("%s\n", __FUNCTION__));
        if (!buf)
                return -EINVAL;
        if (wifi_control_data && wifi_control_data->get_mac_addr) {
                return wifi_control_data->get_mac_addr(buf);
        }
        return -EOPNOTSUPP;
}
#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35)) */
as you can see it puts something in buf and returns -EOPNOTSUPP; no matter what.
the actual changing if possible is done with what''s inside the if

without recompiling the kernel try it ou with dhdutil
Code:
Select Code
int
_dhd_set_mac_address(dhd_info_t *dhd, int ifidx, struct ether_addr *addr)
{
        char buf[32];
        wl_ioctl_t ioc;
        int ret;

        if (!bcm_mkiovar("cur_etheraddr", (char*)addr, ETHER_ADDR_LEN, buf, 32)) {
                DHD_ERROR(("%s: mkiovar failed for cur_etheraddr\n", dhd_ifname(&dhd->pub, ifidx)));
                return -1;
        }
        memset(&ioc, 0, sizeof(ioc));
        ioc.cmd = WLC_SET_VAR;
        ioc.buf = buf;
        ioc.len = 32;
        ioc.set = TRUE;

        ret = dhd_wl_ioctl(&dhd->pub, ifidx, &ioc, ioc.buf, ioc.len);
        if (ret < 0) {
                DHD_ERROR(("%s: set cur_etheraddr failed\n", dhd_ifname(&dhd->pub, ifidx)));
        } else {
                memcpy(dhd->iflist[ifidx]->net->dev_addr, addr, ETHER_ADDR_LEN);
                memcpy(dhd->pub.mac.octet, addr, ETHER_ADDR_LEN);
        }

        return ret;
}
that's from dhd_linux.c (under hardware/broadcom/ .... )
may be there's a way to do so with dhdutil (don't remeber all the possible things and both phone and tablet are far away )

EDIT : no dhdutil doesn't seem to have that !

the ioctl seems to end up here :

int
dhd_prot_ioctl(dhd_pub_t *dhd, int ifidx, wl_ioctl_t * ioc, void * buf, int len)
in dhd_cdc.c
 
cernekee
Old
#9  
Senior Member - OP
Thanks Meter 350
Posts: 175
Join Date: Jun 2013
Quote:
Originally Posted by kenshin33 View Post
Code:
Select Code
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35))
int wifi_get_mac_addr(unsigned char *buf)
{
        DHD_ERROR(("%s\n", __FUNCTION__));
        if (!buf)
                return -EINVAL;
        if (wifi_control_data && wifi_control_data->get_mac_addr) {
                return wifi_control_data->get_mac_addr(buf);
        }
        return -EOPNOTSUPP;
}
#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 35)) */
as you can see it puts something in buf and returns -EOPNOTSUPP; no matter what.
the actual changing if possible is done with what''s inside the if
On tuna this should set the random (or not-so-random) MAC from rand_mac, then return 0:

https://github.com/CyanogenMod/andro...na-wifi.c#L288

But Tegra doesn't implement the get_mac_addr() callback, so bcmdhd will fall through to the -EOPNOTSUPP case and then query the firmware:

https://android.googlesource.com/ker...rouper-sdhci.c
 
kenshin33
Old
#10  
Senior Member
Thanks Meter 55
Posts: 154
Join Date: Mar 2009
Location: Montreal
Quote:
Originally Posted by cernekee View Post
On tuna this should set the random (or not-so-random) MAC from rand_mac, then return 0:

https://github.com/CyanogenMod/andro...na-wifi.c#L288

But Tegra doesn't implement the get_mac_addr() callback, so bcmdhd will fall through to the -EOPNOTSUPP case and then query the firmware:

https://android.googlesource.com/ker...rouper-sdhci.c
you can may be copy it ?
(it doesn;t seem to do much except filling a buffer with data)

(as does the one from LGE msm for hammerhead, but reads from a file in /persiste/wifi/)

Tags
pri-fi, privacy, wifi
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes