1
skylancer 2017-08-27 04:29:09 +08:00
在这个 case 里,获取的是路由器的 mac 地址,iOS 同样也能获取
另外,同样也能遍历网络 |
2
EmmaSwan OP @skylancer 这我就不能理解了,既然 IOS 应用也能获取网卡地址,为什么无法实现定位? 难道是迫于苹果压力,假装无法定位?
|
3
greenskinmonster 2017-08-27 07:00:22 +08:00
网卡地址是指什么? MAC 地址?还是 IP 地址?
|
4
EmmaSwan OP @greenskinmonster 额,正文第一段结尾“更改路由器网卡地址后,定位就失败了。 ” 所以我说的,肯定是路由器的网卡地址。它不可能利用手机网卡地址来定位的啊,因为你走到哪里,手机网卡都是一个地址啦。但是你不同地方,就有不同路由,所以根据你的路由网卡就知道你在哪里嘛。我以为大家都知道,所以标题就简单写了
|
6
EmmaSwan OP @szlytlyt “各种全家桶依旧轻易地获取了准确定位”。。。准确定位。。。你说的 IP 定位,我个人理解,很大程度上也要依赖于其他方式的定位,然后与 IP 关联起来。但这 IP 如果重拨号后被你隔壁小区人用了,自然也就不准确了。网卡定位,据我的多次实验,是精确到了 10 米内,也就是你在楼下进屋前最后的精准 GPS,会与你的网卡关联起来
|
7
EmmaSwan OP @szlytlyt 所以,我的理解,网卡定位,你局域网里的人越多,定位越准。而 IP 定位,用过这个 IP 的人越多,就越分散
|
8
EmmaSwan OP @szlytlyt 哦,对了,忘了说。如果你的路由器“爱国”了,且没有被你用于国内的服务,那这个爱国 IP 是不会有国内位置记录的。但这种情况下,依然可以用你的网卡地址来定位,而不管你的 IP 在什么国家
|
9
panda1001 2017-08-27 08:43:56 +08:00 via Android 1
安卓应用只要有权限获取周围 AP 的 SSID 和 MAC,再怎么防止定位也是徒劳
|
10
EmmaSwan OP @panda1001 这就是我发这个帖子的原因,“基于什么考量”要允许应用获取网卡地址,这在我看来,应用的正常运行根本不需要知道我是什么网卡嘛
|
11
panda1001 2017-08-27 09:41:50 +08:00 via Android
@EmmaSwan
一般路由器在是区分 LAN 口的 MAC 和无线 AP 的 MAC 应用有网络权限就能用 ARP 拿到路由器 LAN 口的 MAC,这个避免不了的,手机的定位权限就在 AP 的 MAC 获取上,也就是 wifi 列表 可惜一般路由器默认这两个 MAC 是一样的,即使有不一样差别也在最后一位不同,这么说来,像 PC 机这种完全有线接入的通过大数据也能被精确定位,ios 应用也是假装不知道 |
12
EmmaSwan OP @panda1001 对对,这个思路下次试试,家里有个吃灰的路由刷过 Tomato,记得是可以更改全部三个网卡地址,看看还能不能定位到。如果真是你说的这样,买 IOS 的理由又少了一个
|
13
fcka 2017-08-27 10:08:35 +08:00 via Android
wifi 的 MAC 地址能被获取到是 wifi 协议支持的,一个手机操作系统无法改变。不知道密码,通过扫描就能轻易获取到所有可用 wifi 的 MAC 地址。各大厂都有 公网 ip MAC wifi 名 三者结合的定位数据库,需要定位时尽力匹配。
楼主现在明白了吧。 |
14
zhaoxiting1997 2017-08-27 10:09:35 +08:00
这个问题不是在于获取网卡地址,而是 Android 允许获得周边 WIFI 的 SSID 和 MAC。定位是通过一些高精度定位的手段比如 GPS,配合标记周边 WIFI 的 SSID 和 MAC 实现的,所以你改变了 MAC 后,定位会无法成功。所以这一点跟网卡地址无关,跟局域网内的用户也无关,而是周围所有能搜索到你 WIFI 并使用了那些地图 SDK 的人都在进行标记。这个功能挺多时候确实挺有用的特别是在室内收不到 GPS 的时候,Android 已经把获取周边 WIFI 列表的权限加在了定位权限里面。
|
15
fengleidongxi 2017-08-27 10:21:13 +08:00
|
16
zjl5918 2017-08-27 11:09:39 +08:00 via Android
咋刷
|
17
honeycomb 2017-08-27 11:46:29 +08:00
@EmmaSwan
无论是 iOS 还是 Android 都允许获取当前已经连接的 wifi 热点的 SSID 与 BSSID 无论是 iOS 还是 Android 都不允许获取本机的 WLAN/蓝牙的 MAC 在没有获取定位权限时,Android 不允许获取周边其它 wifi 热点的信息 问题是在于,Google 对不给权限不启动的态度是“ You can always give 1 star in the store ”,所以这个事情无解,除非你接管了 AOSP |
18
honeycomb 2017-08-27 11:47:34 +08:00
@EmmaSwan
我提交过这个 issue (允许获取当前已经连接的 wifi 热点的 SSID 与 BSSID ),回答是 fixed,但不清楚它改了什么地方 |
19
fengleidongxi 2017-08-27 12:41:28 +08:00
@honeycomb
iOS 允许 READ_PHONE_STATE 吗? |
20
jerry12547 2017-08-27 12:58:20 +08:00
不是说 o 更改额策略了吗 你获得的 mac 地址是随机出来的而不是真实的地址
|
21
evagreenworking 2017-08-27 13:22:18 +08:00 via Android
Android 8 关于隐私还是有不少改进的 尤其是终于用了随机 mac 应对 wifi 探针 这对于那些现在铺 wifi 热点拿 mac 的公司影响不小 但是你一旦连上了 wifi 基本能定位 除非你的 wifi 从来没有被国内服务访问过
|
22
woyaojizhu8 2017-08-27 13:27:38 +08:00
https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html
谷歌没理由全心全力阻止应用获取你的信息,毕竟谷歌对 android 掌控不如苹果对 ios 那样大,不可能得罪开发者太多的。 |
23
woyaojizhu8 2017-08-27 13:28:21 +08:00
@jerry12547 #20 那是针对路由器来说
|
24
woyaojizhu8 2017-08-27 13:30:02 +08:00
@evagreenworking #21 但是注重隐私的人根本不会连公共 wifi 吧;这样的随机 mac,对他们只会带来不便
|
25
evagreenworking 2017-08-27 13:38:09 +08:00 via Android
只是在扫描阶段随机 和 ios 机制应该类似 就是为了应对公共 wifi 探针而已 连上了路由获取的就是真实 mac 否则连上也随机那 mac 地址就真没用了
@woyaojizhu8 |
26
honeycomb 2017-08-27 13:42:09 +08:00
@fengleidongxi
iOS 不适用 Android.Permission 的概念 iOS 不能(没有公开 API),也不允许(不允许使用私有 API)使用任何的持久设备识别码,但是 iOS11 为每个应用提供了一个只有两比特长度的持久识别码,用于识别滥用试用(应用重装后往往无法识别设备)等情况 @woyaojizhu8 随机 MAC 最早在 iOS 出现,现在 Android,Windows10 也有,但表现不一致。 大致意义上是设备在搜寻附近的热点时,需要发出探测(probe)帧以让热点回应,使用了随机 MAC 特性后,这些 probe 帧上面的 mac 地址会变成随机的,而非设备真正的 MAC。等到正式连接时则使用设备真正的 MAC。 在 Android 方面可以保证 Android 7+的亲儿子都有这个特性,但 OEM 制造的 Android 设备是否有这个特性则可能无法保证,首先 CDD 没有随机 MAC 的要求,CTS 是否进行这方面测试我不得而知,需要查看它的源代码。 Windows10 的随机 MAC 则更强化,连接到新热点时,系统甚至会使用新的随机 MAC。 @evagreenworking “但是你一旦连上了 wifi 基本能定位 除非你的 wifi 从来没有被国内服务访问过” 应用在没有定位权限的情况下,应当不能取 wifi 热点的信息中供识别地理位置的部分 |
27
evagreenworking 2017-08-27 14:28:39 +08:00 via Android
@honeycomb 现在各大厂靠采集的 ssid 和 bssid 的数据库足可以大致定位了吧 自己不开定位可是架不住同事和邻居助攻啊
|
28
honeycomb 2017-08-27 14:33:31 +08:00
@evagreenworking
正是因为这样,应用不应能毫无限制地获取这两个信息 |
29
woyaojizhu8 2017-08-27 14:55:39 +08:00
@panda1001 #11 如果“应用有网络权限就能用 ARP 拿到路由器 LAN 口的 MAC ”,那就只有随机化路由器 lan 口 mac 一条路了吧,光修改手机系统是无法阻止应用通过这种信息来定位的,毕竟附近助攻的人太多
|
30
fengleidongxi 2017-08-27 16:12:13 +08:00
@woyaojizhu8 谷歌没理由全心全力阻止应用获取你的信息,毕竟谷歌对 android 掌控不如苹果对 ios 那样大,不可能得罪开发者太多的。。。。。。。
应用获取你信息的目的是什么? |
31
woyaojizhu8 2017-08-27 16:18:43 +08:00
@fengleidongxi #30 这是信息时代的常识了,信息跟资本一样重要,所以你这样的问题就跟“为什么要拼命赚钱”一样的
|
33
iFlicker 2017-08-27 16:23:10 +08:00
6.0 之后 READ_PHONE_STATE 要动态申请
|
34
fengleidongxi 2017-08-27 16:30:46 +08:00
@honeycomb 谢谢
IOS 是否允许应用获取手机是否在通话? |
35
fengleidongxi 2017-08-27 16:39:26 +08:00
@woyaojizhu8 谢谢,不太懂这些
|
36
honeycomb 2017-08-27 16:53:18 +08:00
@fengleidongxi
自己查 iOS 的文档,我不知道 |
37
benmaowang 2017-08-27 22:01:15 +08:00
@honeycomb
据说 iOS 8 开始随机 MAC 机制的,但我用 iPhone 6s ( iOS 10 )尝试了下,并没有看到随机 MAC。 据说 Android 是从 6.0 开始随机化的,但我用 Nexus 6 ( AOSP 7.1.1 )尝试了下,也没有看到随机 MAC。 不过另一台国产安卓( 7.1.1 )确实是随机的。 Win10 “连接到新热点时,系统甚至会使用新的随机 MAC ” ?我觉得不太可能。每台设备占用的 MAC 是有限资源,是需要厂商购买的,在 Probe 时使用随机 MAC 还勉强说得过去,连接时使用随机 MAC 就不可能了。 |
38
honeycomb 2017-08-27 22:05:55 +08:00
@benmaowang
按照 win10 的 Wifi 设定自己的说法,应该是说它会忽略这个“每台设备占用的 MAC 是有限资源,是需要厂商购买的” |
39
honeycomb 2017-08-27 22:06:22 +08:00
@benmaowang
你用什么方法抓 probe 帧? |
40
benmaowang 2017-08-27 22:18:45 +08:00
@honeycomb 如果 Win10 真的那样做,那就是瞎搞,万一碰到相同 MAC 的情况就害人害己了。
无线抓包用 Macbook + Wireshark 或系统自带无线诊断软件就可以。顺便安利一下,请路过的各位同学注意! Macbook 是我用过的最方便的无线抓包工具! |
41
honeycomb 2017-08-27 22:30:22 +08:00
@benmaowang
是不是 macbook 不需要像 windows 那样专门安装额外的 NDIS 驱动? |
42
benmaowang 2017-08-27 22:43:46 +08:00 1
@honeycomb 不需要。装上 Wireshark 就能抓,如果要指定信道,需要用 airport 命令配合。如果使用系统自带的无线诊断工具抓,可以通过界面设定信道,抓到的数据是保存到文件的,也可以用 Wireshark 打开查看。
|
43
EmmaSwan OP 楼有点歪。
我发这楼其实是想讨论安卓“为什么允许应用获取网卡地址”,而不是“为什么安卓可以获取网卡地址” 连接 WIFI 并不是由应用负责的事情,在我看来是没有必要把相关信息给他的,除非授权他获取定位权限,那么由于网卡地址可以帮忙定位,这才说得通。 从实验来看,IOS 上,如果你未授权定位,那么应用无法获取周边 WIFI 的网卡地址,和你自身连接到的那个 WIFI 的网卡地址。但是安卓上,如果你未授权定位,仅仅是拒绝了获取周边 WIFI 的网卡地址,而你自身链接到的那个 WIFI 的网卡地址,依旧被获取。所以依旧可以定位。我的疑惑就恰恰是,为什么默许应用获取这么关键的信息,而这个信息对它又没有什么用处。 楼上有些同学似乎是没有看到我主楼的实验描述,在我修改了路由器网卡地址后,这些应用就无法实现定位了。所以,显然,这个实验中,定位就是通过手机实际连接上的那个 WIFI 的路由器网卡地址来实现的。和周边其他 WIFI 没有任何关联。或许也能佐证,在未授权定位的情况下,安卓应用是无法获取周边 WIFI 信息的。 |
45
liulcq 2017-08-28 08:54:15 +08:00
所以说还是 WIN10 给力, 可以让自己的网卡 MAC 随机化,每天随机、每链接随机还是按热点随机都可以设置。这样就不会存在 MAC 随机的时候冲突问题了
@benmaowang |
46
benmaowang 2017-08-28 09:03:53 +08:00
@liulcq 怎么会不存在?只要随机就有可能会冲突,只是机率小而已。况且,别人花钱买的地址段,凭什么给你随机用,除非微软自己买一段在里面怎么随机都行。
|
47
honeycomb 2017-08-28 09:11:06 +08:00 1
@EmmaSwan WifiManager 不需要任何运行时权限就可以获取当前连接的网络的 WifiInfo,后者有 getSSID,getBSSID 函数就能导出来了,这是不合理的。
|
49
greenskinmonster 2017-08-28 09:58:24 +08:00
@EmmaSwan 换个角度想问题吧,没必要凡事都指望谷歌。你可以停在 6.0,装 XPrivacy。7.0 版本上 XPrivacy 能不能正常工作我不太确定。也可以呼吁下有没有跟你一样有隐私意识的去 patch AOSP,或者是 LOS。开源的意义不就在这嘛。
另外未 root 的话,至少 7.0 系统,App Ops 也可以来限制应用的权限,只是需要 ADB 命令来配合,有点麻烦,每次重启还要再做。 https://play.google.com/store/apps/details?id=rikka.appops 你要想最高程度的隐私,那么你就需要一个最大程度上你可以支配的系统。 谷歌确实没提供这样的系统,但是谷歌也没阻止你去获得这样的系统,大多数东西都在 Google Play 上。 你改变不了谷歌,就改变自己呗。 |
50
honeycomb 2017-08-28 10:08:48 +08:00
@EmmaSwan
就这个(获得已经连接的 wifi 的信息)问题来说: "thanks.看来真是天残,谷歌一日不改,安卓就不存在隐私" iOS 有同样的问题 @greenskinmonster AppOps 从 Android 4.3 开始就存在了 6.0 出现的变化是: 1:增加了 adb 的接口 2:对应与 6.0 的运行时权限所需的新增的一些 OP(如 OP_READ_PHONE_STATE) |
51
greenskinmonster 2017-08-28 10:22:50 +08:00
@honeycomb 没太明白你想表达啥。
AppOps 这个只是个例子,完全可以根据自己的需要去用其它软件实现。意思就是说,说服谷歌根据你的需求去改他们的系统,可能性微乎其微。谷歌的鸟脾气,有些明显的 bug 都几年不修呢。 但是你想获得更好的隐私保护,有很多其它的办法可以实现,这些是你可以控制的。 |
52
honeycomb 2017-08-28 10:37:54 +08:00
@greenskinmonster
是一个勘误,针对这句话 “另外未 root 的话,至少 7.0 系统,App Ops 也可以来限制应用的权限,只是需要 ADB 命令来配合 ” 再具体一些的补充 目前而言,AppOps 的作用大致上是运行时权限的一部分 backend(特别是针对旧 targetSDK 应用),以及一些非运行时权限,以及其它特性(如对 SDK26 以前的应用开启后台限制) |
54
greenskinmonster 2017-08-28 11:04:49 +08:00
@honeycomb 我说的是我链接中的那个 App Ops 软件的功能,而不是在讨论系统内置的 App Ops,所以我附了一个链接在那里,这两者不完全是一回事。
这个软件我在 7.0 未 root 三星系统测试过,对于非要 READ_PHONE_STATE 才肯运行的软件有用,应用只会得到空数据。 |
55
7654 2017-08-28 13:59:36 +08:00
谷歌是广告公司
|
56
skylancer 2017-08-28 15:18:25 +08:00
@greenskinmonster 这就是系统内置的 AppOps,完全就是一回事
|
57
honeycomb 2017-08-28 15:36:48 +08:00
@greenskinmonster
“我链接中的那个 App Ops 软件的功能” 目前有两个做得很棒的 appops wrapper,一个是你提到的 rikka appops,还有一个是开源的 appopsX rikka appops https://play.google.com/store/apps/details?id=rikka.appops 配合用的 shizuku api https://play.google.com/store/apps/details?id=moe.shizuku.privileged.api appopsx https://play.google.com/store/apps/details?id=com.zzzmode.appopsx https://github.com/8enet/AppOpsX 这两者说到底都是在用 AppOps “对于非要 READ_PHONE_STATE 才肯运行...应用只会得到空数据” 除了通过反射取 appops 以外,还有一个绕过方法,就是检测到非 null 时一律当作权限被阻止(有些银行的应用会这么做),绝大多数包括微信在内的流氓软件们都能用它治疗 |
58
greenskinmonster 2017-08-28 15:38:24 +08:00
@skylancer 表抬杠,可以认为这是利用系统 AppOps 来简化权限管理的一个工具,完全等同就不对了。比如这个软件可以设置个权限模板,新装的软件自动套用,系统的 AppOps 能做到吗?
|
59
skylancer 2017-08-28 15:40:16 +08:00
@greenskinmonster 你所给的这个工具只是系统 CLI 的前端 App 而已,简化了操作,实际上你这个 App 的任何操作均可以使用 adb 来完成
|
60
greenskinmonster 2017-08-28 15:56:37 +08:00
@skylancer 那不是把 chrome 跟 http 协议等同起来了吗?把 mplayer 和 mplayer frontend 也等同起来了么?感觉跑题有点远了。
|
61
skylancer 2017-08-28 15:57:32 +08:00
@greenskinmonster 实际就是这样,如果你不信,Google 大批这种 App 都是开源的,你可以自己看
|
62
honeycomb 2017-08-28 16:05:23 +08:00
所以你们准备用什么方法说服 Android 组给奥利奥加上关于热点的 MAC(BSSID)/SSID 的限制呢?
|
63
fengleidongxi 2017-08-28 16:51:21 +08:00
@honeycomb 除了通过反射取 appops 以外,还有一个绕过方法,就是检测到非 null 时一律当作权限被阻止(有些银行的应用会这么做),,,,,,,
这个怎么设置,能详细说说吗? |