本文作者表示自己在Whereami工作時(shí)對(duì)蘋果公司的位置服務(wù)如何運(yùn)作很感興趣。以下是作者對(duì)如何逆向位置服務(wù)協(xié)議的描述。
由于Little Snitch一直攔截locationd，因此我了解到該協(xié)議是通過locationd處理的。由于macOS目前具有系統(tǒng)完整性保護(hù) (SIP) 功能，因此通過proxychains檢查流量的普通方式不起作用了。另外一種方法就是將Charles設(shè)置為iOS設(shè)備的中間人代理。看到多數(shù)是由設(shè)備背景連線通信產(chǎn)生的流量，于是我得到了想要的東西即一個(gè)位置服務(wù)請(qǐng)求。
位置服務(wù)請(qǐng)求
這個(gè)請(qǐng)求本身只是application/x-www-form-urlencode以及一些二進(jìn)制數(shù)據(jù)。
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
由于數(shù)據(jù)并不具有g(shù)zip頭部0x1f8b，我猜應(yīng)該是PB (protocol buffer)。畢竟它現(xiàn)在風(fēng)光無限且備受眾多很酷的小伙伴推崇。我們?cè)囍獯a一下。
$ xxd -r request.hex | protoc --decode_raw
Failed to parse input.
不起作用，可能是因?yàn)檎?qǐng)求里面存在多余的東西。按邏輯來說這些mac地址應(yīng)該是數(shù)據(jù)的一部分。我們?cè)囍鴣斫獯a一下這些地址，如下十六進(jìn)制轉(zhuǎn)儲(chǔ)中的藍(lán)色部分所示：
還是不行。頂部看起來就像是一個(gè)頭部。我們?cè)囍鴦h除頭部看看。
還是不行。
多次嘗試未果之后，我決定通過從開頭把字節(jié)一個(gè)一個(gè)地刪除的暴力方法來看看能否解碼。稍微改進(jìn)的腳本版本如下。
protomower.sh
運(yùn)行之后發(fā)現(xiàn)三個(gè)匹配似乎是誤報(bào)。雖然有輸出但有些數(shù)據(jù)時(shí)亂碼。第四個(gè)看似是合法的。
看似我原來的想法非常接近真相了。黃色部分是被刪掉的字節(jié)。藍(lán)色部分是成功被解碼的PB信息。
也就是說請(qǐng)求信息由四種不同類型的數(shù)據(jù)組成。在PB術(shù)語中，每種數(shù)據(jù)類型都被稱作一個(gè)標(biāo)簽。那么這條信息就有四個(gè)標(biāo)簽。
1是包含一個(gè)mac地址的字符串，基本上跟一個(gè)無線路由器mac地址差不多。
2是包含1作為值的內(nèi)嵌信息，將其看做一個(gè)結(jié)構(gòu)或?qū)ο蠹纯伞?/span>
3 和 4都是整數(shù)。我不知道它們的含義是什么，可能是說路由器最近一次出現(xiàn)的年份或者是信號(hào)噪音比。
為了驗(yàn)證這些假設(shè)，我們?cè)囍ㄟ^不同的mac地址提出一個(gè)請(qǐng)求。我通過一個(gè)十六進(jìn)制編輯器來編輯二進(jìn)制請(qǐng)求文件并通過curl命令提出一個(gè)POST請(qǐng)求。
$ 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
還是不行。為什么會(huì)出現(xiàn)問題呢？
從轉(zhuǎn)儲(chǔ)中我們可看出信息現(xiàn)在是1個(gè)字節(jié)的長度，那么某個(gè)地方可能是一個(gè)校驗(yàn)和。這一點(diǎn)顯而易見。0x2d的小數(shù)有效位數(shù)是45，而原始信息是45字節(jié)長。新的信息是46字節(jié)長，那么轉(zhuǎn)換成十六進(jìn)制應(yīng)該是0x2e。我猜變量是一個(gè)32位的整數(shù)即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
成功了。現(xiàn)在我們就可以知道請(qǐng)求的格式了。
頭部本身可進(jìn)一步進(jìn)行分割。
地址服務(wù)響應(yīng)
響應(yīng)本身非常大。
這次，我們還是用暴力笨辦法，事實(shí)證明有效果。解碼的輸出大概是1400行長。
第一行有點(diǎn)讓人困惑。18446744073709551615 等于 0xfffffffffffffff也就是最大的無符號(hào)64位值。這可能意味著mac地址并未發(fā)現(xiàn)。我不知道18446744055709551616即0xfffffffbcf1dcc00的情況如何。
余下的結(jié)果更清楚。
2-1 是mac地址
2-2-1 是緯度 135582881 * pow(10, -8) = 1.35544532
2-2-2是經(jīng)度10399172128 * pow(10, -8) = 103.99172128
2-2-3 貌似是位置精確度，
2-21 很可能是無線信道。
我剛開始不解的是為什么會(huì)得到101個(gè)結(jié)果。后來想明白了，這說明成功的結(jié)果是100個(gè)。剛開始的兩個(gè)是我發(fā)送的mac地址，其余的是跟我提交的地址臨近的mac地址。
但為啥有100個(gè)結(jié)果呢？
我猜可能是蘋果公司去掉了對(duì)客戶的三邊測量計(jì)算，它并沒有為每個(gè)人做出昂貴的計(jì)算，而是提供了一些訪問點(diǎn)和坐標(biāo)。
如果其中至少有三個(gè)地址是客戶可見的，那么核心位置就能夠使用信號(hào)水平作為距離。當(dāng)你擁有三個(gè)坐標(biāo)以及它們離目標(biāo)位置的距離后，你就能合理地計(jì)算出目標(biāo)位置在哪里。
如下是請(qǐng)求位于新加坡樟宜的位置時(shí)返回的訪問點(diǎn)位置服務(wù)。
擁有了周邊數(shù)百個(gè)訪問點(diǎn)的信息還省去了再次聯(lián)系位置服務(wù)服務(wù)器的必要。只要核心位置擁有三個(gè)可見訪問點(diǎn)的坐標(biāo)，那么就能夠準(zhǔn)確地計(jì)算出目標(biāo)位置在哪里。即使是在離線的情況下只要開啟了wifi，一樣可以找到準(zhǔn)確位置。
如何為我所用？
你可以為不帶用戶空間核心位置支持的編程語言寫支持，不過其實(shí)可以用更簡單的辦法實(shí)現(xiàn)這個(gè)訴求。其實(shí)可以寫一下你自己的位置服務(wù)服務(wù)器，幫助定位app做出一些有創(chuàng)意的調(diào)試，這個(gè)會(huì)更有意思。
延伸閱讀
Application à l’analyse des données de géolocalisation envoyées par un smartphone 這是一篇法語論文，來了沒有一些.proto文件實(shí)例和Python代碼，我就是從這里開始的。不過論文發(fā)表之時(shí)協(xié)議似乎已經(jīng)發(fā)生變化了
Vulnerability Analysis and Countermeasures for WiFi-based Location Services and Application （《基于WiFi地理服務(wù)和應(yīng)用程序的漏洞分析和應(yīng)對(duì)方法》）可大體了解基于WiFi的定位是如何運(yùn)作的。
| 
