0x01 背景

想象一下以下場景，當(dāng)你跟隨我們的《物聯(lián)網(wǎng)終端安全入門與實(shí)踐》系列文章學(xué)會了多種獲取固件的方法，甚至忍痛將自家路由器拆了掏出了固件之后，正雄心勃勃準(zhǔn)備繼續(xù)學(xué)習(xí)提取文件系統(tǒng)、仿真時(shí)，發(fā)現(xiàn)一向滿腹經(jīng)綸的binwalk竟然啞火，它沒有輸出任何你期待的信息。別擔(dān)心這可能不是你的binwalk壞了，一般情況下是這個(gè)固件格式和內(nèi)容超出了它的理解范圍，簡單理解就是固件被廠商作了加密處理。

隨著物聯(lián)網(wǎng)的飛速發(fā)展，越來越多的設(shè)備被曝出存在大量的安全問題，這不僅給整個(gè)網(wǎng)絡(luò)環(huán)境以及用戶帶來較大的安全隱患，更給廠商能否獲取較好的品牌口碑帶來足夠大的挑戰(zhàn)。為此，越來越多的廠商都會給自家設(shè)備發(fā)布加密固件來對抗一些存有惡意目的攻擊者的分析和研究。

0x02 固件的常見加解密方法

在正式動手對固件進(jìn)行解密之前，我們需提前了解廠商一般會以怎樣的形式發(fā)布加密固件以及在設(shè)備啟動和固件升級過程中，會在哪些地方對固件進(jìn)行解密，從而思考實(shí)現(xiàn)解密的邏輯和方法。

2.1  從固件發(fā)布場景定位解密方法

廠商發(fā)布加密固件一般有以下三種場景：

固件出廠時(shí)未加密，后續(xù)發(fā)布包含解密程序的未加密過渡版本，隨后發(fā)布加密固件

固件出廠時(shí)加密，后續(xù)發(fā)布包含新版解密程序的未加密過渡版本，隨后發(fā)布使用新加密方案加密的固件

固件出廠時(shí)加密，后續(xù)發(fā)布包含新版解密程序的加密版本（使用舊版本加密方案加密），隨后發(fā)布使用新加密方案加密的固件

2.1.1 固件出廠未加密后續(xù)發(fā)布包含解密方案的未加密固件

固件在出廠時(shí)未加密，也未包含任何解密代碼，后續(xù)為了發(fā)布加密固件，會提前發(fā)布一個(gè)包含解密程序的未加密版本作為過渡版本，這樣后續(xù)發(fā)布加密固件時(shí)可使用該解密程序進(jìn)行解密，這類情況在發(fā)布時(shí)間較早的設(shè)備中比較常見。

對于此種情況，可尋找固件過渡版本v1.1，從中分析出所包含的解密邏輯和算法，從而實(shí)現(xiàn)對后續(xù)加密固件的解密。因?yàn)橛脩魺o法從v1.0直接升級v1.2的固件，所以在官方的固件發(fā)布描述中，一般會存在如下圖所述的描述。

2.1.2 固件出廠加密后續(xù)發(fā)布包含新版解密方案的未加密固件

固件在出廠時(shí)加密，廠商決定更改加密方案并發(fā)布一個(gè)未加密的轉(zhuǎn)換版本v1.1，其中包含了新版本的解密程序，這樣后續(xù)發(fā)布加密固件時(shí)可使用新版本的解密程序進(jìn)行解密。

以過渡版本v1.1作為分界線，我們分別對其前后版本固件的解密進(jìn)行說明。

對于v2.0及更高版本的固件即過渡版本之后的固件（假設(shè)都使用同一種加密方案，無其它過渡版本）：與上述場景1中描述的一致，可以通過尋找過渡版本v1.1，從中分析出v2.0的解密方法從而對v2.0固件進(jìn)行解密

對于v1.0及更低版本的固件即過渡版本之前的固件（假設(shè)都使用同一種加密方案，無其它過渡版本）：一是可購買實(shí)體設(shè)備，通過設(shè)備的調(diào)試接口或管理服務(wù)等直接從設(shè)備中提取解密后的固件。二是需設(shè)法獲取內(nèi)容完整的固件，直接對加密的固件進(jìn)行分析，尋找包含在其中的解密算法。第三種方法則比較取巧，需要?dú)v史版本固件存在RCE漏洞可以獲取到設(shè)備的Linux Shell，從而分析其固件升級邏輯獲取解密算法。

說明：對于上述方法沒有絕對的優(yōu)劣勢，需根據(jù)具體情況進(jìn)行選擇，對于有條件的小伙伴，推薦購買相應(yīng)實(shí)體設(shè)備，一是有幾率通過調(diào)試接口或管理服務(wù)等直接從設(shè)備上dump出解密后的固件，二是能從Flash中提取出包含解密方法的完整版固件，以便于后續(xù)的分析。

2.1.3 固件出廠加密后續(xù)發(fā)布包含新版解密方案的加密固件

固件在出廠時(shí)加密，廠商決定更改加密方案并發(fā)布一個(gè)包含新版本解密程序的加密固件，這樣后續(xù)發(fā)布加密固件時(shí)可使用新版本的解密程序進(jìn)行解密。

此類場景發(fā)布的固件自始至終都是加密形態(tài)存在的，與上述場景中v1.1及之前的固件類似，常見的解密方法有3種，具體情況得具體選擇。

2.2 設(shè)備啟動流程中的加解密邏輯

接下來我們從設(shè)備啟動流程來描述下固件的加解密邏輯。

首先我們來看看設(shè)備的啟動流程：

• 設(shè)備上電后，加載芯片中的BootROM程序（芯片廠商固化在CPU中的程序）到SRAM（片內(nèi)RAM，一般較?。┲羞\(yùn)行
• BootROM加載SPL程序（二級引導(dǎo)程序，可用于初始化片外更大的RAM以提供系統(tǒng)運(yùn)行環(huán)境）到SRAM中運(yùn)行
• SPL加載BootLoader到片外RAM中運(yùn)行
• BootLoader隨即引導(dǎo)內(nèi)核啟動
• 內(nèi)核隨后完成對文件系統(tǒng)的加載，執(zhí)行啟動腳本完成設(shè)備的最終啟動

上述的啟動過程包含BootROM、SPL、BootLoader、Kernel、FileSystem五大部分，其中BootROM是由芯片廠商固化在芯片內(nèi)的程序，設(shè)備廠商一般無法自定義，其余四塊內(nèi)容廠商都可進(jìn)行定制，但對SPL進(jìn)行加密的場景沒有見過，這里不加以贅述。下表展示了常見情況下固件中的某塊數(shù)據(jù)被加密后解密方法可能存在的位置：

2.3 固件更新流程中的加解密邏輯

接下來我們從設(shè)備固件升級流程來描述下固件的加解密邏輯。

固件更新流程如下：

• 用戶本地上傳固件或者設(shè)備聯(lián)網(wǎng)下載新版固件存儲到設(shè)備Flash中
• 判斷負(fù)責(zé)處理固件更新的后臺服務(wù)是否存在解密的功能a.（常見情況）如果有解密功能，則后臺服務(wù)執(zhí)行解密邏輯對固件進(jìn)行解密，即當(dāng)前文件系統(tǒng)中會存在解密邏輯代碼b. 如果后臺服務(wù)不負(fù)責(zé)對固件進(jìn)行解密，則會在后續(xù)重啟過程中由BootLoader或Kernel進(jìn)行解密
• 設(shè)置Boot標(biāo)識位后重啟設(shè)備
• 運(yùn)行新版本固件

從固件的更新流程中我們知道對固件的解密有2種情況，但由后臺服務(wù)調(diào)用解密邏輯進(jìn)行解密是比較常見的，所以在拿到文件系統(tǒng)后，如果想分析其解密邏輯以實(shí)現(xiàn)對其它版本固件的解密，可以從設(shè)備的固件更新功能入手來定位解密邏輯。

2.4 常見解密方法總結(jié)

從上述固件的發(fā)布場景、設(shè)備的啟動和固件升級流程中，我們發(fā)現(xiàn)固件的加密情況有很多種，廠商會根據(jù)設(shè)備性能、應(yīng)用場景、預(yù)算等多個(gè)條件來選擇適合的加密方式，某些對安全性要求較高的產(chǎn)品如工控設(shè)備等往往還會采用硬件加密的形式，將解密算法存儲在單獨(dú)的芯片中，強(qiáng)行讀取會導(dǎo)致芯片損壞。(PS:在本文中我們只講述了一些常見的解密方法和技巧，大家有更好的想法或方法歡迎在評論區(qū)留言交流)

針對物聯(lián)網(wǎng)終端設(shè)備的固件解密，我們總結(jié)了如下五種方法和技巧：

基于老版本未加密固件中的解密程序?qū)崿F(xiàn)新版本加密固件的解密

對于固件出廠時(shí)未加密，后續(xù)發(fā)布的固件是加密的情況，可以通過對比邊界版本，解包最后一個(gè)未加密版本逆向升級程序還原加密過程，以實(shí)現(xiàn)對加密固件的解密。

基于調(diào)試串口直接提取未加密固件

如果設(shè)備存在UART、JTAG等調(diào)試接口，可通過連接硬件接口獲取設(shè)備的Shell，從而dump出設(shè)備的固件。

對于可直接進(jìn)入Linux Shell的情況，具體的操作可參考我們之前發(fā)布的《物聯(lián)網(wǎng)終端安全入門與實(shí)踐之玩轉(zhuǎn)物聯(lián)網(wǎng)固件（上）》一文。

但由于某些設(shè)備安全限制較高導(dǎo)致無法進(jìn)入Linux Shell，我們可嘗試進(jìn)入BootLoader Shell（最常見的是Uboot Shell）對固件進(jìn)行提取。這里要說明的一點(diǎn)是部分設(shè)備更新固件后會將解密后的新版固件寫回Flash，這種情況下dump出的固件是未加密的，而相反的是部分設(shè)備Flash中的固件一直是加密狀態(tài)存在，只是在每次設(shè)備啟動時(shí)進(jìn)行動態(tài)解密。所以此種方法提取出的固件可能也是加密的，但好處在于可以避免因拆解設(shè)備Flash去讀固件導(dǎo)致設(shè)備損壞的風(fēng)險(xiǎn)，并且可以獲取到較為完整的固件（官方下載的固件可能只是某塊數(shù)據(jù)的更新包）。

基于管理服務(wù)獲取設(shè)備Shell提取文件系統(tǒng)

對于有Telnet、SSH等服務(wù)的設(shè)備，可以通過這些服務(wù)進(jìn)入設(shè)備的Linux Shell進(jìn)行固件提取。服務(wù)一般在設(shè)備的web管理頁面中可手動開啟，但需要說明的一點(diǎn)是某些廠商會開發(fā)自家的CLI屏蔽掉底層Linux Shell，連接這些服務(wù)進(jìn)入的Shell只是廠商的CLI，也無法提取文件系統(tǒng)，不過某些設(shè)備（光貓居多）的CLI存在可進(jìn)入Linux Shell的命令，具體可自行在互聯(lián)網(wǎng)上搜索相應(yīng)的方法。

基于低版本固件RCE漏洞獲取設(shè)備Shell分析解密邏輯實(shí)現(xiàn)對新版固件的解密

如果設(shè)備歷史加密版本固件出現(xiàn)過RCE漏洞，可將存在漏洞的固件刷入設(shè)備，通過RCE漏洞獲取設(shè)備Linux Shell，再分析其包含的解密邏輯，最終通過該解密邏輯實(shí)現(xiàn)對更新版本固件的解密。需要注意的是存在RCE漏洞版本的固件所使用的加密方案需要與新版本固件一致。

直接分析完整固件中包含的解密邏輯實(shí)現(xiàn)對固件的解密

常見情況下固件的解密邏輯肯定是存在Flash中的，當(dāng)獲取到完整版固件（拆機(jī)從Flash讀取或者從BootLoader Shell中提取等）后，可以直接對整個(gè)固件進(jìn)行逆向分析尋找解密邏輯代碼實(shí)現(xiàn)對固件的解密，但此種方法難度較大，并且這類設(shè)備安全性一般較高，很有可能分析出了解密邏輯但拿不到解密密鑰，如密鑰單獨(dú)存放在某個(gè)安全芯片中。

0x03 解密實(shí)戰(zhàn)

本章首先講述一些判斷固件是否被加密或壓縮的方法，之后通過兩個(gè)實(shí)例講解不同場景下如何對物聯(lián)網(wǎng)設(shè)備固件進(jìn)行解密，由于篇幅限制，這里僅對上述解密方法中的其中2種輔以實(shí)例講解，另外兩種網(wǎng)上均有不錯(cuò)的分析文章，文末也會推薦相應(yīng)的文章供大家學(xué)習(xí)。

3.1 判斷固件是否被加密或壓縮的方法

對于存在過渡版本的固件，可以通過閱讀廠商所發(fā)布固件的Notes關(guān)鍵信息，能夠幫助我們判斷固件從哪個(gè)版本開始進(jìn)行加密。

查看固件的熵值進(jìn)行判斷，熵是對隨機(jī)性的一種度量，它的值在0到1之間，值越高表示隨機(jī)性越好，接近1的值被認(rèn)為是高熵，反之亦然，壓縮或加密的數(shù)據(jù)具有較高的熵值。我們可以通過binwalk -E以圖形化的形式查看加密和未加密固件熵值的變化，如下圖1中未加密的固件熵值存在較大波動，而下圖2中加密的固件熵值基本都保持在1。

3.2  實(shí)例一：DrayTek Vigor2962固件解密

3.2.1 多角度嘗試解密

一般拿到一個(gè)加密固件后，我們可以先從多個(gè)角度對其進(jìn)行分析，不要急于購買設(shè)備或者拆解設(shè)備，或許互聯(lián)網(wǎng)上就存在著你要想的那個(gè)key。

• 對官網(wǎng)下載的固件解壓以及使用binwalk解包均失敗，查看熵值一直保持1，遂判斷固件加密。從廠商官網(wǎng)和其他渠道也未發(fā)現(xiàn)疑似過渡版本的固件，判斷此設(shè)備出廠時(shí)固件就已是加密形態(tài)存在。
• 在互聯(lián)網(wǎng)上嘗試搜索公開的文章或工具也無果。
• 為了更好的進(jìn)行解密，購買一臺實(shí)體設(shè)備。

• 掃描設(shè)備開放的端口，發(fā)現(xiàn)開啟了Telnet和SSH服務(wù)。

• Telnet連接上后，發(fā)現(xiàn)是個(gè)自定義的受限CLI，嘗試使用$(telnetd -l /bin/sh -p 2323)盲測失敗。SSH登錄后也是相同的情況，從Telnet、SSH獲取Linux Shell的路也被堵死。

• 互聯(lián)網(wǎng)搜索該設(shè)備的歷史漏洞，但也一無所獲，無法通過歷史RCE漏洞獲取Linux Shell。
• 沒辦法只能拆解設(shè)備，發(fā)現(xiàn)存在UART串口，連接UART串口后啟動設(shè)備進(jìn)入的是一個(gè)Console Shell，無法進(jìn)入Linux Shell，只能從里面獲取一些日志和進(jìn)程信息，不能提取解密后的文件系統(tǒng)。

3.2.2 Uboot Shell提取固件

• 于是嘗試從Uboot Shell中進(jìn)行固件提取，重新啟動后快速按任意鍵進(jìn)入U(xiǎn)boot Shell。

• 查看Uboot Shell中支持的命令。

draytek> help 
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
blkcache- block cache diagnostics and control
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootefi - Boots an EFI payload from memory
bootelf - Boot from an ELF image in memory
booti   - boot arm64 Linux Image image from memory
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
bubt    - Burn a u-boot image to flash
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
dhcp    - boot image via network using DHCP/TFTP protocol
dm      - Driver model low level access
dray    - Draytek ops
draytftp- Use tftp client to get firmware then boot
echo    - echo args to console
editenv - edit environment variable
efuse   - efuse - read/Write SoC eFuse entries

env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls  - list files in a directory (default /)
ext4size- determine a file's size
ext4write- create a file in the root directory
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatsize - determine a file's size
fdt     - flattened device tree utility commands
fstype  - Look up a filesystem type
go      - start application at address 'addr'
gpio    - query and control gpio pins
gzwrite - unzip and write memory to block device
help    - print command description/usage
i2c     - I2C sub-system
icache  - enable or disable instruction cache
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
ir      - ir        - Reading and changing internal register values.

itest   - return true/false on integer compare
ln      - Create a symbolic link
load    - load binary file from a filesystem
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
lzmadec - lzma uncompress a memory region
md      - memory display
md5sum  - compute MD5 message digest
mdio    - MDIO utility commands
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
part    - disk partition related commands
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
pxe     - commands to get and boot from pxe files
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
save    - save file to a filesystem
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
showvar - print local hushshell variables
size    - determine a file's size
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility command
switch  - Switch Access commands
sysboot - command to get and boot from syslinux files
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
tftpsrv - act as a TFTP server and boot the first received file
time    - run commands and summarize execution time
true    - do nothing, successfully
unzip   - unzip a memory region
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version

• 這里考慮將存儲分區(qū)中的文件加載到內(nèi)存后，再進(jìn)行讀取。使用printenv打印一下Uboot環(huán)境變量，發(fā)現(xiàn)了一些關(guān)鍵信息，rootfs.uboot.img存儲在eMMC的分區(qū)2中。

什么是eMMC？

eMMC ( Embedded Multi Media Card) 采用統(tǒng)一的MMC標(biāo)準(zhǔn)接口， 把高密度NAND Flash以及MMC Controller封裝在一顆BGA芯片中。針對Flash的特性，產(chǎn)品內(nèi)部已經(jīng)包含了Flash管理技術(shù)，包括錯(cuò)誤探測和糾正，F(xiàn)lash平均擦寫，壞塊管理，掉電保護(hù)等技術(shù)。用戶無需擔(dān)心產(chǎn)品內(nèi)部Flash晶圓制程和工藝的變化。同時(shí)eMMC單顆芯片為主板內(nèi)部節(jié)省更多的空間。

簡單地說，eMMC=Nand Flash+控制器+標(biāo)準(zhǔn)封裝

這里介紹以下Uboot Shell中常見的操作eMMC的命令：

mmc list:列出當(dāng)前的mmc設(shè)備mmc dev 1:切換到eMMC設(shè)備mmc part:顯示當(dāng)前eMMC的所有分區(qū)

常見的TypeID對應(yīng)的文件系統(tǒng)如下表：

查看所有分區(qū)中的文件內(nèi)容，發(fā)現(xiàn)rootfs.uboot.img的確存在分區(qū)2中。

• 由于需要提取的文件系統(tǒng)存在于eMMC存儲（一種NAND存儲）中，所以需要先將其加載至內(nèi)存中，再將數(shù)據(jù)讀取保存。

在Uboot Shell中將eMMC的某分區(qū)中的文件讀到內(nèi)存中某個(gè)地址的方法如下：

從加載的地址處讀取固定大小數(shù)據(jù)的方法如下

這里有個(gè)問題就是內(nèi)存中讀到了數(shù)據(jù)，如何保存？

嘗試將數(shù)據(jù)保存到U盤上，提示報(bào)了Unsupported feature metadata_csum found, not writing.Uboot下ext4分區(qū)不支持metadata_csum和64位特性。

通過記錄日志的形式：由于我們使用的是Xshell連接的串口，而Xshell自帶了日志記錄功能，所以需在使用md命令讀取內(nèi)存中數(shù)據(jù)前將日志啟動，讀取完成后將日志中記錄的十六進(jìn)制字符串轉(zhuǎn)為二進(jìn)制程序即可。

注：由于波特率只有115200，傳輸速度較慢，需要掛機(jī)跑一晚。

• 使用上述方法，我們最終將分區(qū)6中的image.sav文件（分區(qū)5下的uffs目錄下v2962_ram_flash.bin文件無法讀進(jìn)內(nèi)存中）從設(shè)備中dump出來，發(fā)現(xiàn)固件并未加密，使用binwalk可直接進(jìn)行解析。

3.2.3 固件解密邏輯的分析

這里說明下為什么拿到文件系統(tǒng)后還需要進(jìn)一步分析其解密邏輯：

官網(wǎng)固件是加密的，想要分析其它版本的固件，需刷入所需版本的固件后按照上述方法進(jìn)行提取

由于波特率較低傳輸速率慢，單次提取耗時(shí)較長，我們花費(fèi)了幾乎1晚的時(shí)間，才完成了Vigor 2962某版本未加密固件的提取

分析出解密邏輯，可以直接使用該解密方法實(shí)現(xiàn)對其它版本固件的解密，這種以點(diǎn)帶面的解密方法的使用，節(jié)省了大量的固件解密時(shí)間/設(shè)備采購成本

• 使用Binwalk解出來的ext文件系統(tǒng)不全。

• 嘗試使用掛載的方式，掛載文件系統(tǒng)mount 0.ext ./ext-root，發(fā)現(xiàn)能正常獲取ext文件系統(tǒng)下的所有文件。

• 嘗試在文件系統(tǒng)下搜索字符串decrypt，發(fā)現(xiàn)存在一個(gè)名為decrypt_firmware的函數(shù)，該函數(shù)存在于fw_upload腳本中，根據(jù)命名推測該腳本用于處理固件更新。

• decrypt_firmware函數(shù)實(shí)現(xiàn)如下，分析其邏輯，發(fā)現(xiàn)chacha20應(yīng)該就是解密程序，理論上只要按照該函數(shù)中解密的命令進(jìn)行執(zhí)行即可完成解密。

decrypt_firmware(){input_file=$1decrypt_data_sect="/tmp/decrypt_data_sect"data_sect="/tmp/data_sect"head_sect="/tmp/head_sect"tail -c +$((256 + 64 + 64 + 1)) $input_file > $data_secthead -c $((256 + 64 + 64)) $input_file > $head_sectenc_signature=$(head -c $((320 + 36)) $head_sect | tail -c 4)if [ "$enc_signature" == "0204" ]; thenecho "Firmware is encypt, start to decrypt."nnotallow=$(head -c $((320 + 48)) $head_sect | tail -c 12)/draytek/drayapp/chacha20 $data_sect $decrypt_data_sect $noncecat $head_sect $decrypt_data_sect > $input_file || abort "Unable to decrypt"rm $decrypt_data_sectfirm $data_sect $head_sect}decrypt_firmware $TMP_FW_PATH

• 由于要執(zhí)行chacha20程序，理論上由于異架構(gòu)問題，需要仿真運(yùn)行，而qemu-user模式不支持arm64，只能使用qemu-system模式。但是在實(shí)際操作過程中發(fā)現(xiàn)使用chroot切換文件系統(tǒng)根目錄后也可以執(zhí)行。

• 最終我們對官網(wǎng)下載到的最新版固件也能進(jìn)行解密。

3.2.4 小結(jié)

針對DrayTek Vigor2962固件的解密，首先嘗試尋找過渡版本以及互聯(lián)網(wǎng)搜索公開的解密方法未果，之后嘗試通過自帶的SSH、Telnet服務(wù)以及歷史RCE漏洞獲取Shell均未成功。之后，拆機(jī)連接UART串口也無法獲取到Linux Shell。最終，利用Uboot Shell dump出eMMC分區(qū)中的未加密固件，繼而分析其解密邏輯，實(shí)現(xiàn)了對Vigor 2962最新版本固件的解密。

3.3  實(shí)例二：飛某星VW1900設(shè)備固件解密

由于我們已有實(shí)體設(shè)備，且已掌握該設(shè)備某版本固件的RCE漏洞，所以刷入低版本固件后，通過漏洞能夠獲取設(shè)備Root Shell，進(jìn)而深入分析其解密邏輯。

該實(shí)例著重講解在此種場景下定位解密程序、分析解密邏輯的方法，以實(shí)現(xiàn)對更高版本固件的解密。

3.3.1 定位解密程序

• 由于我們可以獲取到設(shè)備的Shell，因此我們可以通過固件升級時(shí)的一些接口信息定位后臺中用于處理固件更新的具體服務(wù)。
• 通過BurpSuite攔截設(shè)備自動升級包。

但發(fā)現(xiàn)固件升級失敗了。

• 嘗試攔截手動上傳的固件更新包。

發(fā)現(xiàn)更新固件時(shí)調(diào)用的后臺接口是一個(gè)名為manual_update.cgi程序。

• 在Shell終端中搜索該接口名，發(fā)現(xiàn)該接口功能在webserver程序中實(shí)現(xiàn)。

Ghidra加載該程序定位具體字符串，發(fā)現(xiàn)設(shè)備的更新功能主要在函數(shù)FUN_0001e9a8中實(shí)現(xiàn)。

分析該函數(shù)的具體實(shí)現(xiàn)邏輯，首先從NVRAM中讀取CPU_TYPE，根據(jù)不同值執(zhí)行不同的腳本。

為了分析其具體執(zhí)行流程，獲取設(shè)備Shell后，讀取nvram中相應(yīng)的值，發(fā)現(xiàn)CPU_TYPE=bcm4708。

之后處理固件上傳的POST請求，將加密的固件寫入/mnt/code.bin文件中。

隨后執(zhí)行如下系統(tǒng)命令對固件進(jìn)行解密，從命令中可看出/usr/bin/rc5-update應(yīng)該就是固件的解密程序。

直接在設(shè)備上測試該方法驗(yàn)證我們的分析結(jié)論，發(fā)現(xiàn)可以成功解密。

外傳解密后的固件，使用binwalk可直接進(jìn)行解包獲取完整的文件系統(tǒng)。

3.3.2 以點(diǎn)帶面解密其它版本固件

至此，我們已經(jīng)知道rc5-update是解密程序以及使用方法，所以針對其它版本固件的解密，有兩種思路：

直接使用程序?qū)碳M(jìn)行解密，這種方法是最簡單的，這里需要注意程序的架構(gòu)問題

分析rc5-update中的解密算法，自己編寫代碼實(shí)現(xiàn)。由于程序包含解密算法，需要有一定的逆向分析功底

3.3.2.1 局部仿真調(diào)用解密程序

由于該設(shè)備是arm架構(gòu)的，rc5-update無法直接在除arm架構(gòu)之外的主機(jī)上運(yùn)行，但可以通過局部仿真的方式運(yùn)行該解密程序?qū)崿F(xiàn)對其它版本固件的解密。具體的仿真原理和方法可參考上一篇文章。

• 局部仿真解密當(dāng)前版本固件成功。

• 局部仿真解密最新版本固件成功。

3.3.2.2 逆向解密算法

• 讀取內(nèi)置在解密程序中的一個(gè)31字節(jié)數(shù)組數(shù)據(jù)，經(jīng)過計(jì)算得出一個(gè)20字節(jié)的數(shù)組作為密鑰的第一部分。

• 該程序提供加密和解密功能，使用不同的參數(shù)進(jìn)行區(qū)分。

• 讀取加密固件的前10字節(jié)數(shù)據(jù)作為密鑰的第二部分拼接在第一部分后面，最終根據(jù)這30字節(jié)的數(shù)組生成一個(gè)1056字節(jié)大小的最終密鑰數(shù)組，之后循環(huán)讀取加密固件，每8192字節(jié)作為一個(gè)block進(jìn)行解密。

• 我們使用代碼還原整個(gè)解密算法，最終能成功對加密的固件實(shí)現(xiàn)解密。

3.3.3 小結(jié)

該實(shí)例主要講述了在拿到解密的固件后，定位解密邏輯以及分析解密算法的思路，最終通過局部仿真和自己實(shí)現(xiàn)解密算法2種方法實(shí)現(xiàn)了對其它版本固件的解密。

0x03總結(jié)

本文從設(shè)備固件的發(fā)布場景、設(shè)備的啟動流程以及固件升級流程等多方面描述了物聯(lián)網(wǎng)終端固件常見的加解密方案，總結(jié)了5種常見的解密方法，之后詳細(xì)講述了運(yùn)用其中2種方法實(shí)現(xiàn)解密的實(shí)例。由于篇幅的限制，另外幾種解密方法本文沒有給出具體的例子，文末會貼出相關(guān)的參考鏈接。

參考鏈接

【1】尋找過渡版本實(shí)現(xiàn)解密 https://payatu.com/blog/munawwar/solving-the-problem-of-encrypted-firmware

【2】直接分析完整版固件實(shí)現(xiàn)解密 https://cloud.tencent.com/developer/article/1005700

【3】https://www.freebuf.com/articles/endpoint/254257.html