破譯優利德旗艦萬用表UT181A通訊協議

新聞 08-29

UT181A是優利德門下旗艦級手持數字萬用表，主打數據記錄（Data Logging）功能，支持USB聯機通訊。基本評測可以看我以前發的文章。前文說到，其官方或第三方軟體功能有限，缺少最重要的導出功能。另外，數據傳輸的速度也比較慢。

所以，欲對其協議進行分析，方便擴展、改進、和其它設備（比如樹莓派）連接、等等。

本文的破解/破譯方法及結論應該適用於UT171系列；UT71系列也可以參考。對破譯其它聯機通訊的設備也有借鑒意義。

可行性分析

UT181A使用了Silicon Labs HID-to-UART介面模塊CP2110. 在操作系統里呈現為一個HID設備，這樣的好處是不用裝驅動。既然它最終表現為UART協議，應該比較容易重寫其通訊協議。其實UT71系列也是類似的方案（HID轉UART），只不過用的南京沁恆的模塊。

找了一個CP2110的代碼在Linux下試了下，可以對UT181A進行基本的連接設置。但因為會話層的協議未知，所以嘗試讀寫操作時沒反應。

為了得到會話的詳情，最直接和萬能的辦法是用USB Sniffer。試了一下Free USB Analyzer，可以看到一些數據，但不能解碼為UART層的數據。從USB到HID，再到UART，實際上是隔了兩層，需要層層剝殼，還是有點繁瑣。Free USB Analyzer的HID解碼，是解為鍵盤/滑鼠數據的；也許它的收費版可以解碼為UART。

圖：

用Free USB Analyzer截獲UT181A通訊

不過我還有另一條完全不同的思路，也許會更簡單。

API Hook

十幾年前，我用過這種方法對SCSI設備的通訊進行劫獲。這些設備的通訊軟體，通常會有一個通訊模塊（動態庫），提供諸如Send/Receive的API。所以，只要自己寫一個提供同樣API的動態庫取代原有的動態庫，但在每個API的實現上，還是轉到原動態庫上，就可以實現鉤子（Hook）的效果。這樣截獲的數據塊是應用層／會話層的，比數據鏈路層／驅動層的數據有更好的可讀性。同時，還可以根據API的調用順序，得到和設備的交互流程，比如:初始化時要進行哪些設置，通訊參數，等等。

查看UT181A軟體的目錄，果然有兩個這樣的動態庫。用dumpbin /exports查看其API，初步判斷應該只要替換SLABHIDtoUART.dll 就可以了。

圖：

UT181A使用的動態庫及API

從版本信息上，可以看到這個動態庫來自Silicon Labs。到其網站上找到了CP2110/4 的SDK，用SDK里的動態庫替換這兩個動態庫，64位版崩潰，換32位版，果然可以運行。

其實優利德使用的版本較老（2010年的1.4），SDK里的版本是2017年的6.7。其中，API數目由42增加到了58。不管怎樣，能跑。這樣就容易開展下一步的工作了。

圖：

CP211x SDK里的動態庫及API

有了SDK就有了頭文件，有頭文件就可以寫出八股文一樣的代碼了。弄兩行腳本，自動生成大部分苦力代碼。。

圖：

HookAPI實現代碼示意

很快，就有了一個「山寨」動態庫。

圖：

自己實現的SLABHIDtoUART.dll及API

正版的要改名；山寨版要記住它名字。——活都找它干。

圖：

HookAPI的文件名替換

弄好了，發現山寨版的比老正版的API都少了2個。能跑，就沒深究了，畢竟優利德的軟體不會用到所有API。

看看Log文件，API的調用一目了然。這樣，我們就有了一個堅實的基礎。

圖：

通過HookAPI截獲的API調用序列

CP211x SDK

發現CP211x的SDK里還提供了Linux版Library（-lslabhidtouart -lslabhiddevice）的源代碼及例子。

這兩個Library和Windows的SLABHIDtoUART.dll，SLABHIDDevice.dll對應。於是，重寫通訊協議就更容易了。對Makefile略做修改後，可以在Intel和ARM（樹莓派）架構下編譯、運行。

直接用SDK里的例子做個測試，發出第一條命令」AB CD 04 00 05 01 0A 00」後，就可以源源不斷地收到數據了。

圖：

CP211x SDK里例子和UT181A通訊

後續的工作就是根據API Hook的Log，給UT181A發不同的命令，研究其反應，搜集更多的數據，以便發現數據的模式（Pattern）。

協議解碼

起始碼、長度字

上圖中，通過觀察每個輸入/輸出的數據包，發現會間隔地出現」AB CD」。用這兩個位元組對包進行分隔後，數據看起來更有規律，然後可以看出接下來兩個位元組應該是包的長度。長度可以和起始字起到相互驗證/確認的作用。

圖：

基本的會話數據

結束碼/檢驗字

對收到的數據包與其實際意義進行初步的對應後，發現最後兩位元組是多餘的。推測應該是校驗字。在CRC在線計算網站上對包中的數據做CRC計算，發現與任何一種CRC編碼都不能匹配。

其實，對收到的數據，可以忽略這個校驗碼，因為USB協議保證了數據不會出錯，除非是軟體層發生了錯誤。但後來發現，對發送的命令，也多了兩個位元組。如果萬用表那端要對它收到的數據做校驗，主機端則必須生成校驗碼了。

下圖的命令中，帶有參數。9位元組長的包中有一個參數，13位元組長的包有2個參數。根據參數的變化，可以觀察出最後兩位元組的變化規律。觀察9位元組長的包，發現最後兩位元組是在參數上增加了0x11，但這顯然不能解釋13位元組長的包。進一步的分析發現，原來這個校驗就是最簡單的「校驗和」，即把前面的所有位元組（除起始碼」AB CD」外）相加。對於長達2258位元組的包也是這樣，只不過高位溢出忽略。