Database Info

WiFi and 3g simultaneously Guide - need help following instructions

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

[APP][4.1+] M2D My Second Device

Use this one:
http://forum.xda-developers.com/android/apps-games/app-m2d-notifications-sender-receiver-t2986778

http://forum.xda-developers.com/android/apps-games/app-m2d-notifications-sender-receiver-t2986778

Developer Post:
Want to use M2D Manager for your own modules? Get rid of bluetooth connections and leave that for M2D Manager. Focus on your App.
In order to send a message between devices, the message goes first to M2D Manager with an Intent this way:
Intent i = new Intent("com.pacosal.m2d.manager.action.MSG");
i.setPackage("com.pacosal.m2d.manager");
i.putExtra("action", "Your receiver package and filter");
i.putExtra("data", "message");
sendBroadcast(i);
***********************************************************************************
** version 1.3.0
***********************************************************************************
Added feature to ask m2d Manager for connection state
Register for this filter in your ExternReceiver:
<action android:name="com.pacosal.m2d.manager.action.CONNECTION" />
and in your class use this code:
if (intent.getAction().equals("com.pacosal.m2d.manager.action.CONNECTION")) {
connectionState = intent.getBooleanExtra("connected", false);
return;
}
If you need to know the connection state, you can ask m2d manager with this code:
Intent i = new Intent("com.pacosal.m2d.manager.action.CONNECTION_STATE");
i.setPackage("com.pacosal.m2d.manager");
this.sendBroadcast(i);
***********************************************************************************
** version 1.2.0
***********************************************************************************
Added feature to send and receive binary files. Don't send binary files greater than 500.000 bytes.
To send:
intent.putExtra("binary",byte[]) ;
To receive:
byte[] dataBinary = intent.getByteArrayExtra("binary");
If you need sending greater files, send them with several messages and concatenate them.
***********************************************************************************
** version 1.1.0
***********************************************************************************
By default, M2D Manager stores messages if there is no connection between devices in real time, if for your App the message is only valid in real time, set the following flag. For instance for an instant action.
intent.putExtra("flagNoStore",true) ;
***********************************************************************************
The action parameter include the filter broadcast that the receiver App must implement.
The data parameter is a String message to send to your App. Could be any String text, including json
In order to receive the message in the other App (Could be the same App) M2D Manager send an Intent with the action text you sent before that you have to register in your manifest:
AndroidManifest
<receiver android:name="your_package.ExternReceiver" >
<intent-filter>
<action android:name="Your receiver package and filter" />
</intent-filter>
</receiver>
Class
public class ExternReceiver extends BroadcastReceiver {
public void onReceive(Context context, Intent intent) {
// Do actions...
String data = intent.getStringExtra("data");
Log.D(TAG, data);
}
}
Remember including in Google Play description the sentence M2D My Second Device Module at the end in order that users can find your App from M2D Manager.
Thanks

pacosal said:
Galaxy Note 3 and show your Xperia U, por example.
Click to expand...
Click to collapse
spell mistake
concept is good,any chance of connection by internet rather than using Bluetooth,so that I can use it even when I m out?
coz otherwise I will have to be in Bluetooth range to make everything work ..

anu.cool said:
spell mistake
concept is good,any chance of connection by internet rather than using Bluetooth,so that I can use it even when I m out?
coz otherwise I will have to be in Bluetooth range to make everything work ..
Click to expand...
Click to collapse
Thanks for the mistake
The idea is wear always both devices, because the small one doesn't have SIM
Regards

pacosal said:
Thanks for the mistake
The idea is wear always both devices, because the small one doesn't have SIM
Regards
Click to expand...
Click to collapse
Pacosal my man,
Do both devices need to be running Android?
Could this happen between an iPhone and a Gear?
Thanks!

gidi said:
Pacosal my man,
Do both devices need to be running Android?
Could this happen between an iPhone and a Gear?
Thanks!
Click to expand...
Click to collapse
Sorry my friend, but only Android

pacosal said:
Thanks for the mistake
The idea is wear always both devices, because the small one doesn't have SIM
Regards
Click to expand...
Click to collapse
I don't know anything about coding and all,but it maybe possible to take the app to a whole new level if net connection is possible,like checking on baby when you are out(you can click picture,upload it on cloud and then check it),using your other mobile to use as camera and many more examples ... we can always connect other mobile through wifi!
I am half dead atm(sleepy I mean) so can't really think much,but do give it a thought...

version 1.1.0
- New options for developers for not to store messages not sent if there is no connection in that moment.
By default, M2D Manager stores messages if there is no connection between devices in real time, if for your App the message is only valid in real time, set the following flag. For instance for an instant action.
intent.putExtra("flagNoStore",true) ;

Version 1.2.0 out!
Added feature to send and receive binary files. Don't send binary files greater than 500.000 bytes.
To send:
intent.putExtra("binary",byte[]) ;
To receive:
byte[] dataBinary = intent.getByteArrayExtra("binary");
If you need sending greater files, send them with several messages and concatenate them.
**

Version 1.2.1 out!
- Bug Fixed!

pacosal said:
Version 1.2.1 out!
- Bug Fixed!
Click to expand...
Click to collapse
?, When im watching a movie on my galaxy note 2 i dont receive notifications to my gear, will this (M2D) help with this issue?

rmont23 said:
?, When im watching a movie on my galaxy note 2 i dont receive notifications to my gear, will this (M2D) help with this issue?
Click to expand...
Click to collapse
I think so!

I have asked this question several times on XDA and had no luck, but this seems to be going the right way.
My main phone has to be connected to an external antenna when I am at home because the signal is so poor, I have a couple of spare phones that I want to be able to connect via Bluetooth to my main one, so that I can leave them in other rooms, and when a call comes in I want to be able to use either one as a `remote phone`, can you foresee this being possible? I would have thought, that if a GalaxyGear can remotely make/receive calls then surely a second Android phone can be utilised the same way?
Thanks

SSThing said:
I have asked this question several times on XDA and had no luck, but this seems to be going the right way.
My main phone has to be connected to an external antenna when I am at home because the signal is so poor, I have a couple of spare phones that I want to be able to connect via Bluetooth to my main one, so that I can leave them in other rooms, and when a call comes in I want to be able to use either one as a `remote phone`, can you foresee this being possible? I would have thought, that if a GalaxyGear can remotely make/receive calls then surely a second Android phone can be utilised the same way?
Thanks
Click to expand...
Click to collapse
Hi,
this would be perfect, but for calls it's not possible because Android framework don't have the required bluetooth profiles for this. I think Galaxy Gear has implemented this feature.
What we can get with this App and modules is to warn you when you receive a call in your main device and take it or not. To take it you will need a bluetooth hands free gadget.
Thanks

M2d Manger - Version 1.2.2 out!
- Bug fixed!

Working in several Apps in order to get these:
Could be used in both devices (main and auxiliary). Like a remote.
- Be able to camera preview and take pictures as well.
- Be able to record sounds
- Be able to control media player
Working in first option right now!

Very cool project. Do you plan to add a windows desktop client/receiver.
I've seen something like your app which sends notifications through internet, but Bluetooth would be very cool.

Also if we getting a call in second device, can it be transferred to primary device thro BT which is quite handy and usefull...!!...coz I've 2 sim card and 2 smartphones....!!

This is super awesome
Any plans to allow multicast?
So not just one slave, but many, that could daisy chain even?
Crazy idea in my head: Hook up a multitude of different devices, and have them all snap a picture at the same time

Understanding Pry-Fi and 802.11 probe requests

Over the past year or so, a number of news stories have discussed the possibility of tracking smartphone users in public via wifi probes. The recent announcement of Pry-Fi inspired me to do a little research to see exactly what information was being revealed, and what could be done about it.
The easiest way to observe the information leak in question (and later, to find out if it has been successfully plugged) is to follow part 4 of Vivek Ramachandran's WLAN Security Megaprimer. He describes the process of setting up a virtual machine running Backtrack Linux (now replaced by Kali Linux), and using aircrack-ng and wireshark to observe WLAN activity.
The whole series is worth watching, but here are a few basic survival commands:
Code:
# 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)

Figuring out Samsung Accesory Protocol internals

Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.

javispedro said:
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
Click to expand...
Click to collapse
I think your thread should probably go in the Dev section for Tizen. Have you made any development? If your want it moved, report your own post with the button in top right labeled report. You can then suggest your thread be moved to the new Tizen Development section. Ok, I wish you all the luck, you seem to be very talented programmer/dev. Thanks for your contributions.
Chris

noellenchris said:
I think your thread should probably go in the Dev section for Tizen.
Click to expand...
Click to collapse
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
noellenchris said:
Have you made any development?
Click to expand...
Click to collapse
Yes, lots of progress. I have been able to write a program that connects to the Gear2 from my PC, succesfully "completes" the setup program and synchronizes the date&time. Things like changing the background color etc. are now trivial. I will soon port it to my Jolla.
I am now looking into how to send notifications to the watch. I've not been able to get Gear Manager to actually send any notifications (to use as "reference"), because goproviders crashes when I try to simulate notifications on my android_x86 VM
If anyone can send me an HCI / Bluetooth packet capture of their Android device while it is sending notifications to the Gear2 I would really appreciate it.
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.

javispedro said:
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
Click to expand...
Click to collapse
Ya, I was kinda in a Gear 1 mind set, and they have separate threads for Android and Tizen....
Chris

javispedro said:
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
Click to expand...
Click to collapse
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union

Antartica said:
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Click to expand...
Click to collapse
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.

javispedro said:
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
Click to expand...
Click to collapse
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)

Antartica said:
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Click to expand...
Click to collapse
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".

javispedro said:
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
Click to expand...
Click to collapse
No problem. Curiously, I've transitioned from the metawatch to the Gear1 fully (null rom, not pairing with bluetooth to the phone but gear used as a standalone device).
[off-topic]I'm not using my metawatch anymore. I was modifying Nils' oswald firmware to make it prettier and to have some features I wanted (calendar, stopwatch), but it was very inaccurate, supposedly because of missing timer interrupts (the existing LCD drawing routines were too slow). I rewrote the graphics subsystem just to stumble into a known mspgcc bug, and trying to use the new redhat's mspgcc resulted in more problems (memory model, interrupt conventions). In the end I couldn't commit enough time to fix that and my metawatch is now in a drawer[/off-topic]
Returning to the topic:
javispedro said:
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
Click to expand...
Click to collapse
Good. We can at least say it isn't DES/3DES nor blowfish (64 bits block size). Regrettably there are a lot of ciphers using 128-bits block size; that I know: AES, Twofish and serpent.
Perusing the wikipedia there are some more of that size in use: Camellia, sometimes RC5 and SEED.
javispedro said:
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
Click to expand...
Click to collapse
I understand that to mean that you cannot use that library passing your own key, right?
What a pity! One way to test for these ciphers would have been to just cipher a known string (i.e. all zeroes) with a known key (i.e. also all zeroes) and compare the result with each of the normal ciphers :-/.
javispedro said:
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
Click to expand...
Click to collapse
Perfect. I don't need anything more .

Ok, so I've uploaded my SAP protocol implementation: https://git.javispedro.com/cgit/sapd.git/ . It's "phone" side only, ie it can be used to initiate a connection to the watch but not to simulate one. In addition, it's missing two important files: wmscrypt.cc and wmspeer.cc which implement the closed crypto required to "pair" the watch. The most important file is sapprotocol.cc which implements the packing/unpacking of the most important packet types. The license of those files is GPLv3 albeit I'm very happy if you use the information contained on them to build your "Gear Manager" program under whichever license you'd prefer.
For anyone who hasn't been following the above discussion: I've figured out a large part (useful for at least establish contact with the watch and syncing time/date) of the SAP protocol used between the Gear watch and the Gear manager program on the phone. This has been done mostly by studying traces and afterwards talking to the watch using my test implementation above to figure out the remaining and some error codes. The debug messages left by the watch's SAP daemon were also immensely helpful. As long as I understand this is perfectly safe to do, publish and use as I'm in the EU and is basically the same method Samba uses.
Unfortunately, the protocol contains some crypto parts required for the initial sync (subsequent connections require authentication). However, the communication itself is not encrypted in any way, which helped a lot with the process. Because it's impossible for me to figure out whatever authentication method is used, I had to disassemble the library implementing this stuff (libwms.so). This is still OK according to EU law, but I'm no longer to release that information to the public. I'm looking for alternatives or ideas on how to handle this fact.
In the meanwhile, let's talk about the protocol. It's basically a reimplementation of the TCP(/IP) ideas on top of a Bluetooth RFCOMM socket. This means that it's connection oriented and that it can multiplex several active connections (called "sessions") over a single RFCOMM link. Either side of the connection can request opening a connection based on the identifier of the listening endpoint (called a "service"). Strings are used to identify services instead of numeric ports as in TCP. For example, "/system/hostmanager" is a service that listens on the watch side. Once you open a session towards this service (i.e. once you connect to it) you can send the time/date sync commands. In addition to be the above the protocol also seems to implement QoS and reliability (automatic retransmission, ordering, etc.). It's not clear to me why they reimplemented all of this since RFCOMM is a STREAM protocol, and thus reliability is already guaranteed!! So I've not focused much on these (seemingly useless) QoS+reliability parts of the protocol.
Let's start with the link level. There are two important RFCOMM services exposed by the watch: {a49eb41e-cb06-495c-9f4f-aa80a90cdf4a} and {a49eb41e-cb06-495c-9f4f-bb80a90cdf00}. I am going to respectively call those two services "data" and "nudge" from now on. These names, as many of the following ones, are mostly made up by me .
The communication starts with Gear manager trying to open a RFCOMM socket towards the "nudge" service in the watch. This causes the watch to immediately reply back by trying to open a connection to the "data" service _on the phone_ side. So obviously this means that your phone needs to expose the "data" RFCOMM service at least. In addition, the watch will try to open a HFP-AG connection (aka it will try to simulate being a headset) to your phone. Most phones have no problem doing this so no work is required. Of course, if your phone is a PC (as in my case ) then you'll need to fake the HFP profile. I give some examples in my code above (see scripts/test-hfp-ag and hfpag.cc).
Once the RFCOMM socket from the watch to the phone "data" service is opened, the watch will immediately send what I call a "peer description" frame. This includes stuff such as the model of the watch as well as some QoS parameters which I still don't understand. The phone is supposed to reply back to this message with a peer description of its own. See sapprotocol.cc for the packet format.
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
After these two exchanges link is now set up. The first connection that needs to be opened is towards a service that is always guaranteed to be present, called "/System/Reserved/ServiceCapabilityDiscovery". It is used by both sides of the connection to know the list of available services present on the other side. Despite this, you cannot query for all services; instead, you must always know the name of the remote service you're looking for. There's some 16-byte checksum there which I don't know how to calculate, but fortunately the watch seems to ignore it!! I suspect that you're expected to actually persist the database of available services in order to shave a roundtrip when connection is being established. But this is not necessary for normal function. This service is implemented in capabilityagent.cc, capabilitypeer.cc . This part was actually one of the most complex ones because of the many concepts. I suggest reading the SDK documentation to understand all the terms ("service", "profile", "role", etc.).
If everything's gone well, now the watch will try to open a connection to a service in your phone called "/system/hostmanager". Once you get to this message things start to get fun, because the protocol used for this service is JSON! It's implementation resides in hostmanageragent.cc, hostmanagerconn.cc . For example, Gear Manager sends the following JSON message once you accept the EULA: {"btMac":"XX:XX:XX:XX:XX:XX", "msgId":"mgr_setupwizard_eula_finished_req", "isOld":1}. At this point, the watch hides the setup screen and goes straight to the menu.
Well, this concludes my high-level overview of the SAP protocol. Hope it is useful for at least someone!
Things to do:
Personally I'm looking for some traces of the notification service. Ie the one that forwards Android notifications towards the watch. For some reason it doesn't work on my phone, so I can't get traces. I suspect it's going to be a simple protocol so a few traces will be OK. It's the only stuff I'm missing in order to be able to actually use the Gear as a proper smartwatch with my Jolla.
We still need to tackle the problem of the cryptographic parts. Several options: either "wrap" the stock libwms.so file, try to RE it the "proper way", .... I'm not sure of the feasibility of any of these.
Many other services.

javispedro said:
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
Click to expand...
Click to collapse
About that 65-byte bigint... that is a 520-bit key. The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing (just like in bitcoin, so there are a lot of implementations of that code).

Not forgotten about this!
Just an status update:
I'm still in the process of defining the API of the C library using javispedro's sources as template.
It's tougher than I originally supposed because the C++ code has a lot of forward-declarations of classes, which is very difficult to map into C. To counter that I have to move elements between structures and I'm not so comfortable with the codebase yet.
And then there is still the hard work of translating the Qt signals/slots to plain' old callbacks... and implementing the bluetooth part using bluez API... and... well, I hope that is all.
Anyway, patience .

I've now had access to a Samsung S2 and thus I have been able to obtain more traces. The latest Git now contains code to connect to the notification manager service, thus allowing to send notifications from the phone to the watch.
That was the last missing part to be able to use the Gear 2 as a 'daily' smartwatch with my Jolla, so I've now also ported the code to run under Sailfish. In fact I'm using this setup at the moment. My first comment is "wow the vibrator IS weak".
You can find a log of sapd's (ie my code) startup qDebug() messages; they may be useful (if you can't yet get your code to run)
I suspect that there may still be some important battery issues because the watch keeps printing error messages about SAP services it can't find on the phone (and instead of sleeping, it starts busy polling for them.... :/ ). It does not seem to happen while the watch is out of the charging cradle, so it may not be important, but not sure yet.
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
Antartica said:
The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing
Click to expand...
Click to collapse
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.

Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
javispedro said:
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Click to expand...
Click to collapse
If you manage to describe it using mathematical formulas as in
http://en.wikipedia.org/wiki/Ellipt...ture_Algorithm#Signature_generation_algorithm
it would be perfect, but I reckon that to be able write that you need intimate knowledge of the code and don't know if you have time for that :angel:
And identifying the hash function used would be a problem in itself...
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Anyway, I have a lot of work before me until I need that, so don't fret over it.

Hi there! Any chance that the Gear can (really) work with an iPhone?

gidi said:
Hi there! Any chance that the Gear can (really) work with an iPhone?
Click to expand...
Click to collapse
agreed. Needs iPhone support please.

Antartica said:
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
Click to expand...
Click to collapse
You may want to look at the official Samsung SDK docs to match their class hierarchy. I tried to match my hierarchy to theirs, but this happened very late in the development process, so there is some weirdness.
Antartica said:
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Click to expand...
Click to collapse
I more or less know what it is doing with OpenSSL, but that's because I looked at the dissassembly. They use OpenSSL for key derivation (ECDH), but the actual cryptographic algorithm is their own. This 'block cipher' is the part they have tried to obfuscate. Not much, but still enough to require more time than what I have available It is basically a set of arithmetical operations with some tables hardcoded in the libwsm.so binary, so no external calls to any library. The hardcoded tables are probably derivated from their private key, which is most definitely not on the binary. In fact I suspect this is basically AES with some changes to make it hard to extract the actual key used, so that's where I've centered my efforts.
Technically it should not even be copyrightable, so maybe I could just redistribute my C reimplementation of the algorithm, but as with any other DRM who knows these days... and that still leaves the problem of the tables/"private key".
Digiguest said:
agreed. Needs iPhone support please.
Click to expand...
Click to collapse
Well you are welcome to implement one such iPhone program yourself. Will be happy to resolve all the protocol questions you have.
(But please stop with the nagging).

Wasn't nagging at all. Just agreeing with him. I am no programmer so I have to rely on others for answers. Sorry if you thought otherwise.
Looking for to see more work on it though. Keep it up.

Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.

Duobix said:
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Click to expand...
Click to collapse
javispedro had the sources in gitorius, but they are not there anymore (surely related to gitlab buying gitorius).
I attach a tarball with javispedro sources as of 19 October 2014.
Note that it lacks the files implementing the crypto, so just porting it is not enough to be able to communicate to the gear. OTOH, I know that there are some differences in the protocol between the Android Gear1 and the Tizen Gear2 (if the gear1 has been updated to Tizen, it uses the same protocol as gear2). Specifically, to be able to communicate with both watches, the gear manager package has both gear manager 1.7.x and gear manager 2.x. javispedro's code implements the gear 2 protocol.
Personally, I have my port on hold (I have problems with bluetooth in my phone, so there is no point in porting sapd right now as I would not be able to use it).

reading vechicle sensor data in Android app? (CANBUS input)

Dear devs,
I have MTCD PX5 MX (Witson).
I would like to make some small utility apps to enhance HU functionality based on vehicle data.
I would like for example to read the vehicle speed in my app (without using GPS or OBD). I know it's available somewhere in the OS because you can see it in the factory "Vehicle Info" app which seems to be the same for all MTCD units.
Is it some /proc file to be read? Some broadcasts? Some android API additions or some native library calls?
Thanks!

rumburake said:
Dear devs,
I have MTCD PX5 MX (Witson).
I would like to make some small utility apps to enhance HU functionality based on vehicle data.
I would like for example to read the vehicle speed in my app (without using GPS or OBD). I know it's available somewhere in the OS because you can see it in the factory "Vehicle Info" app which seems to be the same for all MTCD units.
Is it some /proc file to be read? Some broadcasts? Some android API additions or some native library calls?
Thanks!
Click to expand...
Click to collapse
The only way is decompilation of an app (you have to find one which deals with CANBUS) and analysis of decompiled source code. There is no API for such things in these devices.

rumburake said:
Dear devs,
I have MTCD PX5 MX (Witson).
I would like to make some small utility apps to enhance HU functionality based on vehicle data.
I would like for example to read the vehicle speed in my app (without using GPS or OBD). I know it's available somewhere in the OS because you can see it in the factory "Vehicle Info" app which seems to be the same for all MTCD units.
Is it some /proc file to be read? Some broadcasts? Some android API additions or some native library calls?
Thanks!
Click to expand...
Click to collapse
You need a canbus decoder. If you buy a canbus decoder for VW golf/Jetta mk5/mk6 I can tell you which messages you need to send to the canbus decoder for the vehicle info apk and for door information, and you can easily send messages with Arduino (with canbus board) or with teensy 3.1 (with can transeiver) or other microcontroller.

I notice by default, (after installing Titanium Backup) that the Vehicle App is "frozen" and when I unfreeze it to run, it doesn't really stay open. I do have a CANBus interface for my 08 Mitsubishi Lancer Evolution X. I noticed in Factory Settings>CANBus, it has options (standard/swap) for front door, back door and air conditioning. Is there any way to have the data displayed somehow? Is the vehicle info app supposed to show it?
Sent from my Nexus 9 using Tapatalk

verkion said:
I notice by default, (after installing Titanium Backup) that the Vehicle App is "frozen" and when I unfreeze it to run, it doesn't really stay open. I do have a CANBus interface for my 08 Mitsubishi Lancer Evolution X. I noticed in Factory Settings>CANBus, it has options (standard/swap) for front door, back door and air conditioning. Is there any way to have the data displayed somehow? Is the vehicle info app supposed to show it?
Sent from my Nexus 9 using Tapatalk
Click to expand...
Click to collapse
In my case (mazda cx5) the vehicle.apk is not the one for showing information
When I open any door it is displayed on the unit.
Even having the same options (air conditioning) like you air conditioning info is not displayed.
Enviado desde mi D6603 mediante Tapatalk

Oh. OK. Hrm...must be controlled somewhere else then. I wonder how I can get it to begin to display that type of info.
Sent from my Nexus 9 using Tapatalk

I'm also in the topic for some weeks, and there is no api or information to access the canbus from the unit.
To reverse engineer the can bus app was the only suggestion provided also.
I think the aim should be to create a android socket can bus api driver for the unit.

Thanks for your interest guys, I managed to get the data by examining the "Vehicle" app (MTCControlInfo.apk). :victory:
There's a broadcast "com.microntek.sync" which contains a byte[] extra called "syncdata". The array has 20 byte values of which I decoded the speed, revs, voltage, temperature and total mileage. When data[2] == 2, the data is:
Code:
// RPM
int rpm = (0xFF & data[3]) * 256 + (0xFF & data[4]);
// SPEED
double speed = ((0xFF & data[5]) * 256 + (0xFF & data[6])) * 0.01d;
// BATTERY
double battery = ((0xFF & data[7]) * 256 + (0xFF & data[8])) * 0.01d;
// TEMP
double temp = (0xFF & data[9]) * 256 + (0xFF & data[10]);
if (temp >= 32768) {
temp -= 65536;
}
temp /= 10;
// DISTANCE
int distance = (0xFF & data[11]) * 65536 + (0xFF & data[12]) * 256 + (0xFF & data[13]);
The problem is the Broadcast doesn't come unless the "Vehicle" app is started. They seem to either:
flip a switch like this:
Code:
Settings.System.putInt(this.getContentResolver(), "com.microntek.controlinfo.door", 1); // in onCreate() and onStart()
and
Code:
Settings.System.putInt(this.getContentResolver(), "com.microntek.controlinfo.door", 0); // in onStop()
I couldn't get my app to do this, you're not allowed to do this unless you're a system app.
or get the CarManager (which is in another app which I didn't get yet to examine), to do some command, perhaps another Broadcast.
I can get continuous data Broadcasts if I start the "Vehicle" app, then go to home screen, then start my app. Since onStop() would be called I believe it's the second method of switch that really happens.
As soon as you explicitely exit the "Vehicle" app the Broadcasts stop coming.
I'm using Bytecode Viewer, but it has quite a few errors translating to Java. A better disassembler would come in handy.
TBC...

rumburake said:
Thanks for your interest guys, I managed to get the data by examining the "Vehicle" app (MTCControlInfo.apk). :victory:
There's a broadcast "com.microntek.sync" which contains a byte[] extra called "syncdata". The array has 20 byte values of which I decoded the speed, revs, voltage, temperature and total mileage. When data[2] == 2, the data is:
Code:
// RPM
int rpm = (0xFF & data[3]) * 256 + (0xFF & data[4]);
// SPEED
double speed = ((0xFF & data[5]) * 256 + (0xFF & data[6])) * 0.01d;
// BATTERY
double battery = ((0xFF & data[7]) * 256 + (0xFF & data[8])) * 0.01d;
// TEMP
double temp = (0xFF & data[9]) * 256 + (0xFF & data[10]);
if (temp >= 32768) {
temp -= 65536;
}
temp /= 10;
// DISTANCE
int distance = (0xFF & data[11]) * 65536 + (0xFF & data[12]) * 256 + (0xFF & data[13]);
The problem is the Broadcast doesn't come unless the "Vehicle" app is started. They seem to either:
flip a switch like this:
Code:
Settings.System.putInt(this.getContentResolver(), "com.microntek.controlinfo.door", 1); // in onCreate() and onStart()
and
Code:
Settings.System.putInt(this.getContentResolver(), "com.microntek.controlinfo.door", 0); // in onStop()
I couldn't get my app to do this, you're not allowed to do this unless you're a system app.
or get the CarManager (which is in another app which I didn't get yet to examine), to do some command, perhaps another Broadcast.
I can get continuous data Broadcasts if I start the "Vehicle" app, then go to home screen, then start my app. Since onStop() would be called I believe it's the second method of switch that really happens.
As soon as you explicitely exit the "Vehicle" app the Broadcasts stop coming.
I'm using Bytecode Viewer, but it has quite a few errors translating to Java. A better disassembler would come in handy.
TBC...
Click to expand...
Click to collapse
Use this decompiler:
http://www.javadecompilers.com/apk
According to CarManager - it is located inside framework.jar. You can see example usage in my app here:
https://github.com/f1xpl/MtcdTools
To use it in your project, simply copy source code loated at app/src/main/java/android/microntek/ except f1x dir to your project directory.

Cool you've got something.
But it looks like some processed data and not the raw can you will need for full controll so you have to mine deeper.

iwl said:
But it looks like some processed data and not the raw can you will need for full controll so you have to mine deeper.
Click to expand...
Click to collapse
As said in the original post what I want is this data. Don't put your hopes into me digging into the canbus as it's not my purpose.

rumburake said:
As said in the original post what I want is this data. Don't put your hopes into me digging into the canbus as it's not my purpose.
Click to expand...
Click to collapse
I have been looking into this also.
My unit is an MTCD PX5 MX, currently using Malaysk rom 5.0 and MX mcu 2.59. The car is a Peugeot 407.
I get air condition data: temperature readings from both sides of the car, air flow direction only from the driver's side, and the temperatures are off by 4 degrees (ie. showing 17C when the temp is set at 21C).
Steering wheel keys: Volume up/down always work, the other keys, Next, Prev, Source, and the "clicky wheel button" (which should change radio preset, change folder in music player etc.) only work if they are the very first button pressed after a reboot - it seems like something crashes on the first press, and after that only the volume buttons work.
I tried going into setup, factory settings, and using 'logcan' as password, the can logger starts, showing me that it does receive data on all the steering wheel keys, even if they no longer perform any action on the head unit after the first press.
The keys send data like the following:
Source: 2e 02 11 ...
Next: 2e 02 12 ...
Prev: 2e 02 13 ...
Volume up: 2e 02 14 ...
Volume down: 2e 02 15 ...
Volume up+down (should do Mute): 2e 02 16 ...
Clicky wheel button: 2e 02 03 ... or 2e 02 04 ... depending on the direction.
I want to modify the can bus apk, making it add 4 to air con temperature readings before showing, and I would also like to figure out, what happens when I press a steering wheel key for the first time, since everything works initially and then stops after the first press.

My unit is an MTCD PX5 MX, currently using Malaysk rom 5.0 and MX mcu 2.59. The car is a Peugeot 407.
Click to expand...
Click to collapse
Where did you get this MCU? AFAIK 2.55 is the latest MCU available for MX (according to: https://forum.xda-developers.com/an...opment/mtcd-px5-headunits-repository-t3619906)
MCUs from different models (HA etc) present minor incompatibilities such as different key setups / fascias between models. It may well be your problem with the buttons!

OK I got it now to work properly. :victory:
To get messages you need to send a request using CarManager. I have used the CarManager code from MTCDTools (thank you @f1x !)
In the case of a canbus adapter config 1 (VW/Skoda) you can send this message periodically to receive a data response (including the speed, rpm etc):
Code:
canbus_rsp=46,144,2,65,2,42
These numbers are made by functions specific to the canbus adapter type which you can find in the "Vehicle" app. I could obviously test this only on my car.
For this canbus config there are 2 other sequences, that return other data too:
Code:
canbus_rsp=46,144,2,65,3,41
canbus_rsp=46,144,2,65,1,43
To send a message you can call:
Code:
CarManager.setParameters(String par);
I hope this helps other people.... I will post again when I build something useful on this.

Interesting thread, would be nice to see the speed data applied to other apps (like Graser's Dasaita or F1x' sound to speed adjust, or Malaysk's screensaver), without the need to get GPS data.
But I guess not all MTCx units will have the speed data, so using GPS will be more generic. I do think the speed data from canbus will be more reliable when the unit supports it.

rumburake said:
Code:
canbus_rsp=46,144,2,65,2,42
Code:
CarManager.setParameters(String par);
Click to expand...
Click to collapse
Does this altogether mean : ?
Code:
CarManager.setParameters("canbus_rsp=46,144,2,65,2,42");
logcan as factory settings password is such valuable information....
---------- Post added at 01:48 ---------- Previous post was at 01:31 ----------
if code logcan starts the canlog app, may be this app is to find, smaller and more easy to decompile / hack.

logcan Can Bus Logger How To ?
KlausBJ said:
'logcan'
Click to expand...
Click to collapse
I'm just playing around with the factory settings pw logcan Can-Logger, but get nothing shown.
I've tried to send with 125000 Baud and 500000 Baud.
What number do you have choosen in the upper right corner there is No, 01, ..., FF ?
How have you used the bottom Buttons, I pressend Start, changing to stop then, what is TX RX for?

I'm also confused.
What's supposed to be inside the String when
Code:
CarManager.setParameters()
is called?
With this method is it possible to write to the CanBus or just read from it?
I'm asking because I'm trying to find a way to control the fade on my factory amp and this seems like the perfect way to do it if writes are possible.

I am now working on a volume setting app using the car speed and rpm. The volume is relative to the one set by user. I got promising results so far.
But I'm stuck at setting the HU volume, it does not sync with the manual controls: suppose volume is 5, then I set it programmatically to 10, then the user turns the knob up it becomes 6 (because it starts from 5)!
 @f1x you do have experience with this, could you please advise? I have tried all of the following:
This is for setting the real volume in the hardware (a volume value mapped from 0% to 100%):
Code:
carManager.setParameters("av_volume="+mtcLevel);
This is temporary and the Android OS doesn't know the volume was changed.
This setting seems to be used for saving the system known volume (0-30):
Code:
android.provider.Settings.System.putInt(ctx.getContentResolver(),"av_volume=",level);
But doesn't seem to have effect and I get this warning: You shouldn't keep your settings in the secure settings. This will soon become an error.
The same volume used to send a broadcast (also 0-30):
Code:
Intent intent = new Intent("com.microntek.VOLUME_CHANGED");
intent.putExtra("volume",level);
ctx.sendBroadcast(intent);
This probably it's just for notifying other apps (it's also how I get the volume changes in my app).
Anyhow what I mean is to set the volume to 10 and when I turn the knob up to find it at 11. Thanks!

rumburake said:
I am now working on a volume setting app using the car speed and rpm. The volume is relative to the one set by user. I got promising results so far.
But I'm stuck at setting the HU volume, it does not sync with the manual controls: suppose volume is 5, then I set it programmatically to 10, then the user turns the knob up it becomes 6 (because it starts from 5)!
@f1x you do have experience with this, could you please advise? I have tried all of the following:
This is for setting the real volume in the hardware (a volume value mapped from 0% to 100%):
Code:
carManager.setParameters("av_volume="+mtcLevel);
This is temporary and the Android OS doesn't know the volume was changed.
This setting seems to be used for saving the system known volume (0-30):
Code:
android.provider.Settings.System.putInt(ctx.getContentResolver(),"av_volume=",level);
But doesn't seem to have effect and I get this warning: You shouldn't keep your settings in the secure settings. This will soon become an error.
The same volume used to send a broadcast (also 0-30):
Code:
Intent intent = new Intent("com.microntek.VOLUME_CHANGED");
intent.putExtra("volume",level);
ctx.sendBroadcast(intent);
This probably it's just for notifying other apps (it's also how I get the volume changes in my app).
Anyhow what I mean is to set the volume to 10 and when I turn the knob up to find it at 11. Thanks!
Click to expand...
Click to collapse
Take a look at this remark:
Checks if the specified app can modify system settings. As of API level 23, an app cannot modify system settings unless it declares the WRITE_SETTINGS permission in its manifest, and the user specifically grants the app this capability. To prompt the user to grant this approval, the app must send an intent with the action ACTION_MANAGE_WRITE_SETTINGS, which causes the system to display a permission management screen.
Click to expand...
Click to collapse
https://developer.android.com/refer...System.html#canWrite(android.content.Context)