本文作者表示自己在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
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的定位是如何運作的。
| 
