欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

如何逆向苹果定位服务协议

来源:本站整理 作者:佚名 时间:2017-05-12 TAG: 我要投稿

本文作者表示自己在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地址应该是数据的一部分。我们试着来解码一下这些地址,如下十六进制转储中的蓝色部分所示:

还是不行。顶部看起来就像是一个头部。我们试着删除头部看看。

还是不行。
多次尝试未果之后,我决定通过从开头把字节一个一个地删除的暴力方法来看看能否解码。稍微改进的脚本版本如下。

protomower.sh

运行之后发现三个匹配似乎是误报。虽然有输出但有些数据时乱码。第四个看似是合法的。

看似我原来的想法非常接近真相了。黄色部分是被删掉的字节。蓝色部分是成功被解码的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

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载