作者：Lightal @ PwnMonkey Security Lab
原文鏈接：https://bbs.pediy.com/thread-261679.htm

1．簡介

海康威視作為國際大廠，旗下如攝像頭等產品早就被無數人分析過了，通過google和github等可以找到很多分析記錄和分析工具。螢石是海康威視的一個子品牌，相比于海康威視，螢石的絕大部分產品側重于家用領域，本文將要分析的智能門鎖和網關就是螢石的產品。

之前果加門鎖的分析文章中，我們分析了門鎖和相關的app，這篇文章我們打算對門鎖配套的網關進行一些分析（真正原因是門鎖讓我們搞壞了，雖然海康又補發了一個，但型號沒對上）。剛剛看了看螢石的網上商城，最新的聯網門鎖已經沒有外置網關了，我們在2019年分析的智能門鎖還是有外置網關的款式，圖片如下：

門鎖和網關在拿到手之后，就已經是配對狀態，我們不需要進行額外的配對操作。海康螢石智能門鎖有一個配套使用的app，該app對服務端有證書校驗，所以直接抓包是行不通的，由于我們這里是網關分析，所以就不討論app的工作了，在本專題的后續文章中，還會遇到類似的問題，到那時我們在解決app的事。

2． 通信分析

按照正常思路，肯定是先抓包看一下網關與服務器的通信內容。這里我們通過交換機端口監控的方法抓取海康螢石網關的通信內容（用電腦開啟熱點，然后網關連到電腦的熱點上也可以實現抓包的目的），如下圖：

通過上圖中的通信內容，我們大體上可以分析出一些內容：

A. 網關上電之后，與litedev.ys7.com進行通信。

B. 與litedev.ys7.com通信中，獲取了另一個ip，即101.71.30.172。此后，終止了與litedev.ys7.com通信，并一直保持與101.71.30.172的tcp連接。

C. 通信內容看起來是加密的，通信內容中沒有很多直接可見的明文。

既然抓包獲取不了太多有用的信息，那么我們就要進一步研究網關固件是如何處理這些通信數據的。

3． 電路分析

這次并沒有像之前的果加智能門鎖那樣順利：螢石配套的app不能獲取固件的下載地址，在海康和螢石的官網仔細翻找，同樣沒有查到固件的下載地址。那么接下來我們需要先對電路進行一些分析，以找到固件提取和調試的方法。

3.1 主要芯片分析

我們首先來看一看網關電路板上用哪些芯片，尤其注意主控MCU的型號，以及有沒有外置的Flash芯片。電路板如下圖所示：

上圖中，最明顯的就是中間的MCU，仔細觀察可以確認品牌和型號為MEDIATEK MT7688AN，聯發科的芯片，先下載一份芯片手冊看一看，下載地址是：http://labs.mediatek.com/zh-cn/chipset/MT7688。

通過閱讀芯片手冊，可以找到關于Flash的部分內容：

上圖可以看到該芯片并沒有內置Flash，而是使用SPI通信的外置Flash，那么我們繼續在電路板上尋找Flash芯片。

在圖2-2中，MCU的上方是Winbond W9751G6KB芯片，該芯片是DDR2 SDRAM存儲器，簡單說就是斷電丟數據的內存，固件程序不可能在里面。在MCU的下方有兩個芯片，分別是PCM5100A和GD25Q127CSIG芯片， PCM5100A是個音頻立體聲DAC芯片，而GD25Q127CSIG芯片則是128M-bit的Flash芯片，我們要提取的固件文件應該就是在此Flash中。關于Flash中固件的提取方法，我們將在第4章中介紹。

3.2 電路接口分析

IoT設備在開發和測試過程中，都會使用JTAG、UART等接口用于輔助調試工作。在設備的發行版中，MCU的這些引腳是否與電路板上的接口接通就不一定了，這需要我們測試一下。

在MT7688AN的芯片手冊中，我們可以看到該芯片UART0接口和UART1接口。其中UART0接口在30和31引腳，如下圖：

上圖中，我們僅展示了UART0的位置，UART1可以自行查詢芯片手冊。如果海康螢石的網關沒有屏蔽對UART的輸入和輸出，那么通過這些UART也許可以實現一些操作。通過萬用表測量，可以確定芯片的UART是否被引出到了軟排線接口上，如下圖所示的。

為了接通軟排線接口，我們需要購買一段20pin的軟排線和轉接板，淘寶可以買到，樓下手機店可能也有，軟排線的尺寸間距我們在圖3-4已經測量出來了。此外，我們還需要一個USB轉TTL模塊才能將UART口連接到電腦上，該模塊用于調整USB電路和TTL電路的電平邏輯，軟排線+轉接板+USB轉TTL模塊的連接如下圖所示。

我們在實際操作中，發現軟排線的觸點位置經常虛接，暫無法確定海康螢石的軟排線接口是否需要特殊的軟排線才能連接，但這樣也勉強能用，后續我們會有更好的替代方法。

按照圖3-5方式連接好之后，在電腦的“設備管理器”選項卡中就會出現一個COM口，可以使用xShell、SecureCRT或者sscom等串口調試工具來讀取這個COM口上的通信數據，當使用xShell和SecureCRT的時候需要將連接方式選擇為串行接口。

到此為止，如果操作無誤，網關上電后，應該可以在串口調試工具中看到了類似下圖的輸出內容。

上圖中的輸出內容顯然是網關上電之后的輸出日志，待系統啟動完成之后，我們可以試著輸入一些內容，這時就會出現登陸嵌入式Linux系統的提示字符，但是登陸用戶和登陸密碼我們暫不知道。現在是時候去分析固件了。

4． 固件分析

4.1 固件提取

我們在3.1節提到固件應該存儲在電路板的Flash芯片中，要讀取Flash芯片，只需要將芯片連到編程器上即可。如果情況允許，燒錄夾是最優選擇，這樣我們就不需要將芯片焊下來了。不巧的是，燒錄夾有點粗，海康螢石的門鎖網關設計的很緊湊，燒錄夾夾不上去。所以我們只好用熱風槍和鑷子就可以把Flash吹下來了，如下圖所示：

如果沒有熱風槍，用電烙鐵也是可以的，注意手別抖就好。然后將摘下來的芯片放在編程器上。支持讀寫GD25Q127CSIG芯片的編程器有很多種，我們這里選擇一種較為實惠的MinPro100B，如下圖：

將編程器連接到電腦上，使用編程器配套的軟件，選擇相應的Flash芯片型號后即可提取芯片內容，提取完成后可以將讀出的內容保存成文件，并命名為OriginFirmware.bin。

4.2 固件結構分析

提取出固件之后，我們可以嘗試用binwalk對它進行分析，這里，我們直接用-Me參數提取固件內容，其中M參數表示遞歸提取：

根據binwalk的分析結果，我們可以判斷固件應該包含一個嵌入式Linux操作系統，智能網關的主要功能邏輯應該由文件系統中的可執行程序完成。待binwalk運行完畢之后，會生成幾個文件夾，分別是2個squashfs文件系統，2個LZMA壓縮的數據，以及1個jffs2文件系統，如下圖所示：

上圖中，前2個文件夾即2個LZMA壓縮的數據，解壓之后會發現是cpio文件系統，binwalk會自動幫我們遞歸全部提取。

逐個瀏覽這些文件系統中的內容，可以得到以下信息：

A. jffs2文件系統保存著門鎖和網關的相關信息，如id等；

B. 兩個cpio文件系統中，其中一個應該是恢復出廠設置時的備份文件系統，另一個是當前正在使用的文件系統；

C. 兩個squashfs文件系統中，一個保存的全部都是mp3文件，另一個保存著網關的主程序，該程序即為我們將要分析的主程序。

D. 在固件的cpio文件系統中，可以找到/etc/shadow文件，文件內容如下：

借助于彩虹表，就可以找到root用戶的登陸密碼為abc123。使用該用戶名，就可以通過串口順利登陸海康螢石的智能網關，并使用串口shell提供的各種功能了。

4.3 固件重打包

我們現在已經拿到了固件內容，但是在對主程序進行分析之前，我們還需要處理一個串口總是虛接的問題，調著程序唱著歌，突然就被麻匪劫了（劃掉），串口斷開連接了，也是一件很惱火的事情。

在海康螢石的網關固件中翻一翻，可以發現在/sbin目錄中有telnetd程序，如果我們可以通過telnet連接智能網關，或許會穩定很多，如下圖所示：

該程序是指向busybox的軟鏈接，如果把解壓縮出的固件內容拿到windows環境后，可能會導致/sbin目錄中是空的。我們可以使用串口shell登陸設備，然后運行telnetd程序，但這就意味著每次設備重啟之后，我們都要使用shell啟動telnetd程序，這樣操作很麻煩。

繼續翻找，我們在squashfs文件系統中找到initrun.sh腳本，這個腳本是在網關上電啟動后進行初始化操作的。如果我們在該腳本中啟動telnetd，然后將固件重新打包燒錄回去，這樣應該就不需要軟排線連接設備了，為此我們給initrun.sh增加telnetd命令，如下圖：

接下來，就要考慮如何將固件重新打包，然后刷回至Flash中了。固件解包時，只要binwalk跑一下就完事了，但是重打包就相對麻煩一些。我們剛剛修改了initrun.sh文件，該文件在squashfs文件系統中，所以就需要重新打包squashfs文件系統，但mksquashfs在打包時，有很多細節的參數和配置，這些參數和配置將直接影響到我們重打包的系統是否可以正常運行，而且有些設備只能識別特定版本的mksquashfs打包出來的固件。

為解決squashfs文件系統打包的問題，我們最好參考一下MT7688AN的官方SDK。假設海康螢石的開發者基于該SDK的進行開發的，那么我們也根據SDK中的固件打包方法進行操作，得到的固件應該就是可運行的。首先在官網上下載MT7688 SDK，鏈接如下：http://labs.mediatek.com/zh-cn/platform/linkit-smart-7688。

在下載到的SDK文件中，我們可以在include文件夾中找到image.mk文件，在該文件中可以找到打包squashfs文件系統時的命令和參數，如下圖所示：

同時，在‘staging_dir\host\bin’目錄中可以找到圖4-8 中的mksquashfs4程序.

我們嘗試用SDK中的mksquashfs4程序和圖4-8中的參數打包一下開啟了telnetd程序的squashfs文件系統，如下圖所示：

上圖中，-comp xz是選擇xz壓縮格式，通過binwalk可以直接查看到原固件中的壓縮格式，所以我們也選擇該壓縮格式。

最后，將打包后的文件系統重新放回固件文件中。我們用了一個頗為簡單粗暴的方法，即用UltraEdit直接16進制編輯。4.2節中binwalk分析結果顯示從地址0x700000開始的位置是squashfs文件系統的位置，我們只需要將重新打包的squashfs文件覆蓋到此處即可。需要注意的是固件文件從地址0x900000起始就是另一個squashfs文件系統了，所以，覆蓋完成后需要調整兩個文件系統之間的填充字節數量以保證另一個squashfs文件系統的起始偏移仍然是0x900000。至此，我們完成了重打包工作。

重打包完成之后，還需要將打包的固件燒錄到Flash中去。燒錄和提取是類似的操作，使用編程器就可以完成，操作過程我們就不再贅述了。

5． 主要程序分析

按照4.3的方式重打包并燒錄固件后，我們應該已經可以通過telnet連接到螢石的網關上了。telnet連上后執行“ps”指令，通過簡單的排除法，就可以確定我們要分析主程序是：“/dav/davinci”（達芬奇？達文西？）。接下來我們就對這個程序以及部分它調用的動態庫進行分析。

5.1 靜態分析

我們首先靜態看一下davinci文件，通過代碼可以看到這個程序是有運行日志的，只是把不重要的日志屏蔽了(debug、verbose等)，只輸出了較為嚴重的日志內容(fatal、error等)。那么我們修改幾條指令，使其跳過對日志嚴重程度的判斷，如下圖：

除了要patch日志輸出代碼之外，davinci在啟動之后，初始化了一個線程操作看門狗，該線程會不斷向/dev/watchdog進行寫操作。如果一段時間內/dev/watchdog沒有收到任何數據，那么整個設備就會重啟。由于我們計劃調試davinci程序，如果在調試過程中，觸發斷點導致看門狗線程掛起，那么整個系統就會重啟。為此，我們先把該線程patch掉，然后再弄一個寫入/dev/watchdog的小腳本，用以專門喂狗防止重啟。相關位置的代碼截圖如下：

喂狗的小腳本內容如下：

相信腳本內容一眼就能夠看懂，所以我們不做太多的解釋了。此外，還有個guard.sh是用于檢測davinci程序是否運行的，但它不影響我們的操作，所以就不討論該腳本了，有興趣的讀者可以去看看。

完成上述操作之后，就可以把被patch的davinci上傳至海康螢石的智能網關，此處我們不再采用燒錄固件的方法，因為過于麻煩。通過翻閱該設備的文件系統，可以在設備中發現tftp程序，這是一個使用tftp協議傳輸文件的程序，可以用它從tftpd服務器上傳或下載文件。我們使用從這個鏈接下載到的tftpd程序：http://tftpd32.jounin.net/tftpd64_download.html ，運行后，調整tftpd服務器的文件目錄和監聽網卡。然后在智能網關設備中使用tftp程序獲取相關文件即可，相關命令截圖如下：

待相關文件傳輸到螢石網關中之后，就可以運行FeedWatchdog.sh腳本開始喂狗，然后終止原本的davinci進程，接著刪除/home/pidfile文件，該文件相當于互斥體，用于控制davinci僅運行了一次，最后啟動我們自己的davinci_1進程，相關命令如下：

待程序運行一段時間之后，就可以查看程序的運行日志，然后通過日志分析程序的各種行為。

5.2 日志分析

待程序運行一段時間之后，就會在‘/applog/devlog’目錄下生成日志文件，每個文件500KB左右，如下圖所示：

用tftp程序將日志取回，然后打開程序日志，在日志中搜索litedev.ys7.com，這個地址是智能網關上電之后第一個訪問的地址，我們第二章中介紹過。搜索結果如下圖：

上圖中，我們可以看到由litedev.ys7.com解析而來的ip地址：115.231.107.14，這與我們用wireshark抓包時得到的結果是相同的。

繼續翻看日志，在距離上圖不遠的地方，可以看到另一條日志，看起來像是與海康螢石MQTT服務器相關的日志內容，截圖如下：

從圖中，我們可以看到另一個ip地址：101.71.30.172，該地址同樣與我們wireshark抓包的結果吻合。MQTT通信協議是構建于TCP/IP協議之上的一種輕量級通信協議，經常出現在IoT設備系統中設備端與云端的通信過程中。

結合這兩條日志內容和wireshark的抓包結果，我們可以進一步確認設備的工作流程：與litedev.ys7.com通信，獲取了MQTT服務器的地址；然后與MQTT服務器通信，實現設備的邏輯功能。

在圖5-7和圖5-8中，我們分別用紅框標識了一個關鍵字符串。在海康螢石智能網關的文件系統中，二進制搜索其中一個字符串“lbs_connect”，確認該字符串出現在libmicrokernel.so.1中。用IDA加載該so文件，可以找到與lbs_connect字符串有關系的函數，查找該函數的交叉引用，可以看到有多處代碼調用了此函數，我們隨便找一處點開看下，如下圖所示：

可以看到在lbs_connect函數返回成功之后，就會調用send_authentication_i函數。這個函數看起來就是加密和認證相關的函數，接下來我們通過動態調試的方式分析網關加密和認證的流程。

5.3 動態調試的準備

對于嵌入式Linux操作系統，我們通常選用gdb和gdbserver作為調試工具。我們可以直接在設備上使用gdb進行本地調試，但gdb程序體積比較大，而且直接在設備上運行gdb會有很多不方便的地方，所以我們選擇通過gdbserver進行遠程調試。為了完成調試工作，我們首先需要一個可以運行在海康螢石智能網關設備上的gdbserver程序。

在4.3節中，我們使用MT7688 SDK中的工具對固件進行了重打包，所以當我們需要與芯片配套的gdbserver時，也是去MTK官方查閱資料。事實上，MT7688開發板的固件包中確實內置了一個gdbserver，但是當我們提取出這個gdbserver，并通過tftp傳輸到網關上開始運行后，發現并沒有任何輸出，可能是MTK官方定制了gdbserver的代碼，導致我們無法使用該程序調試。

那么，就只能去找一找有沒有其他可以正常運行在海康螢石智能網關中的gdbserver程序了。經過一番搜索后，在rapid7官方github賬戶上發現了已經編譯好的gdbserver程序，鏈接如下：https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver ， 這里我們選擇下載芯片對應的mipsle版本的gdbserver。

這里需要說明一下，rapid7提供的gdbserver，可能在某些設備上也無法正常使用，所以最靠譜的方法是使用SDK自己編譯一個出來，但是這里既然有可用的，我們就不（懶）再（得）去費功夫了。

我們通過tftp將gdbserver傳輸到網關中，并使用 gdbserver啟動davinci。如果使用附加方式調試，很可能會錯過davinci程序與服務器通信的認證過程。所以我們選擇使用gdbserver啟動程序，這樣一來，在遠程調試器連接之前，davinci程序將處于掛起狀態。命令如下：

此時，gdbserver就開始監聽23946端口，等待遠程調試器的連接。

接下來，我們可以選擇gdb或IDA作為遠程調試器連接gdbserver。IDA提供圖形界面，可以幫助我們理解程序的邏輯；但gdb要更穩定，可以有效避免IDA調試時出現的奇怪錯誤。我們這里直接選擇gdb作為遠程調試器，在后續的文章中會有介紹用IDA作為調試器的例子。

由于我們需要調試的是MIPS指令集的程序，而gdb默認情況下，僅支持調試與當前環境采用相同指令集的程序（i386），所以我們需要安裝可以調試MIPS指令集的gdb程序。安裝方法比較簡單，直接輸入sudo apt install gdb-multiarch即可。還可以給gdb程序加一個pwndbg插件，用于輔助我們的調試工作，該插件的官方地址是：https://github.com/pwndbg/pwndbg ，只需要下載下來，然后運行./setup.sh即可。此插件并非必需品，但是推薦裝上。

完成gdb的配置工作之后，就可以使用gdb連接gdbserver開始遠程調試了。gdb的調試命令非常多，可以直接搜索到很多整理好的常用命令，在這里，我們就遇見什么指令就解釋什么指令吧。運行gdb-multiarch，截圖如下：

上圖中，我們分別設置architecture為MIPS，讀取davinci的符號文件，在main函數設置斷點，并連接遠程的gdbserver，關鍵位置已用綠框圈出。然后，我們用快捷鍵c（continue），讓程序開始執行，過一會程序就會在main函數的入口處被斷下來。

此時，參考圖5-11中的file命令加載libmicrokernel.so.1的符號文件，然后就可以直接使用函數名lbs_connect下斷點了，如下圖：

稍等片刻，就會看到程序斷在lbs_connect函數中，等待我們的調試命令，截圖如下：

圖5-13最下方，打印出了函數調用棧，可以看到，程序是從lbs_redirect調用過來的，我們可以繼續在外層函數下斷點調試，以幫助我們理解程序的邏輯。

5.4 加密和認證流程分析

至此，我們已經具備了調試能力，可以調試固件中的davinci程序以及libmicrokernel.so.1等動態連接庫。為了節約篇幅，我們先將一些分析結論與各位分享，然后再詳細調試其中的某個細節。

在海康螢石的智能網關中，完整的通信流程涉及到3個密鑰，分別是share key、master key以及session key。其中，share key是智能網關與litedev服務器（與之對應的另一個服務器是MQTT服務器）共有的密鑰，由設備序列號等常量經過多次MD5運算得到，每個智能網關設備的share key都是獨一無二的；master key是智能網關與litedev服務器經過密鑰協商而來，用于加密傳輸session key，關于master key的密鑰協商過程就是我們將要分析的重點內容；最后session key是智能網關與MQTT服務器通信時使用的加密密鑰，該密鑰由litedev服務器直接下發給智能網關。

以上三個密鑰在使用過程中，share key是與設備綁定，且固定不變的，一旦獲取了share key，就可以完成所有的認證過程，最終被海康螢石認定為合法的網關設備；使用者通過手機app綁定智能網關時，會經過密鑰協商生成master key，每綁定一次會就更新一次；最后的session key則每次運行davinci程序時，都會更新，這也意味著每次重啟網關都會更新session key。三個不同級別的密鑰，三個不同的密鑰生存周期。

在對海康螢石智能網關的密鑰體系有所了解之后，我們就可以聚焦到某些細節上，下面來著重看一下master key和share key的生成過程。

5.4.1 master key生成流程

為了觸發智能網關的密鑰協商流程，我們需要先刪除當前的master key，具體講就是刪除 “/cfg/dev_masterkey”文件，如下圖所示：

刪除當前master key之后，按照前一節所述的方法通過gdbserver啟動davinci，即可開始調試了。

既然我們希望弄清楚加密和認證的流程，那么這個流程中網關和服務器通信數據的處理是我們要重點關注的。我們首先靜態分析一下5.2節結尾提到的send_authentication_i函數，它調用的common_serialize和authentication_i_serialize用于構造將要發送的數據。我們就在common_serialize函數之前下斷點，然后用gdb命令查看待發送數據的內容（本次調試時，地址為0x007d2dd0），如下圖所示：

在上圖中，可以看到待發送數據內容還是空的。待函數common_serialize執行完畢之后，重新打印該地址的數據，如下圖所示：

該地址的前幾個字節已經被賦值了。繼續調試該程序，在authentication_i_serialize函數之后下斷點，待程序中斷時，重新打印該內存處的數據，如下圖所示：

可以觀察到，authentication_i_serialize函數執行完畢之后，待發送數據基本構造完畢。我們對比一下本次發送數據和之前我們通過wireshark抓包獲取的發送數據，如下圖所示：

可以看到，兩組數據有一小部分是相同的，而不同的這部分應該就是網關密鑰協商的關鍵部分。

為了找到產生不同的原因，我們來重點逆向authentication_i_serialize函數，可以在該函數中發現其調用了一個簽名函數digital_sign_serialize函數：

在該簽名函數之前和之后下斷點，可以觀察到需要簽名的數據以及簽名結果。結合之前用gdb調試send_authentication_i時獲得的發送數據，就可以分析出發送的數據格式如下：

其中，dev_subserial是設備序列號；random_1是1字節隨機數，每次密鑰協商時都是不同的。由于random_1字節的不同，導致了digital_sign不同，所以總共有33（1+32）字節是每次通信都不同的。經過本次通信，智能網關將random_1參數上傳至litedev服務器。

通過類似的分析方法，就可以獲知認證過程中的其他3個函數的作用，這3個函數分別是：wait_authentication_ii、send_authentication_iii以及wait_authentication_iv。加上send_authentication_i函數，網關和服務器之間總共同步了4個隨機數。

在上述的分析過程中，可以發現一個名為lbs_affair的結構體貫穿了整個認證過程，4個隨機數也保存在結構體之中，該結構體的內容如下：

00000000 lbs_affair ``struct``00000000 random_1: .byte``00000001 random_2: .byte``00000002 random_3: .byte``00000003 random_4: .byte``00000004 dev_subserial: .byte 16``00000014 master_key: .byte 16``00000024 dev_id: .byte 32``00000044 session_key: .byte 16``00000054 share_key: .byte 32``00000074 share_key_len: .half``00000076 .byte``00000077 .byte``00000078 global_out_packet: lbs_packet``0000008C global_in_packet: lbs_packet``000000A0 lbs_net_work: .word``000000A4 lbs_affair ends

其中，random_1和random_3由智能網關生成，發送給服務器；random_2和randon_4由服務器生成，發送給智能網關。

通過這4個隨機數以及share key就可以生成master key了，并進一步由master key獲取session key。其master key的生成算法比較簡單，可以在generate_masterkey函數中找到，如下圖所示：

根據圖中紅框標出的偏移可以知道，master key的生成過程就是將random_1、random_2、random_3、random_4和share_key拼湊在一起，然后調用sha512函數，其hash結果就是最終的master key了。

繼續分析其固件的后續內容可以發現以master key作為密鑰，使用aes cbc算法解密session key相關的代碼段，這里就不截圖了。獲取session key之后，通信數據的加密密鑰就完全切換為session key，不再使用master key了。

5.4.2 share key生成流程

相比于master key的生成過程，share key的生成無疑簡單了很多。可以在generate_sharekey函數中找到關于share key的各種運算，通過閱讀IDA反匯編后的代碼，可以確認share key是通過對dev_subserial和dev_verification_code以及一個固定的鹽進行多次MD5而得到，其中dev_verification_code是設備的認證碼，該認證碼被貼在海康螢石智能網關背面的標簽上。在md5運算過程中，固定的鹽值如下圖所示：

上圖中，“ 88075998”是海康的聯系電話，在此處，“www.88075998.com”作為鹽參與了第二次MD5運算中。

6. 小結

到此，關于海康螢石的分析文章就結束了。在這篇文章中，我們先是分別解決了電路分析，固件提取、分析、重打包，程序的動態調試等問題，最后分析了海康螢石的密鑰體系，雖然寫的有些模糊，但基本上涵蓋了所有關鍵點，很多海康和螢石的其他IoT設備也使用了類似的密鑰體系，本篇分析可以提供一個借鑒。其實關于海康螢石智能網關還有很多可以寫的內容，但鑒于胖猴實驗室和海康的良好關系，把海康螢石的網關設備分享得非常透徹也不太好，還是等有機會私下交流吧。

在筆者分析海康螢石智能網關時，Ghidra尚未發布且IDA尚不支持mips decompiler，但在寫本文時已經出現了很多好用的工具，合理利用這些工具可以大幅度減少分析工作量。最后，希望本篇文章能給各位讀者帶來一些收獲，如若有什么想商量或者討論的，可以隨時聯系我們胖猴微信：PwnMonkey。在后續文章中，我們還會繼續分享其他的研究案例，敬請期待。

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/1320/