某印表機韌體更新校驗突破

漏洞復現

復現一下一些比賽的漏洞，學習一下，也方便之後打比賽。

某印表機可以通過篡改更新包實現惡意韌體上傳。

先拿到官方給的更新工具

看到是個exe，直接執行了會報錯，直接丟進binwalk，看到解出了一些東西，直接對MICE_ALL.fw進行分析

丟IDA裡全是亂碼，發現有gzip的壓縮頭，意識到韌體可能分塊了，繼續丟binwalk，能看到壓縮包，-e解出來發現還有四個包。

直接把simple.bin丟進IDA開始分析，搜尋firmware、fw、update、upgrade等字串去定位，裝置沒有shell，只能靜態分析。

大概如下

定義了一個header的結構體，從韌體包裡獲取0x18位元組的頭資訊存進header裡，從程式碼裡知道資訊包括偏移，檔案大小，長度，checksum，於是結合檔案頭來分析

先計算檔案長度

發現頭部有8CDEED倒序出現，確定了檔案長度的存放位置

發現檔案長度下面還有個8CDE69，與檔案長度十分相似，做個差0x8CDEED – 0x8CDE69 = 0x84

於是猜測此為偏移量(header長度)，檔案總長度，檔案資料長度，檔案頭長度

現在開始計算checksum，由於checksum的方法比較多，甚至有可能自己設計，所以得根據程式碼去分析，定位到程式碼

邏輯比較簡單，單純的將DATA每位相加，最後獲取一個總和。

可以用工具粗略判斷一下

也可以自己寫指令碼驗證

繼續分析程式碼，發現頭最開始的四個位元組代表的是這個塊的標識，決定這是什麼韌體，走什麼樣的解析

有明文意義的可以當做裝置和韌體型號，也有把廠商或者是工具的標籤寫在頭裡的。

現在包頭還有兩個四位的資訊意義未知

跟著邏輯找沒有找到關於這兩個地方的程式碼，可能需要一點猜測。

看到gzip包有欄位和他比較相似，

看了下gzip的檔案結構，發現這是時間戳，那麼這個地方就大概率是時間戳了。

最後一個地方，發現沒有對header進行校檢的操作，猜測有可能是對header進行校檢，用工具試了試

到這裡基本是分析完了，要注意的是他採取的是多個header校檢的方式，最外面的header校檢通過了以後，才開始校檢data的header，這個過程十分耗時，即使採用了最簡單的校檢和

格式如下

還遇到點小問題，直接用系統的gzip沒法還原壓縮包，得設定個壓縮等級，最後用python的Gzip函式，compresslevel引數0-9一個一個試過去，發現6壓縮出來的包與目標一致

每次改包+上傳至少得三四十分鐘，十分磨人，放兩張對比圖

原來的報錯頁面

改過的報錯頁面

到此分析完畢。