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:
# 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?
cernekee said:
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.
Click to expand...
Click to collapse
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)
kenshin33 said:
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??
Click to expand...
Click to collapse
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.
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).
Click to expand...
Click to collapse
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.
The same problem would apply to anyone with a laptop and frequents regularly some coffe shop or library ...
Click to expand...
Click to collapse
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:
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.
cernekee said:
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:
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.
Click to expand...
Click to collapse
wl_android.c doesn't seem to do anything with it
there are some refs in wl_cfg80211.c
kenshin33 said:
wl_android.c doesn't seem to do anything with it
there are some refs in wl_cfg80211.c
Click to expand...
Click to collapse
Well, this part of wl_android_priv_cmd() looks discouraging:
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:
$ 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:
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.
cernekee said:
Well, this part of wl_android_priv_cmd() looks discouraging:
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:
$ 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:
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.
Click to expand...
Click to collapse
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
kenshin33 said:
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).
Click to expand...
Click to collapse
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:
#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 */
[b]memcpy(dhd->mac.octet, buf, ETHER_ADDR_LEN);[/b]
#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:
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
Click to expand...
Click to collapse
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.
cernekee said:
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:
#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 */
[b]memcpy(dhd->mac.octet, buf, ETHER_ADDR_LEN);[/b]
#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.
Click to expand...
Click to collapse
custom_get_mac_address doesnt'seem to do much
from grouper's :
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:
#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:
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
kenshin33 said:
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
Click to expand...
Click to collapse
On tuna this should set the random (or not-so-random) MAC from rand_mac, then return 0:
https://github.com/CyanogenMod/andr...7e/arch/arm/mach-omap2/board-tuna-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/ke...mr2/arch/arm/mach-tegra/board-grouper-sdhci.c
cernekee said:
On tuna this should set the random (or not-so-random) MAC from rand_mac, then return 0:
https://github.com/CyanogenMod/andr...7e/arch/arm/mach-omap2/board-tuna-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/ke...mr2/arch/arm/mach-tegra/board-grouper-sdhci.c
Click to expand...
Click to collapse
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/)
cernekee said:
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.
Click to expand...
Click to collapse
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)
cernekee said:
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).
Click to expand...
Click to collapse
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.
cernekee said:
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.
Click to expand...
Click to collapse
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.
cernekee said:
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.
Click to expand...
Click to collapse
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.
cernekee said:
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.
Click to expand...
Click to collapse
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.
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.
Chainfire said:
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.
Click to expand...
Click to collapse
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
Chainfire said:
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.
Click to expand...
Click to collapse
http://www.howtogeek.com/howto/2865...hiding-your-wireless-ssid-really-more-secure/
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...
Click to expand...
Click to collapse
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.
kenshin33 said:
you can may be copy it ?
Click to expand...
Click to collapse
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...
Chainfire said:
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.
Click to expand...
Click to collapse
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) [b]&&[/b]
[b]ssid->scan_ssid[/b]) {
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
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.
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
I ran into the "forget network" caveat earlier. It would be nice to make this more seamless.
Also, if one were to incorporate this into a custom firmware, I would use a very different methods than I did in Pry-Fi.
Click to expand...
Click to collapse
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.
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
Click to expand...
Click to collapse
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 don't need everybody looking over my shoulder or explaining/debating every line of code thrice
Click to expand...
Click to collapse
In security/privacy/crypto circles, that is usually a feature not a bug.
cernekee said:
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...
Click to expand...
Click to collapse
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).
cernekee said:
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"?
Click to expand...
Click to collapse
I'll see if I can correlate the timings of the logcat messages with the scans
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
Click to expand...
Click to collapse
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%.
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.
Click to expand...
Click to collapse
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.
I ran into the "forget network" caveat earlier. It would be nice to make this more seamless.
Click to expand...
Click to collapse
Hence the manage networks option inside the app (which still also doesn't work half the time) ... This definitely needs some work.
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.
Click to expand...
Click to collapse
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.
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:
Click to expand...
Click to collapse
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.
In security/privacy/crypto circles, that is usually a feature not a bug.
Click to expand...
Click to collapse
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.
Chainfire said:
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.
Click to expand...
Click to collapse
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 :angel:.........passive aggressive, got it licked
Disclaimer:
i dont hate you
Chainfire said:
I'll see if I can correlate the timings of the logcat messages with the scans
Click to expand...
Click to collapse
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
Chainfire said:
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
Click to expand...
Click to collapse
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)
Related
Hi,
I currently try to follow these instructions...
http://mobisocial.stanford.edu/news...together-by-hacking-connectivityservice-java/
Very hard for me. Don't know what to do.
The goal of COIN project is to use WiFi and 3G connections simultaneously. So it conflicts with the policy of Connectivity Service, but there is no configuration to edit the policy, and it is hard coded. You can find the clue in ConnectivityService.java:handleConnect function.
Our current solution is quite brutal, which is to mask the eyes of Connectivity Service by modifying its message handler entry like the following:
// must be stateless – things change under us.
private class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
NetworkInfo info;
//added by COIN to disable Connectivity Service
int networkState = 8; //not any following state
/*use static google dns server for wifi and 3g*/
if (msg.what == NetworkStateTracker.EVENT_STATE_CHANGED) {
SystemProperties.set(“net.dns1″, “8.8.8.8″);
SystemProperties.set(“net.dns2″, “8.8.4.4″);
bumpDns();
}
//////////////////////////////////////////////
//switch (msg.what) {
switch (networkState) {
case NetworkStateTracker.EVENT_STATE_CHANGED:
info = (NetworkInfo) msg.obj;
int type = info.getType();
…..
And then compile the modified ConnectivityService.java in the android source code tree, you can get an new services.jar file in framework directory. Replace the existing services.jar on the cell phone with the following adb commands, then reboot the phone
adb shell “mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system”
adb shell “chmod 0777 /system/framework”
adb push services.jar /system/framework
adb shell “chmod 0644 /system/framework/services.jar”
adb shell “chmod 0755 /system/framework”
Click to expand...
Click to collapse
Does he mean I have to compile the whole Android source code again?
So I would need to learn first, how to compile Android, then change this file, compile Android, copy file?
Instant of adb shell, could I also use root explorer?
How device dependant is this? Or how android version dependant?
Could someone offer the compiled file?
No answer yet.
I believe so. This is actually what compelled me to go learn to compile android by myself-- the constant switching between 3g and wifi in a semi-strong wifi zone sucks. For now I am starting with CM7 since it is so popular.
Yes you would need to compile the whole OS and it will only work on an AOSP rom. It will also be very version dependent.
Please let me know if it worked ! I probably don't think it will. Read this on the page:
Pallas Says:
April 13, 2012 at 5:58 am
are you sure the packets are going thru both interfaces?
I think it doesn’t work, simply because you would need two default gateways, leading to some hard problems:
- how does the system choose where to send the packets?
- for outgoing packets: unless the two connections have both statically assigned public IP addresses, which is very unlikely, you will end up with two differently NATed paths, and the client will refuse packets coming from two different ip addresses on the same connection.
- for incoming packets: to let the client send packets to both interfaces, you would need to send them from both interfaces with different source ip addresses: it will not work, the client will get confused. and anyway you would need support at the application level.
to solve all this, you’d need to:
- make an ad-hoc application which understands all this and can send chuncks to both interfaces, then merge all the returning chunks. you’d need support at the application level: for example you’d need http byte range support on both client and server
- divide “equally” the single specific connections thru the two gateways. this may work but it’s pretty hard if you do not have access to advanced routing and traffic shaping at the kernel level. may be possible on a phone with custom compiled aosp rom and modified kernel
gouthamsn said:
Please let me know if it worked ! I probably don't think it will. Read this on the page:
Pallas Says:
April 13, 2012 at 5:58 am
are you sure the packets are going thru both interfaces?
I think it doesn’t work, simply because you would need two default gateways, leading to some hard problems:
- how does the system choose where to send the packets?
- for outgoing packets: unless the two connections have both statically assigned public IP addresses, which is very unlikely, you will end up with two differently NATed paths, and the client will refuse packets coming from two different ip addresses on the same connection.
- for incoming packets: to let the client send packets to both interfaces, you would need to send them from both interfaces with different source ip addresses: it will not work, the client will get confused. and anyway you would need support at the application level.
to solve all this, you’d need to:
- make an ad-hoc application which understands all this and can send chuncks to both interfaces, then merge all the returning chunks. you’d need support at the application level: for example you’d need http byte range support on both client and server
- divide “equally” the single specific connections thru the two gateways. this may work but it’s pretty hard if you do not have access to advanced routing and traffic shaping at the kernel level. may be possible on a phone with custom compiled aosp rom and modified kernel
Click to expand...
Click to collapse
(Probably for your Interest
This project works on a MultiPath-TCP Implementation (follow link to mptcp.info.ucl.ac.be). The hard times you get is compiling the Kernel with the additional files. This Protocol can only work effectively for download Purposes if the Server also has a MPTCP Kernel running. But on the other Hand you can shut down a single connection without loosing the active Connection (Downloads are not interrupted and improved Bandwidth Capacity if your Server is MPTCP-Ready)
Until now this Protocol is only working for Homeservers or similar Projects, where you have full access to the Server and the working Kernel of the system.
I am currently working on implementation of the Protocol for my Bachelor Thesis. I already compiled a working Kernel (Glados Nexus S) and now i'm working on keeping both Interfaces active. I hope this Tut can help me...
Has anybody tried other approaches to this topic? I tried manually loading the wifi-module and configuring it, but i only managed to ping via one Interface.
You managed to make it work?
bagers said:
No answer yet.
Click to expand...
Click to collapse
You managed to make it work? i want to make it also for my master thesis
UPDATE: 2015-01-14IMPORTANT!
Although this thread is still open, it is no longer updated with relevant info.
Please go to our official GitHub Site for the latest developer news and join
our development efforts in our back rooms...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
For all the latest changes see our CHANGELOG.
For all the latest WIP alpha releases, see RELEASES.
The minimum supported AOS API version is 16, thus
AIMSICD will only work on Jelly Bean 4.1 or later.---
Call for help to develop an IMSI catcher detector application for Android OS.
Q: What is an IMSI catcher?
A: It is a fake cell tower (aka. Base Transceiver Station, BTS) used to track and monitor specific (groups of) people in the near vicinity of that BTS.
In the light of last years highly publicized events in the many Arabic nations and the German state sponsored rootkit discovery, etc etc. It is of the highest priority to start developing anti/counter-spy applications for the people living in rogue states such as Syria, Iran etc. In addition, it may play an important role in finding (and preventing) other rogue applications that attempt to send silent SMS's to high-cost premium services.
Recently there have been some publicity surrounding the Osmocom BB's, application patch known as "Catcher Catcher" which is used to detect mobile phone tracking and spying, originating from the Mobile Phone Service Provider side. (I.e. something that generally can only be provided by state sponsored government and security forces.)
Relevant links include:
http://bb.osmocom.org/trac/
http://www.youtube.com/watch?v=YWdHSJsEOck
http://events.ccc.de/congress/2011/Fahrplan/events/4736.en.html
http://gsmmap.org/cgi-bin/gsmmap.fcgi?risk=1
http://lab.ks.uni-freiburg.de/projects/imsi-catcher-detection/wiki/Software
http://opensource.srlabs.de/projects/catcher/wiki
For a tutorial on how to compile and help populate the Gsmmap database, see here.
In the News:
http://www.h-online.com/security/ne...iles-and-security-measures-shown-1401668.html
http://www.actualtoday.com/gsm-hacking-osmocom-patch-discovered-silent-sms-and-eavesdropping
This information started 2010 and was extended to last years 28C3 event...
How can you help?
I would very much like to have contact with anyone who can provide more in-depth knowledge how this could possibly be implemented on the AOS. There are several way you can help, eventhough you may not be an expert on HW or even android.
Help populate the Gsmmap database.
Follow and help/develop the OsmocomBB project.
Compile OsmocomBB for an Android phone, so that it can be used as a USB host. (Preferably for one of the more popular models like the Samsung galaxy S.)
Help mapping out the Android baseband AT command set or the internal RIL function, so that we can obtain as many GSM radio parameters as possible.
Reverse engineer the vendor RIL of the phone above.
Reverse engineer the Modem firmware so that we can use the phone as a native catcher-catcher.
Find provide documentation of the closed source modem(s) most used in androids.
Share other relevant experience you may have in this matter.
Find or provide links to documentation of anything baseband related, not already widely known!
Stay legal, or this project will close really quickly!
NOTE: This is not to prevent IMSI catchers, but to inform the "victims" that they are being subject to tracking/monitoring.
A few other items:
For the Software Change Log, our Github.
For Phone Support Log, see Post #7 below.
We have contacted EFF and The Guardian Project and hope to join their efforts and provide support to counter illegal tracking and tapping.
Thanks to SecUpwN, we now have our own GitHub HERE.
Have made a preliminary Developer Roadmap.
Added some important links.
Licensing Proposal: This will be a community project licensed under a GPLv3 license:
---Glossary: (Harald Welte)
The BSS (Base Station Subsystem)
MS (Mobile Station): Your phone
BTS (Base Transceiver Station): The cell tower
BSC (Base Station Controller): Controlling up to hundreds of BTS
BP/CP (Baseband/Cellular Processor): Your phone radio/modem processor (usually an ARM 7/9)
The NSS (Network Sub System)
MSC (Mobile Switching Center): The central switch
HLR (Home Location Register): Database of subscribers
AUC (Authentication Center): Database of authentication keys
VLR (Visitor Location Register): For roaming users
EIR (Equipment Identity Register): To block stolen phones
Our Support:
We have as a goal to become a strong supporter of the EFF and The Guardian Project.
Part of all future donations will go to EFF. Intellectual and technological support will
also be given where possible.
The GSM Ciphering Indicator
According to the 3GPP GSM standards/specifications [1] for handsets,
there should be a Ciphering Indicator (CI) showing the user when the
GSM phone/data connection is not using encryption. Unfortunately for
many people in the rest of the world, this feature have not been
properly (if at all) implemented in the Android OS, AFAIK [2]. The
second culprit is the fact that your cellular service provider have
disabled showing this CI on the vast majority of SIM cards issued
around the world.
The only options for circumventing these privacy problems are:
Write an application that present the current ciphering status. (Easy)
Write an application that hijacks the baseband processor (modem)
SIM binary-code (in the firmware) to force-enable CI and possibly
also the use of A5/3. (Hard)
Make and use a copy of your SIM card that has CI enabled. (Hard)
Lobby your cellular service provider to always use A5/3 ciphering. (Hard)
(A5/1 was never used and A5/2 can be cracked on-the-fly!)
Force Google to fix the issue! This is hard, since the issue is
already >2 years old at "medium priority", and in addition it
does not resolve the service provider disabled CI in their SIM
cards.
As you can see the issue at hand does not look to be resolved
anytime soon. So I lobby for (1) or (2). But to do that we need
some background knowledge. Then I will show you how to read the
CI setting from your SIM card. Then we will figure out how to
write such an application!
References:
[1] 3GPP GSM 02.07: http://www.3gpp.org/ftp/Specs/archive/02_series/02.07/0207-710.zip
[2] Android Issue 5353: https://code.google.com/p/android/issues/detail?id=5353
[3] Dieter Spaar's Blog: http://www.mirider.com/weblog/2010/08/03/#20100803-ciphering_indicator
[4] 3GPP GSM 11.11: ???
Some 3GPP GSM Terminology:
Code:
EF - Elementary Files
AD - Administrative (Data) Field
BCD - Binary-Coded Decimal (compressed)
CHV - Card Holder Verification (usually your SIM code)
TLV - Tag, Length, Value
BER-TLV - Object that conform to the Basic Encoding Rules (BER)
RFU - Reserved for Future Use
Background:
[1] § B.1.26 Ciphering Indicator
The ciphering indicator feature allows the ME to detect that
ciphering is not switched on and to indicate this to the user,
as defined in GSM 02.09.
The ciphering indicator feature may be disabled by the home network
operator setting data in the "administrative data" field (EF-AD) in
the SIM, as defined in GSM 11.11.
If this feature is not disabled by the SIM, then whenever a
connection is in place, which is, or becomes unenciphered,
an indication shall be given to the user.
Ciphering itself is unaffected by this feature, and the user can
choose how to proceed.
[3] Ciphering Indicator in mobile phones
According to GSM 02.07 B.1.26, there should be a Ciphering Indicator
in the ME to allow a user to detect if ciphering is not switched on.
The Ciphering Indicator can be turned off by the network operator
clearing (what is formerly known as) the OFM (Operational Feature
Monitor) bit in the "administrative data" field of the SIM.
(See GSM 11.11, 10.3.18)
Usually the Ciphering Indicator is turned off, at least in those SIMs
I have seen so far. And you usually cannot modify the administrative
data in the SIM. But would a phone actually display something if the
Ciphering Indicator is enabled and ciphering is not on?
[4] § 10.2.18 The SIM Administrative Data field
All data on your SIM card is stored in a special filesystem hierarchy.
To not delve too far into the murky depths of SIM data storage, we
jump straight to the particular file we are interested in. It is an
elementary file (EF) called Administrative Data (AD), whose
filename/identifier is just a number, like always in the SIM-card
filesystem. In this case it is known '6FAD' (Hex for 28589).
"
This EF contains information concerning the mode of operation according
to the type of SIM, such as normal (to be used by PLMN subscribers for
GSM operations), type approval (to allow specific use of the ME during
type approval procedures of e.g. the radio equipment), cell testing
(to allow testing of a cellbefore commercial use of this cell),
manufacturer specific (to allow the ME manufacturer to perform specific
proprietary auto-test in its ME during e.g. maintenance phases).
"
Technical Summary:
Code:
-----------------------------------------------------------
Name: EFAD (Administrative Data)
Identifier: '6FAD' (28589)
File size: 3+X bytes
-----------------------------------------------------------
Byte Description
-----------------------------------------------------------
1 UE operation mode
2-3 Additional information (incl. cipher indication)
4 Length of MNC of IMSI
5-X RFU
-----------------------------------------------------------
UE Operation Mode: (byte 1)
-----------------------------------------------------------
This is the mode of operation for the MS.
Coding: (Initial value)
'00' - normal operation
'80' - type approval operations
'01' - normal operation + specific facilities
'81' - type approval operations + specific facilities
'02' - maintenance (off line)
'04' - cell test operation
NOTE: All other values are RFU (reserved for future) use
-----------------------------------------------------------
Additional Information: (byte 2-3)
-----------------------------------------------------------
Coding:
- Specific facilities code (if b1=1 in byte 1);
- ME manufacturer specific information (if b2=1 in byte 1).
Ciphering indication is enabled by enabling both the specific
facilities bit (b1) in byte-1 AND the cipher indicator bit (b1)
in byte-3. Thus the administrative data field has to be:
Byte-1: 0x01 0000 0001
Byte-2: 0x00 0000 0000
Byte-3: 0x01 0000 0001
Byte-4: 0x02/3 0000 001x
-----------------------------------------------------------
Length of MNC in the IMSI: (byte 4)
-----------------------------------------------------------
The length indicator refers to the number of digits,
used for extracting the MNC from the IMSI.
This value codes the number of digits of the MNC in
the IMSI. Only the values (b1-b2) '0010' and '0011' are
currently specified, all other values are reserved
for future use.
-----------------------------------------------------------
Relevant Documents:
TS 22.101
TS 31.102
TS 33.102
-----------------------------------------------------------
How to read the Ciphering Indicator in your SIM
Since there is no API call (AFAIK) for directly reading the SIM data
fields, we are going to use your modems standard AT commands. You can
normally do this in two ways. (1) By connecting your phone via USB to
your PC and use a terminal application to send AT commands (ATCs)
directly to the Baseband Processor (BP), aka "modem". (b) To connect
directly to the modem "device" via some terminal program within the
Android Operating System (AOS). For all the details surrounding this,
please see this thread.
Once you've got an AT command terminal session working, you are free
to issue the relevant AT commands to read from your SIM card. The
particular command we are interested in, is the +CRSM command. This
command can read/write various data directly from SIM card files.
==================================================
If you know of any equivalent or valid AOS API call for reading
this type of SIM data, please let us know!
==================================================
The +CRSM syntax is as follows:
Code:
AT+CRSM=<command>[,<fileid> [,<P1>,<P2>,<P3> [,<data> [,<pathid>]]]]
<command> This is the operation to be performed:
176 READ BINARY
178 READ RECORD
192 GET RESPONSE
214 UPDATE BINARY
220 UPDATE RECORD
242 STATUS
<fileid> This is an integer which is the identifier of a elementary
datafile (EF) on SIM. Mandatory for every command except
STATUS and may be e.g.:
Hex Dec File
---------------------
6F37 28471 ACMmax
6F07 28423 IMSI
6F39 28473 ACM
6F41 28481 PUKT
6F42 28482 SMS
Structure:
[CLA INS P1 P2 P3 Data]
The bytes have the following meaning:
CLA Is the class of instruction (ISO/IEC 7816-3 [25]), 'A0' is used in the GSM application;
INS Is the instruction code (ISO/IEC 7816-3 [25]) as defined in this subclause for each command;
P1, P2, P3 Are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for
P1, P2 and P3. P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer
from the SIM in an outgoing data transfer command (response direction). In an ingoing data transfer
command (command direction), P3='00' introduces no transfer of data.
SW1 and SW2 Are the Status Words indicating the successful or unsuccessful outcome of the command.
-------------------------------------------------------------------------------
Dec. <sw1> <sw2> Description
-------------------------------------------------------------------------------
144 0x90 0x00 normal entry of the command, indicating OK
103 0x67 0xXX incorrect parameter P3
0x6B 0xXX incorrect parameter P1 or P2
0x6D 0xXX unknown instruction code given in the command
0x6E 0xXX wrong instruction class given in the command
0x6F 0xXX technical problem with no diagnostic given
0x9F 0xXX length XX of the response data
0x92 0x0X update successful but after using an internal retry routine X times
0x92 0x40 memory problem
0x94 0x00 no EF selected
0x94 0x02 out of range (invalid address)
0x94 0x04 file ID not found; pattern not found
0x94 0x08 file is inconsistent with the command
0x98 0x02 no CHV initialized
0x98 0x04 Access condition not fullfiled / unsucc. CHV verify / authent.failed
0x98 0x08 in contradiction with CHV status
0x98 0x10 in contradiction with invalidation status
0x98 0x40 Unsuccessful CHV-verification. Or UNBLOCK CHF / CHV blocked /UNBL.blocked
0x98 0x50 Increase cannot be performed. Max. value reached
-------------------------------------------------------------------------------
For example, you could also read your IMSI code from your SIM card,
but this is a little more tricky as that operation involves a parity
bit-field in the second byte, while using a compressed BCD coding.
Reading the AD field (containing cipher indication)
Also see +CSIM and +CSCS
Code:
[B]AT+CRSM=176,28589,0,0,3[/B]
+CRSM: 144,0,"000000"
==> Bytes: 1-3 = 00,00,00
byte1: "MS operation mode"
byte2: "Specific facilities" B1
byte3: "Specific facilities" B2 (+ cipher indication)
==> [COLOR=Red]Ciphering indication is disabled[/COLOR]
Note: a response like this "+CRSM: 103,3" indicates that there is
a problem with P3 and that the value for P3 should be 3.
How to write AD and enable the Cipher Indicator in your SIM
Now, this is the most tricky part while being poorly documented.
The problem is that since this is an "administrative operation", it
may require something called a "facility lock password". However it
is not clear to me what this is. Is it just a CHV PIN/PUK or is it
something only known to the OEM or cellular service provider?
Anyone who could provide proper guidance here, will be offered
a beer! (Also see: +CLCK, +CPWD, +CSIM for reference.)
Going through the reading hoops above, we guess that the
proper write command should be like this:
Code:
AT+CRSM=214,28589,0,0,3,"010001"
However, we know from reading other SIM files (IMSI) that sometimes
the data is returned in compressed BCD format. That is, it could be
that the 1st and last pairs of 01's should be swapped to 10's.
So that we have:
Code:
AT+CRSM=214,28589,0,0,3,"100010"
Any ideas?
Also interested
+1 (never know what can happen in a state governed by Sarkozy... :S )
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
XdxH62 said:
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
Click to expand...
Click to collapse
been reading up on this.. quite fascinating.
Phone Support Log
This is a list of phones that have been claimed (but not verified) to work with AIMSICD. If you absolutely want to post success stories, do include exact phone model, API level (AOS version), and whether your using a special ROM, and the result from "uname -a" command.
DO NOT POST IF THE AIMSICD DOESN'T WORK FOR YOU!
This App is not even Beta version yet, so we don't expect it to work for anyone than
ourselves at the moment. As soon as this changes, you will find out here!
Current AIMSICD Version: 0.1.6-alpha
Code:
GT-I9100T Android 4.1.2 Official stocked, rooted
Samsung Galaxy Nexus, CM 11.0 M5
HTC ONE M7 (PN0710000) AOKP M7 Generic (KitKat 4.4.2)
Click to expand...
Click to collapse
---
Old original post/message:
XdxH62 said:
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
Click to expand...
Click to collapse
Unfortunately not. If you had followed the links above, you would have seen gsmmap... It does help trying to map the likelyhood that someone outside an intelligence organization is using one, but you can technically fake any such valid BTS as well. You need other methods... See refs/docs.
Click to expand...
Click to collapse
ghost stations
XdxH62 said:
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
Click to expand...
Click to collapse
sure, that would make perfect sense. this way you would immediately spot "ghost base stations" that miraculously appear for one day only ...
*#0011# | Network Info
*#32489# | Cipher Info <--- does anybody get anything out of this (OFM-bit)
*#197328640# | General Service Mode GT-S5360 Galaxy Y : -1-7-3-1-1- in LA4 modem Fw.
*#745# | RIL Dump Menu
mai77 said:
sure, that would make perfect sense. this way you would immediately spot "ghost base stations" that miraculously appear for one day only ...
Click to expand...
Click to collapse
That's partially correct, but you need to ensure (at least) two things.
1. That the "detector" you're using is not moving around!
2. That the database you're comparing with have not already been corrupted.
Therefore, you can (and should use a database), but you need a much more advanced algorithm for determining when and how this BTS appeared combined with other criteria.
in 97%+ of real cases, an IMSI catcher would be in operation for a short while only. this change should be detectable by comparing cell IDs and such of some area in a town, which hardly changes over time.
On an i9000 the code to access the engineering menu (*#197328640# in Dialer) worked – I’m assuming it’s standard across all recent Samsungs, not just the Galaxy S series.
Menu 1,8,3,1 displays the current ciphering status, i.e. whether or not your current call is currently encrypted.
from youtube :
mai77 said:
...
On an i9000 but the code to access the engineering menu (*#197328640# in Dialer) worked just the same – I’m assuming it’s standard across all recent Samsungs, not just the Galaxy S series.
Menu 1,8,3,1 displays the current ciphering status, i.e. whether or not your current call is currently encrypted.
Click to expand...
Click to collapse
Right, and that's why I have been trying to reverse engineer the Service Mode application, to find out where all that info is coming from, including other parts needed from that app. But I'm new to all this Android stuff, so... Instead this led me to the RIL, but since the interesting parts of the RIL is closed source I tried to figure out what is happening in the modem. This finally led me to post this new thread:
"How to talk to the Modem with AT commands":
http://forum.xda-developers.com/showthread.php?t=1471241
Any tips/ideas how to get this info would be great!
I suspect there will be several different way to get to this, but all may prove relevant...
atdebug.apk
at-command debug tool on android
http://forum.xda-developers.com/showpost.php?p=19485757&postcount=1
you have to know the device name though
mai77 said:
at-command debug tool on android
http://forum.xda-developers.com/showpost.php?p=19485757&postcount=1
you have to know the device name though
Click to expand...
Click to collapse
Yeah, I saw that, but it doesn't work, because the developer is making false assumptions on both which serial device is used, and it's permissions...
http://developer.android.com/reference/android/telephony/gsm/GsmCellLocation.html
to monitor cell data
import com.android.internal.telephony.Phone
import com.android.internal.telephony.PhoneFactory
...
PhoneFactory.makeDefaultPhones(this)
Phone phone = PhoneFactory.getDefaultPhone()
then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. still possible, though
mai77 said:
http://developer.android.com/reference/android/telephony/gsm/GsmCellLocation.html
to monitor cell data
import com.android.internal.telephony.Phone
import com.android.internal.telephony.PhoneFactory
...
PhoneFactory.makeDefaultPhones(this)
Phone phone = PhoneFactory.getDefaultPhone()
then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. still possible, though
Click to expand...
Click to collapse
News ?
Sent from my Galaxy Nexus using xda premium
I just updated original post #2 with the procedure for finding out if the ciphering indicator is enabled/disabled on your SIM card. However, this procedure need to be implemented in code/application for practical use. Alternatively, there may be some IPC calls that could be used to get these data...if we knew where to look.
mai77 said:
then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. still possible, though
Click to expand...
Click to collapse
You could probably use "reflection" to get and use those methods... try googling/stackexchange for that.. We appreciate you attempt!
AT+CRSM=176,28589,0,0,3
results in error code on a Galaxy.
quite some number of xda members have found their entry "Ciphering" ON/OFF in the engineering menu of their phones, e.g. Galaxies. But I didnt come across a reliable report of success. Galaxy Y contains that entry too, but the bit appears unchangeable and might be a placebo menu entry alongside some other placebo toggles.
I am very much impressed with the informative and interesting discussion. Thanks for sharing such great content with us.
mai77 said:
AT+CRSM=176,28589,0,0,3
results in error code on a Galaxy...
Click to expand...
Click to collapse
Hi, Sorry for late reply. You have a GT-S5360 (FCC ID: a3lgts5360), but these come in several different versions. What baseband processor is this using? If it's a X-GOLD-based one (XMM 6x60), the command above should work. If on the other you have some other modem, like Qualcomm etc, there is no telling what would happen, even though the +CRSM is a GPP 27.00x "standard". What error do you get, and how do you connect to your phone? (I.e. Make sure you're actually talking to your phone modem and not to some other internal modem device in your PC.)
Also, like I already mentioned in #2:
1) the bit is not changeable on most SIM cards.
2) the actual ServiceMode menu functionality is contained in the Baseband firmware on X-GOLD, for Qualcomm, I don't know, even if it available.
I gotta say I'm a bit surprised by the lack of ambition to get a working 4G toggle. Every phone I've had, there has always been a demand to get a working 4G toggle. Has anyone heard of anything about this? Luckily this phone gets good battery life so its not that big of a deal but it'd be nice to have for those times when your trying to really save battery.
I know of the app Phone Info, but its gotten a lot of negative views around here about losing data with it so I've avoided it since.
rehpyc has been working on one. I've sent him some info that I discovered trying to find the right system call to switch between 3g and 4g.
Rather than simply be disappointed, would you like to help?
Sent from my SCH-I535 using xda premium
I'm trying to find where the settings (which can be accessed in the phone info -> Device Information area) are stored.
-Using dex2jar and jdgui, I decompiled the phone info app into java source (.java) files. It's a really small app that just calls the "TestingSettings" functionality of the SecSettings.apk
-We can access the "TestingSettings" by simply running "am start com.android.settings/.TestingSettings" in terminal. It essentially does the exact same thing as launching the Phone Info app.
-Using dex2jar and jdgui, I decompiled the SecSettings.apk into java source (.java) files. Digging through the files, I found that the RadioInfo class. This class contains a String array mPreferredNetworkLabels which lists all the settings in the spinner we choose the network type (CDMA Auto (PRL), LTE/CDMA/EvDo, etc). This class seems to provide functionality for listening to GUI changes on the "PreferredNetworkType" spinner. Not exactly sure what it does from there, but hopefully it can be traced down to some methods that either store the settings into a file or to a SQLite database.
In dex2jar -> JD gui for SecSettings.apk, Radioinfo class has
public RadioInfo()
{
String[] arrayOfString = new String[14];
arrayOfString[0] = "WCDMA preferred";
arrayOfString[1] = "GSM only";
arrayOfString[2] = "WCDMA only";
arrayOfString[3] = "GSM auto (PRL)";
arrayOfString[4] = "CDMA auto (PRL)";
arrayOfString[5] = "CDMA only";
arrayOfString[6] = "EvDo only";
arrayOfString[7] = "GSM/CDMA auto (PRL)";
arrayOfString[8] = "LTE/CDMA/EvDo";
arrayOfString[9] = "LTE/GSM/WCDMA";
arrayOfString[10] = "Global";
arrayOfString[11] = "LTE only";
arrayOfString[12] = "LTE/WCDMA";
arrayOfString[13] = "Unknown";
this.mPreferredNetworkLabels = arrayOfString;
}
RadioInfo.java sets the network type in the following code (lines 297-309):
AdapterView.OnItemSelectedListener mPreferredNetworkHandler = new AdapterView.OnItemSelectedListener()
{
public void onItemSelected(AdapterView paramAnonymousAdapterView, View paramAnonymousView, int paramAnonymousInt, long paramAnonymousLong)
{
Message localMessage = RadioInfo.this.mHandler.obtainMessage(1001);
if ((paramAnonymousInt >= 0) && (paramAnonymousInt <= -2 + RadioInfo.this.mPreferredNetworkLabels.length))
RadioInfo.this.phone.setPreferredNetworkType(paramAnonymousInt, localMessage);
}
public void onNothingSelected(AdapterView paramAnonymousAdapterView)
{
}
};
The key line is line 303:
RadioInfo.this.phone.setPreferredNetworkType(paramAnonymousInt, localMessage);
Some info about the setPreferredNetworkType() method:
void setPreferredNetworkType(int networkType, Message response);
Requests to set the preferred network type for searching and registering (CS/PS domain, RAT, and operation mode)
Parameters:
networkType one of NT_*_TYPE
response is callback message
The phone data member is a private data member set to null on line 422:
private Phone phone = null;
The phone data member is set to the Default Phone on RadioInfo object creation (onCreate) in line 916:
this.phone = PhoneFactory.getDefaultPhone();
Based on the above information, I believe we would need to create a toggle which would execute a small java program to access the setPreferredNetworkType() method from a Phone object instantiated from the PhoneFactory.getDefaultPhone() method. I believe Phone resides in com.android.internal.telephony, but in order to gain access to the internal android stuff we would need to do something like the following article provides:
https://devmaze.wordpress.com/2011/01/18/using-com-android-internal-part-1-introduction/
That's all the time I have for the moment...
great info! Unfortunately I have no idea how that stuff works. I praise the devs who do this work and members like you who work on it. I wish I could.
Sorry if I came off as demanding of wanting a toggle, I'm just surprised I haven't heard more about it. But good to know it's being worked on. I'd definitely be willing to help test when something is cooked up though
tu3218 said:
great info! Unfortunately I have no idea how that stuff works. I praise the devs who do this work and members like you who work on it. I wish I could.
Sorry if I came off as demanding of wanting a toggle, I'm just surprised I haven't heard more about it. But good to know it's being worked on. I'd definitely be willing to help test when something is cooked up though
Click to expand...
Click to collapse
Unfortunately I'm short on time these days, but I wanted to get the info out there so someone might be able to use it. I really do think we're close, but I'm more of a hacker/modder than an Android dev. Someone comfortable with development on Android might be able to speed this up significantly.
Sent from my SCH-I535 using xda premium
I use my7rom on my Omnia 7.
Is there anyway to link a contacts adress to Nokia Drive instead of Maps (stock wp7 app). It would be much more practical if Nokia Drive opened a navigation session instead.
Anyone up for the challenge? A reg-tweak perhaps?
// Manneman
Skickat från Windows Phone 7.8
There's two parts here. The first is identifying the correct "filetype" or URI scheme that is used for navigation. That shouldn't be too hard; a little digging in HKCU should reveal it. We already know about ones like callto: and http: and I'm actually (slowly) working on an app to allow people to easily change them. The second part is finding the correct command to load that address or route in the Nokia Maps app. If the app supports pinning routes or destinations to Start, this is probably possible. If not, it may not be possible in the app. Most apps aren't designed to accept command-line parameters, so even if you make them the default handler for a given filetype or URI scheme, they ignore the value you send them and just start as though launched from Start.
GoodDayToDie said:
If the app supports pinning routes or destinations to Start, this is probably possible.
Click to expand...
Click to collapse
Nokia Drive supports pinning to start so it should be possible. Unfortunately I can't tell you exact command line parameters 'cause my Lumia 900 still "in jail"
Let me see if I have a copy of the Nokia Drive XAP handy. I'll need to decompile it to figure out the correct parameters for launching it with the intent of navigating to a specific location. Note also that this might not be possible directly - for example, the app might store a list of locations internally, and the tiles only provide an index into that list rather than providing the location directly - but that just requires another layer of indirection.
In that case, you create an app that gets registered as the navigation handler, and in response to a navigation request, it writes the requested location into the Nokia Drive app and then chain-launches Nokia Drive with the index of the newly written location. That's just an example of one way that this might go wrong, but overall, the odds are actually pretty good. Obviously, all of this will require, at a minimum, write access to the HKCR hive in the registry.
Ah, guys! You are so kind helping me out. I´m really certain alot of members in the WP7 section would love for this to work!
// Manneman
GoodDayToDie said:
I'll need to decompile it to figure out the correct parameters for launching it with the intent of navigating to a specific location
Click to expand...
Click to collapse
GoodDayToDie, you may try much simpler solution. Just create assembly (dll) to show startup parameters in message box, and replace main Nokia Drive dll (but pin some location first).
That's actually harder than it sounds; even if the app is sideloaded (which would mean I already have the DLL) my fake would have to mimic the internal structure of the real app to a degree (namespaces, class names, default actions, etc.). That's not hard, but decompiling .NET is pretty trivial too.
AFAIR, Nokia Drive is obfuscated (but I'm not 100% sure). Also, you don't need to duplicate all names and structures; just a stuff mentioned in WMAppManifest (I hope so). BTW, I forgot: I still have unlocked handset; if I'll found time, will try today later.
Update: tried but without of luck What I did:
- installed Nokia Drive first;
- downloaded map and pinned current location;
- created fake app with same app guid and namespace name ("Drive"), and performed app update (that operation completely override whole solution but NokiaDrive tile still pinned to the start screen);
- tried a few different page names (_default.xaml, QuickStartPage.xaml, DestinationPickerPage.xaml, FavoritesPage.xaml) with code
Code:
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
MessageBox.Show("Hello from fake dll");
if (e.NavigationMode == System.Windows.Navigation.NavigationMode.New)
{
string[] keys = NavigationContext.QueryString.Keys.ToArray();
string[] values = NavigationContext.QueryString.Values.ToArray();
string param = "";
for (int i = 0; i < keys.Length; i++)
{
param += keys[i] + " -> " + values[i] + "\n";
}
MessageBox.Show("parameters: " + param);
}
}
But result always the same: app doesn't start from the pinned tile
Update 2: Finally, I did it
The trick is:
- do the same as I've described above (you should have pinned tile from ND);
- add following code to the start page:
Code:
public MainPage()
{
InitializeComponent();
var appTile = ShellTile.ActiveTiles.Last();
if (appTile != null)
{
//MessageBox.Show(appTile.NavigationUri.OriginalString);
EmailComposeTask emailTask = new EmailComposeTask();
emailTask.Subject = "NokiaDrive pinned parameters";
emailTask.Body = appTile.NavigationUri.OriginalString;
try
{
emailTask.Show();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message, "Error", MessageBoxButton.OK);
}
}
}
- run app as usual (not from tile);
We allset - all params are sent to our email (I'm too lazy to manually copy all stuff )
Here we are (start parameters; bold values are changed for privacy reason ):
/_default?destination.name=200 SomeName Street&destination.latitude=49.5255378801376&destination.longitude=-72.4296837244183&destination.address.street=SomeName Street&destination.address.houseno=200&destination.address.district=&destination.address.county=&destination.address.city=SomeCity&destination.address.state=&destination.address.country=USA&destination.address.postcode=05720&destination.hashCode=371767793destination.address.statecode=MA&pinnedFrom=Favorites
P.S. Just found: Navigon also has ability to pin address to the start tile So, if you find the way to modify map protocol (or how it calls), it will be a really nice hack! BTW, could you remind me: do we have ability to launch assembly by GUID (on the full-/policy-unlocked phones)? If "yes", it's possible to write a real nice "proxy" app to handle map requests
I don't know about launching assemblies directly, but it's certainly possible to launch apps by GUID. It doesn't even require anything more than dev-unlock in fact (although of course you can only launch apps that you could launch anyhow). So yes, a proxy app is totally possible. That's actually what I'm working on (started as a project to make a Kindle ebook file loader, that would pur .mobi/.prc file in the Kindle app's folder and then launch the app).
GoodDayToDie, could you please, take a look to the registry, for default map protocol handler and figure out how to change that stuff? I'm pretty busy these days (and probably will be extremely busy couple of next months) but we can cooperate and create this app...
I'll investigate, but you're not the only one busy. If you've noticed a lack of software from me recently, it's due to the nex job I got some months back; I love it, but it leaves me with a lot less time for phone hacking if I want to still have a life outside of that.
With that said, this actually ties into the work I'm already doing with things like filetype handling and default browser switching. I can send you my HKCRlib, at a minimum; it's a library that simplifies interacting with HKCR, including creating backups of important values when they change, and reverting the backups.
GoodDayToDie, truly, I'm not much interested (personally) in that hack 'cause I can't use it for my Lumia 900. So it's only for the community needs but because of lack of time, I believe, we may put it on hold.
Highlights
100% open source (GPLv2+)
No ads
One-click connection (batch mode)
Supports RSA SecurID and TOTP software tokens
Keepalive feature to prevent unnecessary disconnections
Compatible with ARMv7, x86, and MIPS devices
No root required
Based on the popular OpenConnect Linux package
Click to expand...
Click to collapse
Requirements
Android 4.0 (ICS) or higher (with working VpnService + tun infrastructure)
An account on a suitable VPN server
Click to expand...
Click to collapse
Downloads
Binaries are attached to this post under the downloads tab.
Google Play: https://play.google.com/store/apps/details?id=app.openconnect
Source code: https://github.com/cernekee/ics-openconnect
F-Droid: https://f-droid.org/repository/browse/?fdid=app.openconnect
Click to expand...
Click to collapse
(note that the F-Droid binaries are signed by a different key than the official releases)
Changelog
Code:
v1.11 - 2015/02/21
- Fix "Unknown compression type 0" errors when CSTP and DTLS use
different compression settings
Older changelogs:
Code:
v1.10 - 2015/02/08
- Fix CSD script problem on Lollipop (bug #1)
- Fix IPv6 address display on status window (bug #2)
- Enable LZ4 compression support
- Identify as a mobile client when Android or iOS is selected
- Update to OpenConnect v7.04+, GnuTLS 3.2.21
v1.02 - 2014/09/02
- Fix regression on certificate handling
v1.01 - 2014/08/29
- Add Spanish translations (thanks to teosoft)
- Fix regression on CSD scripts starting with "#!/bin/sh"
- Improve error messages on broken ROMs that throw exceptions when
starting a VpnService
- Fix intermittent fragment-related crashes on ICS
v1.00 - 2014/08/10
- Fix problems storing >8kB certificates on some ROMs
- Clean up seldom-used menu items and move some options into General Settings
or About
- Integrate Xposed module for bypassing the VPN confirmation dialog
- Switch to ACRA for problem reporting
v0.96 - 2014/07/06
- Force a minimum MTU of 1280 on KK due to bugs in 4.4.3 and 4.4.4 ROMs:
https://code.google.com/p/android/issues/detail?id=70916
- Fix navigation anomalies (weird Back button behavior) seen after
re-entering OpenConnect from one of the Notifications
v0.95 - 2014/06/14
- Show the auth dialog <message> text in case it contains useful information
- Add German translations (thanks to Ingo Zansinger <[email protected]>)
- Add Chinese translations
- Add Advanced options for changing Dead Peer Detection timeout and enabling Perfect Forward Secrecy
- Clean up a bunch of lint warnings and unused strings/files
- Try to generate a human-readable profile name when adding a new VPN
v0.91 - 2014/06/01
- Fix bugs involving saved authgroups
- Fix batch mode error handling
- Update to GnuTLS 3.2.15 to fix GNUTLS-SA-2014-3 / CVE-2014-3466
v0.9 - 2014/04/26
- Add new "Send feedback" screen
- Add new "SecurID info" screen for RSA soft token users
- Allow changing settings and using other menu options (about, SecurID,
send feedback, etc.) while connected
- Update FAQ and provide some links to relevant XDA posts
v0.81 - 2014/04/06
- Fix potential issue recognizing certificates stored in VPN profiles
created with <= v0.7
v0.8 - 2014/04/02
- Fix hangs after reconnect if DTLS is disabled
- Fix incorrect storage of PKCS#12 certificates
- Remove unnecessary passphrase prompts on unencrypted certificates
- Add a workaround for ASA certificate request quirks
- Fix FC when attempting to import an OpenVPN profile
v0.7 - 2014/03/08
- Update GnuTLS to address CVE-2014-0092
- Fix FC and other misbehavior on IPv6 connections
- Update to libopenconnect 5.99+
- Fix/delete several broken translations
- Minor improvements to the auth form UI
- Switch curl from OpenSSL to GnuTLS and remove advertising clauses
v0.6 - 2014/02/09
- First release in Google Play Store
- Change to new "big O" launcher icon
- Avoid displaying error alerts if the user terminated the connection
- Try to make the libopenconnect build process more robust, and strip *.so
files to conserve space
v0.5 - 2014/02/01
- Fix "living dead" connections (can't pass data after reconnection due to
DTLS parameter mismatches)
- Add FAQ tab in response to user feedback
- Move log window into a tab
- Reorganize action bar so that the most important items (Status/Log/FAQ)
are tabs, and less important items (Settings/About) are in the menu
- Fix KeepAlive socket errors on KitKat devices
- Other UI and documentation fixes
- Add split tunnel configuration options
- Improve icons
v0.2 - 2014/01/18
- Allow SecurID token import via URI or text file
- Newly reworked "status" tab with uptime, error alerts, IP addresses,
etc.
- Fix a couple of bugs involving screen rotation / activity redraw on
the log window
- Prompt for hostname instead of profile name when adding a new VPN, to
help avoid "empty hostname" mistakes
- Numerous other UI improvements and fixes
- Remove "reconnect on boot" until it works properly
- Try to accommodate Linux CSD wrapper scripts starting with "#!/bin/bash"
Click to expand...
Click to collapse
FAQ
Q: What is this app used for?
A: OpenConnect is used to access virtual private networks (VPNs) which utilize the Cisco AnyConnect SSL VPN protocol. A typical use case might involve logging into your workplace remotely to check email after hours.
If in doubt, check with your I.T. administrator to see if a suitable service is available.
Q: How do I get started?
A: In most cases, you'll just need to create a profile and enter the hostname of the VPN gateway. The other fields in the profile are all optional and should be left alone unless there is a specific need to change them.
Once you've set up the profile, select the VPN entry and OpenConnect will attempt to establish a new session. If this fails, the "Log" tab may provide helpful diagnostic information.
Q: How do I authenticate using an SSL client certificate?
A: Copy your certificate files to Android's external storage directory (nominally /sdcard or the Downloads folder), then edit the VPN profile and make the following changes:
P12 or PFX file: select "User certificate", pick the file from the list, then touch "select". Leave "Private key" blank.
Single PEM/CRT/CER file: same as above.
Separate PEM/CRT/CER and KEY files: populate "User certificate" with the certificate file, and "Private key" with the key file.
When finished, delete the certificate files from external storage so they cannot be stolen by other apps.
If you are generating your own keys (e.g. for use with your ocserv gateway), some basic CA setup instructions are posted here.
Q: Will OpenConnect work with non-AnyConnect VPNs?
A: Unfortunately the software design is tied very closely to the AnyConnect requirements and the libopenconnect interfaces. Therefore it only works with Cisco AnyConnect and ocserv gateways.
Q: Will OpenConnect work with Cisco IPsec VPNs running on an ASA?
A: OpenConnect supports SSL VPN (CSTP + DTLS) only.
Q: How do I import a SecurID software token?
A: If you have an URL that starts with "com.rsa.securid.iphone://" or "http://127.0.0.1/securid/" in your email, click on it and tell OpenConnect to add it to the desired VPN profile. If you just have a raw token string then write it to a text file, copy it under /sdcard, click "Token string" in the VPN profile editor, then select the filename.
If you have an "sdtid" XML file, copy it to /sdcard and then import it.
Q: Is it possible to skip all login prompts when connecting?
A: If you have saved your username, password, or other credentials, or if you are using SecurID or certificate authentication, you can try enabling "Batch Mode" in the VPN profile to skip the login dialogs. If you need to change your saved password later or have trouble connecting, just disable batch mode.
The VPN warning dialog is a security feature built into the Android OS. It cannot be bypassed by OpenConnect, but if your device is rooted, you can try installing the Xposed Framework and then activating the Auto VPN Dialog Confirm module. Some notes on this are posted here.
Due to the user interaction required by these dialogs, it is not always possible to reliably start up the VPN in the background. So a "start-on-boot" feature is not currently provided.
Q: How do I improve battery life while the VPN is up?
A: One option is to select "Pause when asleep" under Settings. The downside is that VPN access will be temporarily stopped when the screen is off. Also, ASA gateways sometimes get annoyed with constant reconnections and may prematurely terminate your session after a few days.
Another option is to contact your server administrator and request that they disable dead peer detection (DPD), increase the idle timeout to >1hr, and increase the keepalive interval to ~5min or so.
Q: How do I use OpenConnect with AFWall+?
A: There are a few caveats to keep in mind when using an Android firewall with VPN:
* If you run KitKat, use Android 4.4.2 or higher and AFWall 1.2.8 or higher. Android 4.4 and 4.4.1 have a serious TCP MSS bug which causes stalled connections and/or poor performance. AFWall <=1.2.7 does not have the extra logic needed to handle the routing changes in KitKat.
* Always allow traffic from the VPN app on all interfaces. In particular, you should whitelist VPN traffic from OpenConnect, as OpenConnect sends DNS requests over the VPN interface every few minutes to help keep the connection from timing out.
Q: Are any apps incompatible with VPN?
A: Apps which perform their own DNS resolution, such as Firefox, may have issues picking up the latest system DNS settings when connecting to the VPN. This can be a problem if your system DNS servers are not accessible over the VPN's routes, or if you are trying to look up hostnames that do not have public (internet) DNS entries.
Q: Under what circumstances will OpenConnect request root?
A: There are two root-only features shown under Settings; both are disabled by default. One setting works around a ROM bug in CM9 which sets incorrect permissions on /dev/tun, preventing VpnService from passing traffic to the tunnel interface; the other setting loads tun.ko on ROMs that neglect to load it by default.
Based on user feedback and testing, future releases may autodetect these conditions.
Q: How do I send a problem report?
A: Navigate to Log -> (menu) -> Send log file. Please be sure to furnish a complete, accurate description of the issue you are seeing, as the logs do not always show a smoking gun.
Click to expand...
Click to collapse
TODO
Translations - I will set up the necessary infrastructure if there are volunteers
Compatibility testing
Add x509 certificate parsing/validation in the profile editor
Enable Android keystore support
Proxy support
Split tunnel DNS?
Click to expand...
Click to collapse
MISC
Using OpenConnect + ocserv (on a VPS) to bypass China's Great Firewall (GFW): link
XDA:DevDB Information
OpenConnect, App for the Android General
Contributors
cernekee
Source Code: https://github.com/cernekee/ics-openconnect
Version Information
Status: Testing
Created 2014-01-18
Last Updated 2015-02-21
hello cernekee,
I was using smoothconnect on my note3 and It was working just fine, but now after I update my note3 to kitkat it surfs only couple of things like "play store", google search, and whatsup. but all other web sites and programs do not!!
now I tried out this program "open connect" with some hope but nope, I does the same thing. It only opens play store and google search but no other things.
I wonder what cause this problem, any suggestions please??
msm88now said:
hello cernekee,
I was using smoothconnect on my note3 and It was working just fine, but now after I update my note3 to kitkat it surfs only couple of things like "play store", google search, and whatsup. but all other web sites and programs do not!!
now I tried out this program "open connect" with some hope but nope, I does the same thing. It only opens play store and google search but no other things.
I wonder what cause this problem, any suggestions please??
Click to expand...
Click to collapse
Sometimes an MTU or TCP MSS problem could cause this symptom. What kind of gateway are you connecting to? Are you the admininstrator?
Older versions of KitKat did have an MSS problem; I think 4.4.1+ is OK: https://code.google.com/p/android/issues/detail?id=61948
There are a few other outstanding problems on <= 4.4.2: http://www.androidpolice.com/2014/0...n-routing-fixes-are-planned-for-some-of-them/
Do you see the same problem connecting from other systems, like a Windows PC, or even the Cisco AnyConnect Android app?
Hi cernekee,
I have an openSSL Cisco vpn connection provided by my university, I hooked it with D-615 Dlink router through DHCP.
Cisco AnyConnect for andriod does not work on our university network because it asks for a certificate which my uni does not provide. that's why I'm using smoothconnect.
anyways, right now I have a flawless connection on my all devices on my room's wireless like my both Win7 laptops and my galaxy S2 andriod 4.1.2.
all work except my note 3 after I updated it to (4.4.2). I don't know if it's a IPv6 or MTU problem,
I tried to decrease MTU value in smoothconnect but with no success. as Cisco stated in: AnyConnect Android 4.4 (KitKat) Compatibility Update (CSCul28340)
any suggestions please???
msm88now said:
Hi cernekee,
I have an openSSL Cisco vpn connection provided by my university, I hooked it with D-615 Dlink router through DHCP.
Cisco AnyConnect for andriod does not work on our university network because it asks for a certificate which my uni does not provide.
Click to expand...
Click to collapse
I don't see this university's VPN requesting a certificate (i.e. SSL client cert). It just asks for a group/username/password.
Are you getting an error that says that the gateway is not licensed for mobile, after you enter your password?
that's why I'm using smoothconnect.
anyways, right now I have a flawless connection on my all devices on my room's wireless like my both Win7 laptops and my galaxy S2 andriod 4.1.2.
all work except my note 3 after I updated it to (4.4.2). I don't know if it's a IPv6 or MTU problem,
I tried to decrease MTU value in smoothconnect but with no success. as Cisco stated in: AnyConnect Android 4.4 (KitKat) Compatibility Update (CSCul28340)
any suggestions please???
Click to expand...
Click to collapse
Can you grab a packet capture when you're seeing the connectivity failures, and email me the result? e.g.
Code:
adb push tcpdump /data/local/tmp
adb shell
cd /data/local/tmp
su
chmod 755 tcpdump
./tcpdump -n -i tun0 -w out.pcap
yes that's right, Cisco anyconnect asks only for username/ password but when I try to start a connection it ends up with no license error!
that's way I'm using smoothconnect and now openconnect on my both andriod phones.
now for my problem, I didn't get what do you mean by connectivity failure because I'm not getting any connectivity failure messages on my note3 after update to 4.4.2 neither on smoothconnect nor on openconnect. it connects as usual and I can see some traffic packets are being transfered but I can only surf google serch, youtube and some other stuff like play store and whatsup. whenever I try to surf any other website like for example bbc news the browser( chrome, opera, Dolfin..) just waits and then ends up with nothing like there is no internet connection!
did I explain my problem clearly? is it an Ipv6 problem? I'm really confused and frustrated
msm88now said:
yes that's right, Cisco anyconnect asks only for username/ password but when I try to start a connection it ends up with no license error!
Click to expand...
Click to collapse
OK. This is because the Cisco mobile clients look for an "X-CSTP-License: accept" header from the gateway after authenticating, to see if the operator has paid extra to support the Cisco mobile client. libopenconnect-based clients (including SmoothConnect) do not require this header.
now for my problem, I didn't get what do you mean by connectivity failure because I'm not getting any connectivity failure messages on my note3 after update to 4.4.2 neither on smoothconnect nor on openconnect. it connects as usual and I can see some traffic packets are being transfered but I can only surf google serch, youtube and some other stuff like play store and whatsup. whenever I try to surf any other website like for example bbc news the browser( chrome, opera, Dolfin..) just waits and then ends up with nothing like there is no internet connection!
Click to expand...
Click to collapse
I can take a look at this to see what is happening. Just start up tcpdump to capture the tun0 traffic (see above instructions), then try visiting the BBC news site and maybe a few other non-working sites. Then hit control-C to interrupt tcpdump, make sure there is some data in the pcap file, and email me the pcap file.
cernekee said:
I can take a look at this to see what is happening. Just start up tcpdump to capture the tun0 traffic (see above instructions), then try visiting the BBC news site and maybe a few other non-working sites. Then hit control-C to interrupt tcpdump, make sure there is some data in the pcap file, and email me the pcap file.
Click to expand...
Click to collapse
Hi,
I don't know how to make Tcpdump on my note3 not to mention hitting the control-c on andriod. what instruction did you mean?
msm88now said:
I don't know how to make Tcpdump on my note3 not to mention hitting the control-c on andriod. what instruction did you mean?
Click to expand...
Click to collapse
Do you have a friend who is familiar with ADB, rooting phones, etc. who might be able to help out in person?
You could also try something like Shark for Root, or follow this video. Make sure you capture on the tun0 interface so that we can see what is happening on the VPN tunnel. If you capture from the wifi interface you'll still see traffic, but everything will be encrypted so it will not be possible to diagnose the failure.
I got it. first I rooted my note3 then I followed the instruction in the video and here it is, I hope it's what you asked me for. waiting for your diagnosis, fingers crossed
msm88now said:
I got it. first I rooted my note3 then I followed the instruction in the video and here it is, I hope it's what you asked me for. waiting for your diagnosis, fingers crossed
Click to expand...
Click to collapse
According to this trace (partial screenshot attached), the Note 3 is advertising an MSS of 1460 bytes on IPv4 TCP connections. This looks abnormally high for a VPN interface; the other direction is using an MSS of 1380, which looks more realistic. The MSS for IPv4 would normally be the tun0 MTU minus 40 bytes. I am assuming this means the MSS is being computed from the 1500-byte wlan0/eth0 MTU, not the smaller tun0 MTU.
When Google fixed the MSS bug in Android 4.4.1, they left the following comments in the changelog:
Code:
commit ca5b4e8d0d8219273ecf0961ed6e8c47ab5d798a
Author: JP Abgrall <[email protected]>
Date: Wed Nov 20 17:27:01 2013 -0800
SecondaryTableController: force the MSS to match pmtu on TCP SYN
Without this change, the VPN sets up a tun/ppp that needs a small
MTU, and during TCP SYN the MSS will end up matching the outgoing iface
MTU which is potentially too big.
This leads to connection flakiness. The wrong MSS is visible by
tcpdump-ing on the tun/ppp device.
With this change, the MSS now is correct.
[b]It requires the kernel to be configured with
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
If kernel is not configured, it silently fails.[/b]
Bug: 11579326
Change-Id: I254d8c39435b92dff91931e461e1efb8b35f6b1e
Note the bolded sentences (emphasis mine). I suspect that your device is running the latest AOSP netd code that has the fix (if the ROM is indeed based on AOSP 4.4.1/4.4.2), but the kernel may be missing the TCPMSS target. If you see an error when running this command as root, it probably means that kernel support is missing:
Code:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN SYN -d 1.2.3.4 -j TCPMSS --clamp-mss-to-pmtu
Toward the bottom of the page on the original Android 4.4 MSS bug report I see a couple of reports from other Note 3 owners that the problem still isn't fixed for them, so it may be something particular to this device (such as the kernel configuration).
I do not see any evidence of IPv6 usage in your log, which rules out some of the known 4.4.2 VPN issues.
If this does turn out to be a kernel problem, you can try a custom kernel from XDA (assuming you can unlock your bootloader), or you could file a bug report with Samsung asking them to enable CONFIG_NETFILTER_XT_TARGET_TCPMSS=y in the next OTA update. From their end this is a simple, low-risk change.
cernekee;
Note the bolded sentences (emphasis mine). I suspect that your device is running the latest AOSP netd code that has the fix (if the ROM is indeed based on AOSP 4.4.1/4.4.2) said:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN SYN -d 1.2.3.4 -j TCPMSS --clamp-mss-to-pmtu
[/code]
Toward the bottom of the page on the original Android 4.4 MSS bug report I see a couple of reports from other Note 3 owners that the problem still isn't fixed for them, so it may be something particular to this device (such as the kernel configuration).
I do not see any evidence of IPv6 usage in your log, which rules out some of the known 4.4.2 VPN issues.
If this does turn out to be a kernel problem, you can try a custom kernel from XDA (assuming you can unlock your bootloader), or you could file a bug report with Samsung asking them to enable CONFIG_NETFILTER_XT_TARGET_TCPMSS=y in the next OTA update. From their end this is a simple, low-risk change.
Click to expand...
Click to collapse
as you can see in the attachment I applied the code with no error message. so in this case I assume I have no problem with the kernel? right?
then what causes the problem? and what can I do in order to solve it?
msm88now said:
as you can see in the attachment I applied the code with no error message. so in this case I assume I have no problem with the kernel? right?
then what causes the problem? and what can I do in order to solve it?
Click to expand...
Click to collapse
Can you connect to the VPN, try to access a few "bad" sites, and then post the full output from:
Code:
su
iptables -t mangle -nxvL
cernekee said:
Can you connect to the VPN, try to access a few "bad" sites, and then post the full output from:
Click to expand...
Click to collapse
here is the output after some bad sites access, I also repeated the provisos code during an openconnect session. hope it will help us.
msm88now said:
here is the output after some bad sites access
Click to expand...
Click to collapse
Hmm, on my KitKat device I have an st_mangle_POSTROUTING chain which does the TCPMSS clamping:
Code:
Chain st_mangle_POSTROUTING (1 references)
pkts bytes target prot opt in out source destination
0 0 TCPMSS tcp -- * tun0 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
I did not see this in your output. Maybe Samsung is using an outdated version of netd.
Try running this command as root after bringing up the VPN and see if you are able to pass traffic with the bad sites:
Code:
iptables -t mangle -A POSTROUTING -p tcp -o tun0 --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
If not, post the new "iptables -t mangle -nxvL" output so we can look at the traffic counters.
Also can you attach your /system/bin/netd binary?
Thanks.
cernekee;
Try running this command as root after bringing up the VPN and see if you are able to pass traffic with the bad sites:
[code said:
iptables -t mangle -A POSTROUTING -p tcp -o tun0 --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Click to expand...
Click to collapse
are kidding me!! it really worked. after I run the the code I tried to access all the bad sites and all of them worked!! but not as fast as my other mobil SG2. I noticed that it takes noticably much longer to access them. but still, It worked and It's fantastic!!
any ways, I rebooted my note3 to see if it will work again but it turned out it didn't! I need to re-enter the code again to make it work. now could you tell me what is my phones problem exactly? despite the re-entering issue I'm very happy that I finally can use internet on my note3 again thanks to you cernekee.
msm88now said:
any ways, I rebooted my note3 to see if it will work again but it turned out it didn't! I need to re-enter the code again to make it work. now could you tell me what is my phones problem exactly?
Click to expand...
Click to collapse
The ROM is supposed to add that rule automatically, but it doesn't.
If you attach your /system/bin/netd binary and output from "getprop" I'll try to figure out why.
cernekee said:
The ROM is supposed to add that rule automatically, but it doesn't.
If you attach your /system/bin/netd binary and output from "getprop" I'll try to figure out why.
Click to expand...
Click to collapse
here I attached them.
I posted a problem report on Samsung's support forum:
http://developer.samsung.com/forum/...&messageId=259244&listLines=15&startId=zzzzz~
Works like a charm with the lastest Slimkat on Nexus 4. Thanks a lot !
Just add a widget to one click connect from the launcher and it will be the best VPN apps that I've use.
Today I've a Tasker task to launch Anyconnect with uri and simulate touchs screen to automate my connection.
@ edit :
Is there a way to don't have the attached screen ?