FORUMS
Remove All Ads from XDA

Understanding Pry-Fi and 802.11 probe requests

186 posts
Thanks Meter: 422
 
By cernekee, Senior Member on 2nd February 2014, 08:08 PM
Post Reply Email Thread
3rd February 2014, 10:24 AM |#11  
Chainfire's Avatar
Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,034
 
Donate to Me
More
Quote:
Originally Posted by cernekee

  • 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.

The background scan intervals are determined by these security settings (http://androidxref.com/4.4.2_r1/xref.../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/xref...AN_INTERVAL_MS)

Quote:
Originally Posted by cernekee

  • 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).

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.

Quote:
Originally Posted by cernekee

  • 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.

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.

Quote:
Originally Posted by cernekee

  • 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.

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.

Quote:
Originally Posted by cernekee

  • 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.

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.
The Following 2 Users Say Thank You to Chainfire For This Useful Post: [ View ]
 
 
3rd February 2014, 01:32 PM |#12  
Chainfire's Avatar
Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,034
 
Donate to Me
More
FYI, 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.
The Following 7 Users Say Thank You to Chainfire For This Useful Post: [ View ]
3rd February 2014, 02:29 PM |#13  
Senior Member
Thanks Meter: 379
 
More
Quote:
Originally Posted by Chainfire

FYI, 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.

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.

i think the main concern with many folks, as you just pointed out, is the idea of a root app and no way to review code, but thats not to pick on anyone in particular, its anyone and everyone, even cadilacs amongst men such as youself chainfire ....... its just a general thinking, sometimes folks like myself will sacrafice that concern if app/author usability outweighs that concern, so something like open source would alleviate that somewhat.......

im glad to hear the reason and your thoughts on this, happy to see where you are hoping to take it
3rd February 2014, 04:32 PM |#14  
Senior Member
Flag Montreal
Thanks Meter: 135
 
More
Quote:
Originally Posted by Chainfire

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.

http://www.howtogeek.com/howto/28653...y-more-secure/

Quote:

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...

I use LLAMA to disable wifi when not home or at the university b/c of battery and also I don;t really trust wifi hotspots out there, if there's a malicious one out there you PNL and mac address are the least of your concernes (especially the "OK/CONTINUE" trigger happy users).
GPS locks fairly quicly most of the time, if not I enable wifi at that point just to get a fix quicker, (the only time I really need it is for bus schedules, -- any other extended --navigation-- use will need very high acuracy and GPS should be on, so no need to drain the battry more with wifi), but that's just me.


As for a solution, finding a way to enable passive scan mode would be great, and sould solve the leak, no root not fiddeling needed (passive mode don;t send beacons, just listen to beacons sent out by AP, and for the life of me I don;t understand why would a client sned a beacon while the AP is expected to?)

Random : see what cm did with tuna kernel (random but not so random)

just my 2 cents

Also there's ap_scan variable in wpa_supplicant, not sure what it does but it have some influance.
3rd February 2014, 05:01 PM |#15  
OP Senior Member
Thanks Meter: 422
 
More
Quote:
Originally Posted by kenshin33

you can may be copy it ?

I could copy the code that populates the MAC address, and omit the parts that calculate it from the OMAP chip ID. But that doesn't tell me where my unique N7 WLAN-firmware-supplied MAC address actually came from.

I'll have to do some more research here...

Quote:
Originally Posted by Chainfire

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.

Are you seeing any of these messages in logcat: "Scan SSID", "Starting AP scan for specific SSID:", or "Include wildcard SSID in the scan request"?

Are there real AP names in the request, or just P2P names?

The code in wpa_supplicant_scan() which writes out the list of SSIDs to pass to the driver via params.ssids is:

Code:
		while (ssid) {
			if (!wpas_network_disabled(wpa_s, ssid) &&
			    ssid->scan_ssid) {
				wpa_hexdump_ascii(MSG_DEBUG, "Scan SSID",
						  ssid->ssid, ssid->ssid_len);
				params.ssids[params.num_ssids].ssid =
					ssid->ssid;
				params.ssids[params.num_ssids].ssid_len =
					ssid->ssid_len;
				params.num_ssids++;
				if (params.num_ssids + 1 >= max_ssids)
					break;
			}
			ssid = ssid->next;
			if (ssid == start)
				break;
			if (ssid == NULL && max_ssids > 1 &&
			    start != wpa_s->conf->ssid)
				ssid = wpa_s->conf->ssid;
		}
In my tests, the logic did work as expected. Some factors that may account for variations could include:
  • Android version and/or wpa_supplicant version: 4.2.2 and wpa_supplicant_8 v2.0-devel-4.2.2
  • OS: CM/AOSP, no Samsung
  • Drivers: bcmdhd in the kernel, and nl80211 in wpa_supplicant
  • Observation time (not 24/7 here), and on-demand scans vs. scheduled scans

Quote:

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.

While disabling SSID broadcasts takes the string out of the beacon, it still appears in the association requests. So there are two easy ways to expose the SSID of a hidden network:
  • Run airodump-ng, or the equivalent point-and-click GUI tool, and just passively wait around for a client to (re)associate. Then the name will pop up on the screen.
  • Use "aireplay-ng --deauth" to kick one STA (unicast) or all STAs (broadcast) off the network. Most will reassociate, leaking the SSID name.

Also, from what I've seen, hiding the SSID doesn't consistently turn off the beacons; it just sends an empty SSID field. So the AP is still broadcasting its presence + BSSID.

Quote:

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.

I ran into the "forget network" caveat earlier. It would be nice to make this more seamless.

Quote:

Also, if one were to incorporate this into a custom firmware, I would use a very different methods than I did in Pry-Fi.

Agreed - that is one reason I started a separate thread to discuss options.

Personally I don't mind hacking my ROM if it results in a cleaner, but less generic, solution.

Quote:

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

banderos101 pretty much covered this. No issue with running as root, as long as it's easy to see (and change) how it all works.

Security- and privacy- conscious individuals tend to get a little control-freaky about what they're running on their systems:

Quote:

I don't need everybody looking over my shoulder or explaining/debating every line of code thrice

In security/privacy/crypto circles, that is usually a feature not a bug.
3rd February 2014, 05:23 PM |#16  
Senior Member
Flag Montreal
Thanks Meter: 135
 
More
Quote:
Originally Posted by cernekee

I could copy the code that populates the MAC address, and omit the parts that calculate it from the OMAP chip ID. But that doesn't tell me where my unique N7 WLAN-firmware-supplied MAC address actually came from.

I'll have to do some more research here...

The function as it is just populates the mac in a buffer, if it has to fail it will fail later , while "setting it", Unfortunatly I can't test it out (my grouper has a broken screen, flo/hammerhead should, so no point in testing).
3rd February 2014, 05:39 PM |#17  
Chainfire's Avatar
Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,034
 
Donate to Me
More
Quote:
Originally Posted by cernekee

Are you seeing any of these messages in logcat: "Scan SSID", "Starting AP scan for specific SSID:", or "Include wildcard SSID in the scan request"?

I'll see if I can correlate the timings of the logcat messages with the scans

Quote:

In my tests, the logic did work as expected. Some factors that may account for variations could include:

  • Android version and/or wpa_supplicant version: 4.2.2 and wpa_supplicant_8 v2.0-devel-4.2.2
  • OS: CM/AOSP, no Samsung
  • Drivers: bcmdhd in the kernel, and nl80211 in wpa_supplicant
  • Observation time (not 24/7 here), and on-demand scans vs. scheduled scans

FWIW, I've done the main testing on a stock+root Nexus 5 @ 4.4.2. This is the one broadcasting all the SSIDs. I think I recall seeing it on my Samsung test devices as well, but I'd have to test again to be 100%.

Quote:

While disabling SSID broadcasts takes the string out of the beacon, it still appears in the association requests. So there are two easy ways to expose the SSID of a hidden network:

  • Run airodump-ng, or the equivalent point-and-click GUI tool, and just passively wait around for a client to (re)associate. Then the name will pop up on the screen.
  • Use "aireplay-ng --deauth" to kick one STA (unicast) or all STAs (broadcast) off the network. Most will reassociate, leaking the SSID name.

Ah this is a misscommunication then. I thought we were talking about the added security of not broadcasting every SSID your device has ever heard of, not of the practise of making an AP hidden.

Quote:

I ran into the "forget network" caveat earlier. It would be nice to make this more seamless.

Hence the manage networks option inside the app (which still also doesn't work half the time) ... This definitely needs some work.

Quote:

Agreed - that is one reason I started a separate thread to discuss options.

Personally I don't mind hacking my ROM if it results in a cleaner, but less generic, solution.

Agreed. That's not my own primary aim though. The stock+root crowd is factors larger than the custom ROM crowd, so they come first to me.

For Pry-Fi itself I think a large chunk of weirdness can be covered by moving a part of code to use wpa_cli commands instead. But first I have to test how well that even works cross-OEM. That alone will take a few days, even before implementing anything. So many devices - and at least Samsung modifies wpa_supplicant.

Quote:

banderos101 pretty much covered this. No issue with running as root, as long as it's easy to see (and change) how it all works.

Security- and privacy- conscious individuals tend to get a little control-freaky about what they're running on their systems:

I know, but passive aggressive statements and generally being more naggish than a pack of wild Jehovah's Witnesses got tiring a few decades ago - I can't possibly reward that behavior.

Quote:

In security/privacy/crypto circles, that is usually a feature not a bug.

You are undoubtedly used to working with a different class of coders than I am. If I had a dollar for every pages-long criticism based on not actually reading the code, or vague assumptions made without actually reading the code, or trivial questions that could be answered simply by reading the code, or in-depth discussions about code clearly marked as 'should be replaced by something less half-assed' ... it just ruins my productivity as well as all will to code. After a chunk of code is complete is a different matter, of course, I just don't like being annoyed during my code time.

You can say it sucks when the painting is finished, not before.
3rd February 2014, 06:07 PM |#18  
Senior Member
Thanks Meter: 379
 
More
Quote:
Originally Posted by Chainfire

I know, but passive aggressive statements and generally being more naggish than a pack of wild Jehovah's Witnesses got tiring a few decades ago - I can't possibly reward that behavior.


You can say it sucks when the painting is finished, not before.

Ah, maaan, but im so good at passive aggresive statements, wheres the love

Joking aside, i see your point, to be honest im surprised your still with us, but glad you still are, otherwise, no pry-fi, and many other great apps, and contributions

so, sorry, and i hate you .........passive aggressive, got it licked

Disclaimer:
i dont hate you
3rd February 2014, 06:44 PM |#19  
Chainfire's Avatar
Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,034
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

I'll see if I can correlate the timings of the logcat messages with the scans

I'm not sure the reason why, but it seems the wpa_cli I compiled from AOSP does does not play nice with the stock wpa_supplicant on my Nexus 5 (potentially killing a lot of Pry-Fi improvements).

Bot claim to be "v2.1-devel-4.4.2" though.

I can't get any of the commands you have listed to do anything useful. For example, "scan" just throws "unknown command" at me.

All I really see coming out at this time is "IFNAME=wlan0 <3>CTRL-EVENT-SCAN-RESULTS"

EDIT My bad, I had the wrong paramters for wpa_cli, re-checking now

EDIT#2 "Starting AP scan for specific SSID:" happens just before the full-list broadcast, but before a broadcast without the full list of SSID names as well. I don't really see any difference between the scans based on logcat.

EDIT#3 A full SSID-listing scan appears to happen at 120 second intervals
3rd February 2014, 07:58 PM |#20  
Senior Member
Flag Montreal
Thanks Meter: 135
 
More
Quote:
Originally Posted by Chainfire

I'm not sure the reason why, but it seems the wpa_cli I compiled from AOSP does does not play nice with the stock wpa_supplicant on my Nexus 5 (potentially killing a lot of Pry-Fi improvements).

Bot claim to be "v2.1-devel-4.4.2" though.

I can't get any of the commands you have listed to do anything useful. For example, "scan" just throws "unknown command" at me.

All I really see coming out at this time is "IFNAME=wlan0 <3>CTRL-EVENT-SCAN-RESULTS"

EDIT My bad, I had the wrong paramters for wpa_cli, re-checking now

EDIT#2 "Starting AP scan for specific SSID:" happens just before the full-list broadcast, but before a broadcast without the full list of SSID names as well. I don't really see any difference between the scans based on logcat.

EDIT#3 A full SSID-listing scan appears to happen at 120 second intervals

I'm trying the same thing, how did you go arround the UNKNOWN COMMAND?


line 748 of scan.c (wpa_supplicant)
somehow max_ssid is set to 1. Why is the question? (ap_scan == 2 might be the answer, but it is not set in wpa_Supplicant.conf AFAI can tell)
The comment seem to indicate that this is done out of convinience (wpa_supplicant can be rebuilt to avoit this behaviour)
3rd February 2014, 08:02 PM |#21  
Chainfire's Avatar
Moderator Emeritus / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 88,034
 
Donate to Me
More
Quote:
Originally Posted by kenshin33

I'm trying the same thing, how did you go arround the UNKNOWN COMMAND?

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 )

Quote:

line 748 of scan.c (wpa_supplicant)
somehow max_ssid is set to 1. Why is the question? (ap_scan == 2 might be the answer, but it is not set in wpa_Supplicant.conf AFAI can tell)
The comment seem to indicate that this is done out of convinience (wpa_supplicant can be rebuilt to avoit this behaviour)

I have no idea what you're talking about ...
Post Reply Subscribe to Thread

Tags
pri-fi, privacy, wifi

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes