Chainfire
Moderator Emeritus / Senior Recognized Developer
You need to use the -p and -i options to point wpa_cli to the correct control socket
( "-p/data/misc/wifi/sockets -iwlan0" in my case )
I have no idea what you're talking about ...
You need to use the -p and -i options to point wpa_cli to the correct control socket
( "-p/data/misc/wifi/sockets -iwlan0" in my case )
I have no idea what you're talking about ...
check
wpa_supplicant_8/wpa_supplicant/scan.c
line 748 that is where the scan for specific SSID is triggered mainly becase some variable named max_ssid is set at some point to 1
I did test (AOSP/CM) no leak,
all I see wireshark are Prob requests with SSD set to NULL.
the only names that appears is the SSID of my AP when it is associating
(On a nexus 5)
given enough time though the whole list appears. wth no logs from wpa_supplicant (neither on wpa_cli no logcat)
Last edited:
Chainfire
Moderator Emeritus / Senior Recognized Developer
The plot thickens.
The logs as far as I can see always state "Starting AP scan for wildcard SSID", not the "Interleave with specific" variant. So maybe it is max_ssid==1 that is the culprit, which from skimming through the related code seems unlikely to be 1 anyway.
"Starting AP scan for wildcard SSID" <-- this I see a lot
the interleave with ... didn;t see at all.
it seems systematic, press the power button to send the device to sleep and there you have it
in dmesg :
<4>[44401.626645] dhdsdio_bussleep: request WAKE (currently SLEEP)
<4>[44401.687730] wl_android_priv_cmd: Android private cmd "SETSUSPENDMODE 1" on wlan0
<4>[44401.692498] wl_android_set_suspendmode: Suspend Mode 1
<4>[44401.750066] dhdsdio_bussleep: request SLEEP (currently WAKE)
right after that I get the list on wireshark
but doing so in wpa_cli doesn't i.e:
> driver SETSUSPENDMODE 1
wpa_cli_cmd_driver: DRIVER SETSUSPENDMODE 1
OK
dmesg reports it but nothing happens in wireshark
EDIT :
D/wpa_supplicant(10715): wlan0: nl80211: sched_scan request
D/wpa_supplicant(10715): nl80211: Sched scan requested (ret=0) - scan interval 10000 msec
D/wpa_supplicant(10715): nl80211: Drv Event 75 (NL80211_CMD_START_SCHED_SCAN) received for wlan0
D/wpa_supplicant(10715): wlan0: nl80211: Sched scan started
D/wpa_supplicant(10715): RX ctrl_iface - hexdump(len=23): 44 52 49 56 45 52 20 53 45 54 53 55 53 50 45 4e 44 4d 4f 44 45 20 31
D/wpa_supplicant(10715): wlan0: Control interface command 'DRIVER SETSUSPENDMODE 1'
D/wpa_supplicant(10715): wpa_driver_nl80211_driver_cmd len = 0, 0
in logcat whenever the device goes to sleep (press the button)
NL80211_CMD_START_SCHED_SCAN seems to be related
this the function :
wpa_driver_nl80211_sched_scan , someone is calling it with the whole PNL.
EDIT I think I narrowed it down to pno_start
Code:
static int pno_start(struct wpa_supplicant *wpa_s)
{
int ret, interval;
size_t i, num_ssid;
struct wpa_ssid *ssid;
struct wpa_driver_scan_params params;
if (wpa_s->pno)
return 0;
if ((wpa_s->wpa_state > WPA_SCANNING) &&
(wpa_s->wpa_state <= WPA_COMPLETED)) {
wpa_printf(MSG_ERROR, "PNO: In assoc process");
return -EAGAIN;
}
if (wpa_s->wpa_state == WPA_SCANNING) {
wpa_supplicant_cancel_sched_scan(wpa_s);
wpa_supplicant_cancel_scan(wpa_s);
}
os_memset(¶ms, 0, sizeof(params));
num_ssid = 0;
ssid = wpa_s->conf->ssid;
while (ssid) {
if (!wpas_network_disabled(wpa_s, ssid))
num_ssid++;
ssid = ssid->next;
}
if (num_ssid > WPAS_MAX_SCAN_SSIDS) {
wpa_printf(MSG_DEBUG, "PNO: Use only the first %u SSIDs from "
"%u", WPAS_MAX_SCAN_SSIDS, (unsigned int) num_ssid);
num_ssid = WPAS_MAX_SCAN_SSIDS;
}
if (num_ssid == 0) {
wpa_printf(MSG_DEBUG, "PNO: No configured SSIDs");
return -1;
}
params.filter_ssids = os_malloc(sizeof(struct wpa_driver_scan_filter) *
num_ssid);
if (params.filter_ssids == NULL)
return -1;
i = 0;
ssid = wpa_s->conf->ssid;
while (ssid) {
if (!wpas_network_disabled(wpa_s, ssid)) {
params.ssids[i].ssid = ssid->ssid;
params.ssids[i].ssid_len = ssid->ssid_len;
params.num_ssids++;
os_memcpy(params.filter_ssids[i].ssid, ssid->ssid,
ssid->ssid_len);
params.filter_ssids[i].ssid_len = ssid->ssid_len;
params.num_filter_ssids++;
i++;
if (i == num_ssid)
break;
}
ssid = ssid->next;
}
if (wpa_s->conf->filter_rssi)
params.filter_rssi = wpa_s->conf->filter_rssi;
interval = wpa_s->conf->sched_scan_interval ?
wpa_s->conf->sched_scan_interval : 10;
ret = wpa_drv_sched_scan(wpa_s, ¶ms, interval * 1000);
os_free(params.filter_ssids);
if (ret == 0)
wpa_s->pno = 1;
return ret;
}something to do with scan offload or something like that ...
Last edited:
Yes that's it. I see the same thing on my N5, coinciding with PNO getting enabled at boot time:
Code:
I/wpa_supplicant( 1712): wpa_supplicant_global_ctrl_iface_receive: 'IFNAME=wlan0 SET pno 0'
I/wpa_supplicant( 1712): wpa_supplicant_global_ctrl_iface_receive: 'IFNAME=wlan0 SET pno 1'
I/wpa_supplicant( 1712): wpa_driver_nl80211_sched_scan: scan 1 SSIDs every 10000 ms
E/wpa_supplicant( 1712): nl80211: XXX leaking SSID name - hexdump(len=7): 61 62 63 64 65 66 67
E/wpa_supplicant( 1712): nl80211: XXX leaking SSID name - hexdump(len=7): 31 32 33 34 35 36 37My debug binary is attached; patch is here.
My network config:
Code:
network={
ssid="abcdefg"
key_mgmt=WPA-PSK
psk="99999999"
priority=1
}
network={
ssid="1234567"
key_mgmt=WPA-PSK
psk="99999999"
priority=2
}Backtrace:
Code:
#00 pc 00079f70 /system/bin/wpa_supplicant (XXX_SSID_LEAK+3)
#01 pc 0007a00b /system/bin/wpa_supplicant (nl80211_scan_common+138)
#02 pc 0007a12d /system/bin/wpa_supplicant (wpa_driver_nl80211_sched_scan+64)
#03 pc 00061d99 /system/bin/wpa_supplicant (wpa_supplicant_ctrl_iface_set+784)
#04 pc 00062729 /system/bin/wpa_supplicant (wpa_supplicant_ctrl_iface_process+520)
#05 pc 000651cd /system/bin/wpa_supplicant (wpa_supplicant_global_ctrl_iface_process+1240)
#06 pc 0006546d /system/bin/wpa_supplicant (wpa_supplicant_global_ctrl_iface_receive+156)
#07 pc 0000a25f /system/bin/wpa_supplicant (eloop_sock_table_dispatch+58)
#08 pc 0000a91d /system/bin/wpa_supplicant (eloop_run+400)
#09 pc 0006a33b /system/bin/wpa_supplicant (wpa_supplicant_run+58)
#10 pc 00070d27 /system/bin/wpa_supplicant (main+718)
#11 pc 0000e34b /system/lib/libc.so (__libc_init+50)
#12 pc 00005f30 /system/bin/wpa_supplicant (_start+96)These can also be reproduced on demand by running wpa_cli and doing:
Code:
> IFNAME=wlan0 set pno 0
OK
IFNAME=wlan0 <3>CTRL-EVENT-SCAN-RESULTS
IFNAME=wlan0 <3>WPS-AP-AVAILABLE
IFNAME=p2p0 <3>CTRL-EVENT-SCAN-RESULTS
IFNAME=p2p0 <3>WPS-AP-AVAILABLE
> IFNAME=wlan0 set pno 1
OKpno = Preferred Network Offload. The Honeycomb 3.1 release notes say:
I do see the "abcdefg" probe request pop up in wireshark about once a minute with the screen off. There is no logcat activity from my instrumentation when this happens. It is possible that the WLAN chipset handles this autonomously while the host remains in deep sleep.
PNO gets enabled based on the device configuration; this property is used to set WifiStateMachine.mBackgroundScanSupported:
Code:
$ rgrep config_wifi_background_scan_support device/ 2> /dev/null
device/lge/mako/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/lge/hammerhead/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/samsung/manta/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/asus/flo/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/asus/tilapia/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/asus/grouper/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>
device/asus/deb/overlay/frameworks/base/core/res/res/values/config.xml: <bool translatable="false" name="config_wifi_background_scan_support">true</bool>It defaults to false if left unspecified.
I found that deleting the key_mgmt and psk lines for a network prevents it from being added to the probe request. I didn't find the code that implements this logic yet, but it's probably there to keep an attacker from eavesdropping for your probe request and then instantly setting up an open AP with the same SSID that your phone will then try to connect to.
Chainfire said:
I have updated the wording in the OP to make this clearer. Thanks for the feedback.
What do you think about using a "wpa_mitm" daemon, running as root, to intercept/rewrite messages on the wpa_supplicant socket? This could do things like:
- Force pno=0 unconditionally
- Coordinate the timing of interface MAC address changes with supplicant activity
- Read/edit wpa_supplicant.conf through the socket interface (if necessary) so that everyone accessing the information stays in sync
may add variable to wpa_supp, and checkit in android_start_pno?
scan offloading is disabled in wpa_supplicant.conf but this is enabled
I didn;t check in kernel what the deal with offloading scans, dhd_pno states clearly that an epty list -ie broadcast is not supported-
if the point was to save power ... even more power will be saved if the scan was passive ...
Chainfire
Moderator Emeritus / Senior Recognized Developer
Yes, I believe that is its intent - the WLAN chipset doing the scanning while the main CPU sleeps.
What I don't know yet, and which I think will be very important to learn before going any further, is determining what happens with the results of these offloaded scans. It the main CPU woken up when a network is found? Does the WLAN chip automatically connect and wake the main CPU? What?
I think in that case it fails the wpas_network_disabled() check.
Yes, that might be a good solution, I'll have to do some thinking on that though, there's a long list of complications that need to be solved, not in the least dealing with the different versions of wpa_supplicant out there. I'll probably be able to start a lot of testing on this today. (I'll elaborate later, need to go out for now)
EDIT: yeah I think it's possible, going to take me a few days to do the PoC code though
Last edited:
Check this out - Patched wpa_supplicant to scan for APs passively:
http://xdaforums.com/showthread.php?p=51139790
cernekee, your info was essential, thank you.
http://xdaforums.com/showthread.php?p=51139790
cernekee, your info was essential, thank you.
Last edited:
This topic made the news again: iOS 8 randomises the MAC address while scanning for WiFi networks
One of the comments mentioned that the wpa_supplicant maintainers are thinking about making MAC address randomization a standard feature. According to Jouni's post, the best way to implement this might involve enhancing the user/kernel "cfg80211" interface. This wouldn't be easy to do from an Android app (at least not portably) but once the infrastructure is present, it should percolate into future ROMs.
One of the comments mentioned that the wpa_supplicant maintainers are thinking about making MAC address randomization a standard feature. According to Jouni's post, the best way to implement this might involve enhancing the user/kernel "cfg80211" interface. This wouldn't be easy to do from an Android app (at least not portably) but once the infrastructure is present, it should percolate into future ROMs.
Provided the address doesn't change between sessions (only on association and connection) there is no issue with changing addresses.
Chainfire
Moderator Emeritus / Senior Recognized Developer
Chainfire
Moderator Emeritus / Senior Recognized Developer
EFF is letting their voice be heard on this subject:
https://www.eff.org/deeplinks/2014/07/your-android-device-telling-world-where-youve-been
A Googler submitted a patch to wpa_supplicant yesterday about this:
http://w1.fi/cgit/hostap/commit/?h=pending&id=4ed3492206097c24aa37b4429938fec049ba1827
If anyone is still interested in this debate ( @cernekee ?), I find that patch very curious. There's not that much information out there about PNO, but as I understood it, it's primary purpose is allowing the device to notice Wi-Fi networks it knows while the main CPU is asleep, so it can then wake the main CPU to take action. The scanning PNO does is implemented in the Wi-Fi firmware.
With this patch to wpa_supplicant, only manually added and hidden networks will be handed over to be scanned by the PNO feature. While this obviously prevents leakage of the names of the other configured Wi-Fi networks, this would then also mean those latter Wi-Fi networks (which would be most of the networks you normally use, for most people) are no longer scanned for at all, if the main CPU is sleeping.
To me it seems that for most cases this completely negates the use of PNO. If you're building a firmware and disable PNO support completely, in that case Android would wake up the CPU every few minutes to manually scan and connect to any known network (without the leaking), while with PNO you'd end up only connecting to hidden/manual networks (while the main CPU is sleeping).
Of course it is possible that Google is also modifying Android itself to keep doing those scans every few minutes even if PNO is enabled with this new patch, this can't be learned from this specific commit. Then I don't see the use for enabling PNO at all though ...
Seems to me that it would be much better if the Wi-Fi chips firmwares were updated, so PNO only broadcasts the hidden/manual SSIDs, but still checks for all the others ones as well.
Thoughts?
https://www.eff.org/deeplinks/2014/07/your-android-device-telling-world-where-youve-been
A Googler submitted a patch to wpa_supplicant yesterday about this:
http://w1.fi/cgit/hostap/commit/?h=pending&id=4ed3492206097c24aa37b4429938fec049ba1827
If anyone is still interested in this debate ( @cernekee ?), I find that patch very curious. There's not that much information out there about PNO, but as I understood it, it's primary purpose is allowing the device to notice Wi-Fi networks it knows while the main CPU is asleep, so it can then wake the main CPU to take action. The scanning PNO does is implemented in the Wi-Fi firmware.
With this patch to wpa_supplicant, only manually added and hidden networks will be handed over to be scanned by the PNO feature. While this obviously prevents leakage of the names of the other configured Wi-Fi networks, this would then also mean those latter Wi-Fi networks (which would be most of the networks you normally use, for most people) are no longer scanned for at all, if the main CPU is sleeping.
To me it seems that for most cases this completely negates the use of PNO. If you're building a firmware and disable PNO support completely, in that case Android would wake up the CPU every few minutes to manually scan and connect to any known network (without the leaking), while with PNO you'd end up only connecting to hidden/manual networks (while the main CPU is sleeping).
Of course it is possible that Google is also modifying Android itself to keep doing those scans every few minutes even if PNO is enabled with this new patch, this can't be learned from this specific commit. Then I don't see the use for enabling PNO at all though ...
Seems to me that it would be much better if the Wi-Fi chips firmwares were updated, so PNO only broadcasts the hidden/manual SSIDs, but still checks for all the others ones as well.
Thoughts?
Last edited:
I'm not sure that is the main purpose. I think the main purpose would be to use a (preferred/known) WiFi network when that is available, to make various services updates, instead of using the mobile network, thus saving energy and packet data money. This is useful for apps constantly using the network, like Facebook, Viber, weather and so on. About the sleep policy, I don't know, but I would assume it doesn't matter wheather the phone is sleeping or not. If it is sleeping, ok then perhaps it's woken up. And if not, then that particular WiFi connection is used instead of 3/4G.
Why do you say that? I certainly don't use any other WiFi networks, than those I have added manually.
Chainfire
Moderator Emeritus / Senior Recognized Developer
Your explanation doesn't make any sense, as PNO is only used when the main CPU is asleep (so no apps can communicate), and the only information it gets from wpa_supplicant is the names of the networks to connect to, as I can see it.
I don't mean one you've tapped to connect to, then entered the password, but ones you add fully manually, including typing in the network name and manually picking the encryption settings.
Well then I just can't see any point of having PNO on at all. What is that, another marketing trick? I don't care if my wifi connection take 1 second longer to be established, as long as I can be confident its not spewing my personal data all over the ether. Remove it.
WTF! I had no idea it made that distinction. That is sickening. So in what files are these two distinct lists kept? I wanna check this out. (Another chicken whim from the head-less Android development team?)
Could it be that this patch would have wpa_supplicant include a wildcard SSID, together with the list of hidden networks, so PNO would effectively ask every network in range (including any known hidden networks) to reply? Reading the comment on the following line (which is called only when num_match_ssid > num_ssid, and thus when any non-hidden network is in the user's PNL) made me suspect this:
Code:
+ params.num_ssids++; /* wildcard */I'm not sure how this would work, though, as it would then need to wake up the CPU as soon as *any* network is in range (unless the Wi-Fi chip has another way of knowing which networks it should look for). I agree that the only real solution seems to be to fix it at the level of the firmware.
The last response in this very interesting topic being over 3 years old, I'd be interested if anyone has been following the Android Wi-Fi security developments and could tell us something about the current state.
One article from 2017 I found stated:
One article from 2017 I found stated:
arstechnica.com/information-technology/2017/03/shielding-mac-addresses-from-stalkers-is-hard-android-is-failing-miserably/
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
11Over 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:# 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:# 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:D/wpa_supplicant(19967): wlan0: Control interface command 'SCAN' D/wpa_supplicant(19967): wlan0: Setting scan request: 0 sec 0 usec [color=red]D/wpa_supplicant(19967): Scan SSID - hexdump(len=7): 61 74 74 77 69 66 69[/color] 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 [color=red]D/wpa_supplicant(19967): nl80211: Scan SSID - hexdump(len=7): 61 74 74 77 69 66 69[/color] [color=blue]D/wpa_supplicant(19967): nl80211: Scan SSID - hexdump(len=0): [NULL][/color]
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?7FYI, I feel releasing source at this point is premature. I'm not really trying to hide anything here. If you really want the source right now I'll even give it to you (cernekee)
However, a lot of devices work in a slightly different way, and I wanted to get it out there to see how it would work out. After a lot of feedback, test versions, releases, etc (even though its only been 3 days) I feel a part of the core logic may need to be redesigned to incorporate the new knowledge (some even from this thread) to make it work better.
What I specifically don't want is a dozen or so source happy OSS zealots jumping on it, declaring which parts are ****, doing a dozen forks that aren't compatible with each-other, fixing one device and breaking another, the whole circus. I'd rather it's at least semi-stable before everybody goes running off with it. And I don't need everybody looking over my shoulder or explaining/debating every line of code thrice while re-doing half the core.
Patience... also because now its no longer weekend and I have contract work to do aside from this.
Also, if one were to incorporate this into a custom firmware, I would use a very different methods than I did in Pry-Fi. I might actually be committing those changes to Omni, but I can't do everything at once.2
The background scan intervals are determined by these security settings (http://androidxref.com/4.4.2_r1/xref/frameworks/base/core/java/android/provider/Settings.java):
wifi_supplicant_scan_interval_ms
wifi_framework_scan_interval_ms
which in turn are sourced from these config values:
config_wifi_supplicant_scan_interval (15000 in AOSP)
config_wifi_framework_scan_interval (300000 in AOSP)
Inside the settings activity, it is determined by the WIFI_RESCAN_INTERVAL_MS field which is 10000 by default in AOSP (http://androidxref.com/4.4.2_r1/xre...ifi/WifiSettings.java#WIFI_RESCAN_INTERVAL_MS)
I didn't see you mention this anywhere else, but the above doesn't appear to be entirely true, or is incomplete. On my test devices, there aren't any networks at all with scan_ssid=1, yet my MBA running Wireshark 24/7 (finally a use for a Mac) regularly intercepts the list of SSIDs (if Pry-Fi is not enabled). Certainly not as often as normal scans, but they're definitely still broadcast.
If you could quickly re-hash why there is no extra security in disabling SSID broadcasts, without having to review the entire Vivek video series, that'd be great.
It's not a security app, it's a privacy app, and you can't do this on a non-custom firmware without root, so I don't really see the point about complaining that its a security app that runs as root - most apps that do anything significant security or privacy wise do (requiring a framework/system modification and then not requesting root access is not an excuse, you still need root access for this at some point).
As for strange interactions, as documented, this is caused by the app having to change Wi-Fi states to let the MAC changes work. If it works as (currently) intended all you'd see is Wi-Fi going off/on again rapidly once or twice, and only if you are watching the settings->wifi screen. If anything else weird is going on, feel free to elaborate.
Have you actually reviewed this (and solutions like this) ? Do they even turn Wi-Fi fully off, including the background scanning ? AFAIK that's not possible without leveraging some form of root or system modification. And if it does uses that, it should be listed as a con because its a "security" app that runs as root. If it's a con for one app...
Also I would like to list as an additional con that this (fairly dramatically) reduces location determination speed and accuracy for location-based apps, which may or may not be an issue for the user.1
Provided the address doesn't change between sessions (only on association and connection) there is no issue with changing addresses.
