計客藍牙魔方協議逆向分析
前言
本文大致記錄了一個，對于藍牙魔方中的協議逆向分析的步驟。
去年年初的時候，對藍牙有一點兒興趣，搞了搞ubertooth one（好像是叫這個名字？進不清楚了），用來嗅探藍牙數據的，然后順手又買了一個計客的魔方，帶藍牙功能的，簡單來說就是基于藍牙和手機的數據傳輸，將魔方的狀態輸出到手機上，以此來實現一些好玩的小功能的（誒再說下去感覺像是在打廣告了）
這個其實沒啥太多干貨，甚至沒有知識點，總的來說，僅僅是記錄一個，處理問題接近問題的思路，具體關于擰動魔方的方向，這里也不提了，回頭帶一個魔方入門教程在結尾的參考中吧。
基礎邏輯推理分析
在著手分析之前，其實需要搞明白一個問題，這個玩具，它是怎么通過和手機建立藍牙連接后，將自己的狀態同步到手機上的。
首先，它內部一定是存在感應器來獲取魔方轉動的情況的，這里的問題是，它給到手機的數據，是什么樣子的，理論上只有兩種方式
- 僅僅給出魔方轉動的方向情況，手機端接收到之后，自行進行計算。
- 每次轉動，都將整個魔方的狀態發送到手機上。
我之前覺著是第二種，因為考慮到藍牙也許會出現丟包或者數據包傳輸時的次序問題，所以這里不管怎么想，也都是每次同步狀態過去比較穩健的樣子。實際著手驗證的方式也非常簡單，連接手機后隨便轉動幾下，再斷開連接，連上另外一個設備，如果魔方狀態仍然被同步了，起碼說明，它是能存儲自身狀態的（老實說我在最初分析的時候就是這樣想的，但是現在回過頭來看，也許還是有點兒牽強吧，因為也存在每次連接同步狀態，后續僅僅發送轉動方向的可能性）
狀態獲取&信息收集
接下來的事情比較簡單，就是先通過電腦連接上魔方，這個比較簡單，代碼我也上git了
就是使用bleak的python庫，寫一點兒python就行了，我這里代碼寫的比較隨意，因為僅僅是分析和獲取協議信息，沒有進一步開發的打算（本來是有的。。但是沒啥時間了），可以拿到這樣的信息：
Connected: True
[Service] 180A: Device Information
[Characteristic] 2A29: (read) | Name: , Value: b'GiCube.Co.Ltd' 4769437562652e436f2e4c7464
[Service] 180F: Battery Service
[Characteristic] 2A19: (read,notify) | Name: , Value: b'7' 37
[Descriptor] 2902: (Handle: 15) | Value: b'\x00\x00' 0000[Service] AADB: Unknown
[Characteristic] AADC: (read,notify) | Name: , Value: b'\x124Vx3333\x124Vx\x9a\xbc\x00\x00a\x13a\x13' 1234567833333333123456789abc000061136113 這個大概率是魔方狀態
[Descriptor] 2902: (Handle: 19) | Value: b'\x00\x00' 0000[Service] AAAA: Unknown
[Characteristic] AAAB: (notify) | Name: , Value: None
[Descriptor] 2902: (Handle: 23) | Value: b'\x00\x00' 0000
[Characteristic] AAAC: (write-without-response) | Name: , Value: None
[Service] 00001530-1212-EFDE-1523-785FEABCD123: Unknown
[Characteristic] 00001532-1212-EFDE-1523-785FEABCD123: (write-without-response) | Name: , Value: None
[Characteristic] 00001531-1212-EFDE-1523-785FEABCD123: (write,notify) | Name: , Value: None
[Descriptor] 2902: (Handle: 31) | Value: b'\x00\x00' 0000
[Characteristic] 00001534-1212-EFDE-1523-785FEABCD123: (read) | Name: , Value: b'\x01\x00' 0100
藍牙協議我其實不怎么熟悉，就是隨便看了看，簡單提一下，其實可以吧藍牙設備抽象成一個類，它提供各種各樣的服務，也就是一些成員變量或者函數，用的時候，去調用相關服務獲取信息就行了。這里能看到一個比較可疑的Characteristic：AADC，因為它帶的數據量看起來最大，符合我前面說的“每一次通信包含整個魔方狀態”的推論，因此這里進一步進行一些轉動，收集到了一些數據。
需要注意的是，從一個協議角度來理解整個魔方轉動狀態的時候，毫無疑問的是，魔方的中軸一定是不動的，也就是說，保持一個方向，不會對整個魔方進行轉體之類的操作。
這里整體以藍色為頂，橙色為前
復原狀態： 1234 5678 3333 3333 1234 5678 9abc 0000 6113 6113 最上面那層 順時針擰一下 即 U 1234 8567 3333 3333 1234 5678 c9ab 0000 1161 1311 1234 7856 3333 3333 1234 5678 bc9a 0000 1111 6113 1234 6785 3333 3333 1234 5678 abc9 0000 1111 1161 1234 5678 3333 3333 1234 5678 9abc 0000 1111 1111 最右 R 1624 5738 3223 3223 1264 5b38 9a7c 2620 4111 1111 1764 5328 3333 3333 12b4 5768 9a3c 0000 4141 1111 1374 5268 3223 3223 1274 53b8 9a6c 2620 4141 4111 1234 5678 3333 3333 1234 5678 9abc 0000 4141 4141 最下面一層 擰一下 D 4123 5678 3333 3333 4123 5678 9abc 0000 6363 6361 3412 5678 3333 3333 3412 5678 9abc 0000 6363 6363 2341 5678 3333 3333 2341 5678 9abc 0000 6363 6363 1234 5678 3333 3333 1234 5678 9abc 0000 6363 6363 最前面一層 F 1273 5684 3311 3311 1237 56c4 9ab8 0000 3163 6363 1287 5643 3333 3333 123c 5687 9ab4 0000 3131 6363 1248 5637 3311 3311 1238 564c 9ab7 0000 3131 3163 1234 5678 3333 3333 1234 5678 9abc 0000 3131 3131
拿到了這些信息的樣子，接下來進行進一步的分析
協議信息分析
首先，在魔方復原狀態下，出現了很多很規律的數據，例如
1-8位的數據是 1234 5678 17-28位的數據是 1234 5678 9abc
首先魔方的每一塊顏色都不一樣（這里指三維狀態下的塊），因此，肯定是需要使用不同的代碼來標示不同的塊的，因此這兩段數據，有很大的可能，是代指各個塊，魔方的角塊有8個，而棱塊有12個，正好對應上了這兩組數據。（誒這里就一句話就吧最關鍵的塊數據情況描述出來了，我當時看其實看了老半天。。）
這里再放一張圖來說說啥是角塊啥是棱塊吧：
然后這里使用了一些常見的魔方公式，比如說PLL中的三棱塊對調：
獲取到了這樣的數據：
對換藍色層的棱塊 對換前 1234 5678 3333 3333 1234 5678 9abc 0000 3331 6361 后 1234 5678 3333 3333 1234 5678 bc9a 0000 2143 2143
可以看到， 9abc 變成了 bc9a，總的來說就是通過這類的變換，最后獲取到了每一個編碼對應的魔方的塊：
棱塊： 綠黃 1 綠紅 2 綠白 3 橙綠 4 紅黃 5 紅白 6 橙白 7 橙黃 8 藍黃 9 藍紅 a 藍白 b 橙藍 c 角塊： 黃綠紅 1 紅綠白 2 白橙綠 3 黃綠橙 4 黃藍紅 5 紅藍白 6 白橙藍 7 黃藍橙 8
這樣，整個塊的編碼就清楚了，接下來還有一個問題也迎刃而解了，就是，角塊和棱塊后面對應的數據分別是什么。后續我又進行了一些轉動，簡單推理得出，3333 3333 這段數據，就是對應每一個棱塊的朝向，因為他們僅僅只有1/2/3 三種數字出現，而棱塊只有兩個朝向，因此使用二進制數據標示 000 三個十六進制數字，轉換成二進制正好是12個0，這樣就說得通的，具體如下：
1234 5678 3333 3333 1234 5678 9abc 0000 3331 6361 A B C D E F G H I J 棱塊：EFG坐標 H 前三個數字的二進制為朝向 角塊：AB坐標 CD朝向
block之后的發散思路
老實說分析到上面那一步之后，我就整個block住了，因為我實在是不太明白其中朝向的和這串數據到底有什么關系。。當時一直念叨著，朝向朝向朝向的，突然想到，整個魔方協議的設計思路，和魔方的一個項目，有很強的關系—-盲擰。誒早年在南昌WCA的時候，看過兩個鐘頭盲39個三階的巨佬，太強了，算了不扯遠了，說回盲擰的事情。我并不會盲擰，但是早些年玩魔方的時候，有一些玩魔方的朋友會這玩意，簡單和他們聊過，總體來說就是，通過記憶魔方的編碼情況，然后通過一系列比較特殊的，對整個魔方狀態改動比較小的公式（我可能不太能描述清楚這個概念，大致意思就是，在交換一些使用者期望交換的塊之后，其他塊盡可能的保持不變），魔方盲擰的編碼方式種類也比較多，
這里僅僅看編碼的部分就好了，整體思路非常接近，唯一有一點點區別的是，棱塊的朝向在這個編碼中不是1/2/3，而是0/1/2，且棱塊的高/中/低級面，和角塊的高/中/低級面，并不相同。
棱塊： 高級色 橙色 紅色 中級色 白色 黃色 低級色 藍色 綠色 角塊： 高級色 藍色 綠色 中級色 橙色 紅色 低級色 白色 黃色
這里在分析和最后代碼實現其實也花了很多時間，不過本身僅僅是一些業務邏輯，不涉及問題分析，這里就不記了，回頭看看代碼吧。
總結
總的來說就只是一個，逆向的分析思路吧，其實挺簡單的
- 邏輯分析推理 （如果我來整這玩意，咋樣能合適一點兒）
- 信息收集 （收集一批數據看看，是不是和猜想一樣的）
- 思路發散 （如果真的分析不動了，找找資料看看也沒有類似的玩意）
