翻译：360代码卫士
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
概述
本文作者表示自己在Whereami工作时对苹果公司的位置服务如何运作很感兴趣。以下是作者对如何逆向位置服务协议的描述。
由于Little Snitch一直拦截locationd，因此我了解到该协议是通过locationd处理的。由于macOS目前具有系统完整性保护 (SIP) 功能，因此通过proxychains检查流量的普通方式不起作用了。另外一种方法就是将Charles设置为iOS设备的中间人代理。看到多数是由设备背景连线通信产生的流量，于是我得到了想要的东西即一个位置服务请求。
位置服务请求
这个请求本身只是application/x-www-form-urlencode以及一些二进制数据。
POST /clls/wloc HTTP/1.1
Host: gs-loc.apple.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 97
Proxy-Connection: keep-alive
Accept: */*
User-Agent: locationd/1756.1.15 CFNetwork/711.5.6 Darwin/14.0.0
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
00000000: 00 01 00 05 65 6e 5f 55 53 00 13 63 6f 6d 2e 61 ....en_US..com.a
00000010: 70 70 6c 65 2e 6c 6f 63 61 74 69 6f 6e 64 00 0c pple.locationd..
00000020: 38 2e 34 2e 31 2e 31 32 48 33 32 31 00 00 00 01 8.4.1.12H321....
00000030: 00 00 00 2d 12 13 0a 11 62 34 3a 35 64 3a 35 30 ...-....b4:5d:50
00000040: 3a 39 34 3a 33 39 3a 62 33 12 12 0a 10 39 38 3a :94:39:b3....98:
00000050: 31 3a 61 37 3a 65 36 3a 38 35 3a 37 30 18 00 20 1:a7:e6:85:70..
00000060: 64 d由于数据并不具有gzip头部0x1f8b，我猜应该是PB (protocol buffer)。毕竟它现在风光无限且备受众多很酷的小伙伴推崇。我们试着解码一下。
$ xxd -r request.hex | protoc --decode_raw
Failed to parse input.不起作用，可能是因为请求里面存在多余的东西。按逻辑来说这些mac地址应该是数据的一部分。我们试着来解码一下这些地址，如下十六进制转储中的蓝色部分所示：
还是不行。顶部看起来就像是一个头部。我们试着删除头部看看。
还是不行。
多次尝试未果之后，我决定通过从开头把字节一个一个地删除的暴力方法来看看能否解码。稍微改进的脚本版本如下。
运行之后发现三个匹配似乎是误报。虽然有输出但有些数据时乱码。第四个看似是合法的。
看似我原来的想法非常接近真相了。黄色部分是被删掉的字节。蓝色部分是成功被解码的PB信息。
也就是说请求信息由四种不同类型的数据组成。在PB术语中，每种数据类型都被称作一个标签。那么这条信息就有四个标签。
1是包含一个mac地址的字符串，基本上跟一个无线路由器mac地址差不多。
2是包含1作为值的内嵌信息，将其看做一个结构或对象即可。
3 和 4都是整数。我不知道它们的含义是什么，可能是说路由器最近一次出现的年份或者是信号噪音比。
为了验证这些假设，我们试着通过不同的mac地址提出一个请求。我通过一个十六进制编辑器来编辑二进制请求文件并通过curl命令提出一个POST请求。
$ curl https://gs-loc.apple.com/clls/wloc --include --request POST --data-binary @request2.bin
HTTP/1.1 400 Bad Request
Date: Sun, 07 May 2017 06:26:06 GMT
Cneonction: Close
Content-Type: text/plain
X-RID: 62904d6c-fe93-47d5-b579-548f9c83297c
Content-Length: 11
Bad Request还是不行。为什么会出现问题呢？
从转储中我们可看出信息现在是1个字节的长度，那么某个地方可能是一个校验和。这一点显而易见。0x2d的小数有效位数是45，而原始信息是45字节长。新的信息是46字节长，那么转换成十六进制应该是0x2e。我猜变量是一个32位的整数即0x002e。
$ curl https://gs-loc.apple.com/clls/wloc --include --request POST --data-binary @request3.bin
HTTP/1.1 200 OK
X-RID: bb3cc16a-6680-4019-b5d0-fb52e8c8bd5a
Content-Type: text/plain
Content-Length: 4948成功了。现在我们就可以知道请求的格式了。
头部本身可进一步进行分割。
地址服务响应
响应本身非常大。
这次，我们还是用暴力笨办法，事实证明有效果。解码的输出大概是1400行长。
第一行有点让人困惑。18446744073709551615 等于 0xfffffffffffffff也就是最大的无符号64位值。这可能意味着mac地址并未发现。我不知道18446744055709551616即0xfffffffbcf1dcc00的情况如何。
余下的结果更清楚。
2-1 是mac地址
2-2-1 是纬度 135582881 * pow(10, -8) = 1.35544532
2-2-2是经度10399172128 * pow(10, -8) = 103.99172128
2-2-3 貌似是位置精确度，
2-21 很可能是无线信道。
我刚开始不解的是为什么会得到101个结果。后来想明白了，这说明成功的结果是100个。刚开始的两个是我发送的mac地址，其余的是跟我提交的地址临近的mac地址。
但为啥有100个结果呢？
我猜可能是苹果公司去掉了对客户的三边测量计算，它并没有为每个人做出昂贵的计算，而是提供了一些访问点和坐标。
如果其中至少有三个地址是客户可见的，那么核心位置就能够使用信号水平作为距离。当你拥有三个坐标以及它们离目标位置的距离后，你就能合理地计算出目标位置在哪里。
如下是请求位于新加坡樟宜的位置时返回的访问点位置服务。
拥有了周边数百个访问点的信息还省去了再次联系位置服务服务器的必要。只要核心位置拥有三个可见访问点的坐标，那么就能够准确地计算出目标位置在哪里。即使是在离线的情况下只要开启了wifi，一样可以找到准确位置。
如何为我所用？
你可以为不带用户空间核心位置支持的编程语言写支持，不过其实可以用更简单的办法实现这个诉求。其实可以写一下你自己的位置服务服务器，帮助定位app做出一些有创意的调试，这个会更有意思。
延伸阅读
Application à l’analyse des données de géolocalisation envoyées par un smartphone 这是一篇法语论文，来了没有一些.proto文件实例和Python代码，我就是从这里开始的。不过论文发表之时协议似乎已经发生变化了
Vulnerability Analysis and Countermeasures for WiFi-based Location Services and Application （《基于WiFi地理服务和应用程序的漏洞分析和应对方法》）可大体了解基于WiFi的定位是如何运作的。