[misc]智能車協議分析：2020網鼎杯青龍組misc_teslaaaaa_wp
文章目錄
teslaaaaa這道題是青龍組被做出來的題目中做出來人數最少的，直到比賽快結束纔有第一個人做出來，怎麼說，難並不是因爲腦洞大，講道理這道題是一道好題，我當時也是肝了一天沒做出來，我倒是把文件提取出來了，奈何比賽時間已經接近尾聲，而且腦子也是一團漿糊，沒有想到是刷的固件，還以爲是配置文件等等。怎麼說，還是太菜了。昨天看到看雪論壇的HHHso大佬發佈的wp，於是恍然大悟，自己復現一番。
拿到題目，解壓出來是一個.asc文件：
並沒接觸過這種類型，搜索了一番也沒搜到什麼，是一個文本文件，打開之後可以看到類似數據包的抓包日誌：
結合文件名ecu_can_log，通過搜索，可以確定這是個智能汽車can總線的抓包log。
首先了解一下can總線，can總線控制器局域網絡(Controller Area Network, CAN)的簡稱，也是智能汽車裏面的總線，智能汽車中各個部件、傳感器都會通過can總線鏈接到車輛的主控板（ECU）上組成一個局域網（對智能汽車不是很瞭解，簡單描述一下），我們只需要知道這個抓包log是來自智能汽車就可以了，那麼也要明白，這裏面的協議也是智能汽車中獨有的協議。
分析log文件格式
通過搜索，我們得到了這個log文件裏面的數據格式：
從左到右依次是：時間戳、CAN通道編號、幀ID（16進制）、幀方向（發送或接收）、d。之後跟的DLC、數據。我們只需要知道數據流向和數據內容即可：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-AEKbWdUo-1589599664736)(teslaaaa_wp.assets/image-20200515162832992.png)]
分析協議組成
接下來我們要分析數據報文究竟是什麼協議，根據我們搜索的內容和最後官方給的提示：UDS診斷協議（ISO 15765-2， ISO 14229-1），我們確定了協議內容爲UDS網絡傳輸層和UDS統一診斷服務（雖說官方提示前我就知道了是什麼協議，但並不影響我做不出來）。
這兩個協議的關係就類似傳輸層和應用層的關係，UDS網絡傳輸層協議在UDS統一診斷服務的外層，我們可以像分析網絡協議棧數據包一樣分析這個log文件。
UDS網絡傳輸層
關於UDS網絡傳輸層：ISO15765-2(UDS網絡傳輸層)
關於UDS網絡傳輸層不用知道太多，只需知道這個協議有兩種模式，分別爲單幀傳輸和多幀傳輸，協議內容很短，只需要看每條數據的第一個字節：
第一個字節的含義：
如02 10 02 AA AA AA AA AA這條數據就代表單幀(0)，數據長度2(2)，然後10 02就是協議的數據，後面的AA 都麼用。
如
Tx d 8 10 0D 31 01 FF 00 44 08
Rx d 8 30 08 00 00 00 00 00 00
Tx d 8 21 00 00 00 00 00 20 00
代表發送方要發送連續幀(1)，數據長度13(0 0D)，然後後面的6個是數據
然後接收方返回控制FC(3)，含義是繼續發送(0)，後面08是啥不用管，因爲我看這個數據包裏後面所有的繼續發送都是30 08 00 00…
然後發送方繼續發送連續幀(2)的第二幀(1)，後面是接首幀的內容。
這兩組例子差不多能概括這個數據包裏面所有的UDS網絡傳輸層報文了，這個數據包裏基本只有單幀和連續幀。
UDS統一診斷服務
接下來分析UDS統一診斷服務
關於UDS統一診斷服務也不用知道太多，我們只需要知道這個協議是測試人員向ECU（車輛主控板）上發送的協議，協議結構也非常簡單：
發送方（測試人員）發送：SID+具體數據
接收方（ECU）回覆：肯定：（SID+0x40這裏代表數學加法）+具體數據
否定：7F+SID+一字節NRC
協議也是很簡單，以下面的內容爲例：
Tx d 8 02 10 02 AA AA AA AA AA
Rx d 8 06 50 02 00 32 01 F4 00
發送方發送的內容爲（去掉外層UDS網絡傳輸層）：10 02，10代表協議SID爲10，對應的是診斷會話服務，可以看出這裏是診斷的開始，發送方發起診斷請求，02是對應的協議數據，可能是一些類別啥的，沒啥用，我們是要解題而不是完全掌握這個協議
然後返回方的內容爲（去掉外層UDS網絡傳輸層）：50 02 00 32 01 F4，這裏50代表的就是對之前發送方發起的10診斷服務的肯定（SID+0x40），後面的是數據吧，這裏不用管是啥，只需知道**請求放發起了診斷服務，ECU給予了確定的回覆。**這時單幀的情況，連續幀同理，比如：
Tx d 8 10 0D 31 01 FF 00 44 08
Rx d 8 30 08 00 00 00 00 00 00
Tx d 8 21 00 00 00 00 00 20 00
Rx d 8 05 71 01 FF 00 00 00 00
發送方發送請求內容（去掉外層UDS網絡傳輸層連續幀）：31 01 FF 00 44 08 00 00 00 00 00 20 00，請求的服務是0x31例行程序控制，協議數據01位啓動程序，FF 00爲擦除數據（一般用於請求APP數據下載（34服務）之前，這也和後文34服務照應上了），擦除地址爲0x8000000 。
接收方返回內容爲（去掉外層UDS網絡傳輸層連續幀）：71 01 FF 00 0071代表肯定回覆（0x31+0x40），然後01和之前請求保持相同，FF 00 00代表擦除成功？？不太確定猜的。
附：在知乎上找到一個大佬，較爲詳細的講解了大部分的服務：
https://www.zhihu.com/people/zoe-white/posts
或者百度“UDS診斷之XX服務”
協議分析
Tx d 8 02 10 02 AA AA AA AA AA 10服務 診斷會話控制
Rx d 8 06 50 02 00 32 01 F4 00 請求成功
Tx d 8 02 27 05 AA AA AA AA AA 27服務 安全訪問-5
Rx d 8 06 67 05 11 22 33 44 00 請求成功，返回祕鑰
Tx d 8 06 27 06 EE DD CC BB AA 27服務 安全訪問-6，計算祕鑰返回結果
Rx d 8 02 67 06 00 00 00 00 00 結果校驗無誤，通過安全校驗
Tx d 8 10 0D 31 01 FF 00 44 08 31服務 例行程序控制，擦除數據0x8000000
Rx d 8 30 08 00 00 00 00 00 00 繼續發送
Tx d 8 21 00 00 00 00 00 20 00 31服務 例行程序控制接上文，擦除數據0x8000000
Rx d 8 05 71 01 FF 00 00 00 00 擦除成功
Tx d 8 10 0B 34 00 44 08 00 00 34服務 請求下載，下載到0x8000000
Rx d 8 30 08 00 00 00 00 00 00 繼續發送
Tx d 8 21 00 00 00 20 00 AA AA 34服務 請求下載接上文，下載到0x8000000
Rx d 8 04 74 20 01 02 00 00 00 成功，接受下載請求
Tx d 8 10 82 36 01 28 04 00 20 36服務 開啓數據傳輸，長度0x82，第一次傳輸
Rx d 8 30 08 00 00 00 00 00 00 繼續發送
Tx d 8 21 45 01 00 08 21 03 00 接下來是持續發送數據直到發送結束（編號21-2f之後從21
Tx d 8 22 08 23 03 00 08 27 03 重新開始）
Tx d 8 23 00 08 2B 03 00 08 2F
··· ··· ··· ···
Tx d 8 22 08 5F 01 00 08 AA AA 第一次數據傳輸結束
Rx d 8 03 7F 36 78 00 00 00 00 返回阻塞？？這裏不用管，因爲下一個數據包就是成功返回
Rx d 8 02 76 01 00 00 00 00 00 第一次數據傳輸成功
Tx d 8 10 82 36 02 5F 01 00 08 第二次數據傳輸開始，長度還是0x82,下面相同
Rx d 8 30 08 00 00 00 00 00 00 繼續發送
Tx d 8 21 5F 01 00 08 5F 01 00
··· 一共傳輸了0x40次 ···
Rx d 8 02 76 40 00 00 00 00 00 最後一次傳輸成功
Tx d 8 02 37 01 AA AA AA AA AA 37服務 傳輸結束
Rx d 8 06 77 01 C6 B6 5E 10 00 傳輸結束成功
Tx d 8 04 31 01 DF FF AA AA AA 31服務 例行程序控制，一些操作
Rx d 8 03 7F 31 78 00 00 00 00 阻塞（不用管，下面就成功了）
Rx d 8 05 71 01 DF FF 00 00 00 成功
Tx d 8 04 31 01 FF 01 AA AA AA 31服務 例行程序控制，執行剛剛傳輸的東西
Rx d 8 05 71 01 FF 01 00 00 00 成功
Tx d 8 02 11 01 AA AA AA AA AA 11服務 ECU復位，重啓ECU
Rx d 8 03 7F 11 78 00 00 00 00 阻塞（不用管，下面就成功了）
Rx d 8 02 51 01 00 00 00 00 00 成功
Tx d 8 02 3E 80 00 00 00 00 00 3E服務 回話保持心跳包
Tx d 8 02 3E 80 00 00 00 00 00 3E服務 回話保持心跳包
這時賽後進行的完整分析，在比賽的時候我沒對每個服務的內容進行詳細分析，導致不知道傳輸的數據後來被執行了。這個31服務的操作數特斯拉廠商自己規定的。
所以我們可以看出整個數據報文就是，先進行例行的身份認證，然後擦出了單板上0x8000000內存區域的數據，然後向這塊區域下載了一個文件並執行。
文件提取
那麼根據我們之前分析的內容，我們把下載相關的報文提取出來。
根據協議，這些東西就是傳輸的內容，所以我們先把整個log文件“掐頭去尾”，只剩下0x40次日誌傳輸相關報文，然後將所有RX的返回報文去掉（直接批量搜索刪除即可），類似下面這樣：
正則語法：.*Rx.*\n
中間還有一行這個，別忘記刪掉：
然後對得出來的結果執行下面的代碼，提取出傳輸數據的值（ascii形式）：
f = open('ecu_can_log.asc', 'r')
f1 = open('result.txt', 'w')
list1 = f.readlines()
data=[]
count=1
for i in list1:
if(count%19==0): #19行是數據傳輸的最後一行，後面有兩個AA是不要的
data=i[43:57]
elif(count%19==1): #每次傳輸的第一行要去掉傳輸協議頭
data=i[52:63]
else:
data=i[43:63] #其他中間傳輸的報文，直接去掉UDS網絡層即可
f1.write(data+' ')
count+=1
得到的結果差不多是這樣：
最開始我還以爲是什麼壓縮文件或者圖片啥的，還在找這個文件頭，發現不認識這個文件頭，而且binwalk直接跑也沒結果。。。。唉。
然後我們需要把這個文件轉化爲二進制形式，通過如下腳本實現：
f = open('result.txt', 'r')
f1 = open('result', 'w')
strings=f.read()
i=0
while(i<len(strings)):
data=int(strings[i:i+2],16)
f1.write(chr(data))
i+=3
輸出了二進制文件之後通過strings可以發現裏面有個flag：
提交發現並不是對的。。。。。
當時爲什麼就沒有想到是個二進制文件呢，好後悔，賽後覆盤的時候隊內大佬也再說是不是arm的可執行文件啥的。我才恍然大悟，再加上後來看到看雪的wp。
文件逆向
題目給的圖片也是一個提示，圖片上可以看到單板是arm的：
然後通過IDA打開它，arm小端，加載到內存0x8000000地址處：
然後將彙編模式改爲thumb，按alt+G，將T值設爲1即可。
接下來按C便可以反彙編了：
主要函數：
計算flag：
flag計算
直接將上述代碼拷貝到python上執行一遍：
temp="canoecr7-zd9h-1emi-or8m-f8vm2od81nfk"
v1=[]
j=0
for i in temp:
v1.append(ord(i))
j+=1
v1[2] -= 13
v1[11] -= 5
v1[15] -= 44
v1[3] -= 11
v1[5] -= 48
v1[7] += 43
v1[28] += 50
v1[31] += 46
v1[19] -= 13
v1[20] -= 66
v1[1] += 3
v1[29] -= 55
v1[24] -= 51
v1[9] -= 23
v1[25] -= 6
v1[27] -= 60
v1[4] -= 52
v1[6] -= 14
v1[30] -= 52
v1[22] -= 58
v1[12] -= 48
v1[16] -= 56
v1[34] -= 53
v1[0]-= 48
v1[14] += 3
v1[17] -= 5
v1[33] -= 55
v1[35] -= 56
v1[10] -= 2
v1[26] -= 67
flag="flag{"
for i in v1:
flag+=chr(i)
flag+='}'
print flag
flag爲：flag{3dad13db-cb48-495d-b083-3231d80f1713}
這道題真的是一道很好的題目，之前都沒接觸過智能汽車協議分析等相關的東西，學習了很多。