前言 - Detect My Love

在部分韌體中，廠商為了防止遭到複製破解或是山寨，會對韌體和檔案系統進行加密或是置換。根本就是EDR跟Malware的同款 love hate relationship

書接上(上)回，flash back 一下Day 2 的內容，韌體本身是一個壓縮檔案，裡面的架構如下：

Firmware
├── Bootloader          ← 硬體初始化
├── Kernel / RTOS       ← 作業系統核心
├── Root Filesystem (RootFS)
│   ├── /lib
│   ├── /www
│   ├── /usr
│   ├── Vendor Applications
│   ├── Configuration Files
│   └── Startup Scripts
├── Data Partition
├── NVRAM / Config

因此一般的流程會是：
辨識檔案格式 → 解壓縮韌體拆出裡面的東西 → 提取RootFS

（上上一章也有提到不同的檔案系統和它們對應的工具解法。一般情況下，使用相對應的工具後，可以解壓縮出正確的檔案結構。）

但是當廠商加上加密或混淆後，原先的工具解就可能會失敗，因此今天來介紹一些針對加密韌體的常見處理方式。

0x01 識別加密

熵值分析

• binwalk -E firmware.bin
• 接近 1.0：加密或已壓縮　（上圖）
• 忽高忽低：部分加密（比如只加密header但是rootfs依然是明文）（下圖）
  

特徵尋找

• binwalk firmware.bin
• 若是像這種的很可能是symbol被拔掉或是被高度加密
  

殘留可讀字串

• xxd / hexdump
• 部分片段：加密强度不夠或只加密部分區塊
• 無可讀字串~~（亂碼）~~：完全加密

0x03 加密常見型態分類

延伸補充：
還有一種並非加密，但也是好玩DLC的一部分 --- 檔案系統復原
e.g., Tenda在部分firmware中針對CRC和header進行混淆、TP-Link 自製的 MiniFS等等

0x04 工具失敗後的逆向策略

進一步細分逆向路線：

• 找現成解密器：找到官方 tool 、以前的沒有加密的東西用相同邏輯解
• 靜態逆向：逆向重現演算法、撈撈 hard code 密鑰
• 混合動態：用 QEMU / strace hook / Unicorn 模擬特定函式

(ref: Pass the Salt 2026[1])

0x05 舉幾個栗子

Ruijie[2]

背景：中國網路設備公司，在多個領域有很多不同的 IoT 產品

binwalk看起來有高機率進行了加密

初步解壓縮後進行初步偵查
tips: 偵查 upgrade 相關 binary/strings 是一個常見的分析切入點

發現寫死的加密邏輯，逆向成功

Stormsheld[3]

背景：法國的 IoT 設備、防火牆製造商

原先韌體經過加密，在 Internet Archive 中發現了過往版本
tips：鏡像網站中找到的VM/binary 未加密

逆向出的加密函數使用openssl，經過 Dtrace 動態 hook 加密函式位址得到具體加密位置的 offset，最後 dd dump 並成功解密

Special Thanks

感謝kalakala支援了幾個案例分析，太扛了

References

[1] How to Beat Firmware Encryption (it4sec)
[2] https://claroty.com/team82/research/the-insecure-iot-cloud-strikes-again-rce-on-ruijie-cloud-connected-devices
[3] https://archives.pass-the-salt.org/Pass%20the%20SALT/2026/slides/PTS2026-TALK-05-Firmware_encryption.pdf

(Tools)

• dlink-decrypt
• Firmware Analysis Toolkit
• unblob — 遞迴解包，binwalk 的替代/補充選項
• FMK (Firmware Mod Kit)
• FACT — Firmware Analysis and Comparison Tool
• Dtrace — 動態追蹤，可用於分析解密流程