物联网终端安全入门与实践之玩转物联网固件之解密篇-创站工坊

当前位置：首页 >人工智能 >物联网终端安全入门与实践之玩转物联网固件之解密篇

物联网终端安全入门与实践之玩转物联网固件之解密篇

发布时间：2025-11-05 05:25:17 来源：创站工坊作者：IT科技类资讯

0x01 背景

想象一下以下场景，物联网终玩转物联网固当你跟随我们的端安《物联网终端安全入门与实践》系列文章学会了多种获取固件的方法，甚至忍痛将自家路由器拆了掏出了固件之后，全入正雄心勃勃准备继续学习提取文件系统、门实仿真时，践之件之解密发现一向满腹经纶的物联网终玩转物联网固binwalk竟然哑火，它没有输出任何你期待的端安信息。别担心这可能不是全入你的binwalk坏了，一般情况下是门实这个固件格式和内容超出了它的理解范围，简单理解就是践之件之解密固件被厂商作了加密处理。

随着物联网的物联网终玩转物联网固飞速发展，越来越多的端安设备被曝出存在大量的安全问题，这不仅给整个网络环境以及用户带来较大的全入安全隐患，更给厂商能否获取较好的门实品牌口碑带来足够大的挑战。为此，践之件之解密越来越多的厂商都会给自家设备发布加密固件来对抗一些存有恶意目的攻击者的分析和研究。b2b供应网

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

在正式动手对固件进行解密之前，我们需提前了解厂商一般会以怎样的形式发布加密固件以及在设备启动和固件升级过程中，会在哪些地方对固件进行解密，从而思考实现解密的逻辑和方法。

2.1 从固件发布场景定位解密方法

厂商发布加密固件一般有以下三种场景：

固件出厂时未加密，后续发布包含解密程序的未加密过渡版本，随后发布加密固件

固件出厂时加密，后续发布包含新版解密程序的未加密过渡版本，随后发布使用新加密方案加密的固件

固件出厂时加密，后续发布包含新版解密程序的加密版本（使用旧版本加密方案加密），随后发布使用新加密方案加密的固件

固件在出厂时未加密，也未包含任何解密代码，后续为了发布加密固件，会提前发布一个包含解密程序的未加密版本作为过渡版本，这样后续发布加密固件时可使用该解密程序进行解密，这类情况在发布时间较早的设备中比较常见。

对于此种情况，可寻找固件过渡版本v1.1，从中分析出所包含的解密逻辑和算法，从而实现对后续加密固件的解密。站群服务器因为用户无法从v1.0直接升级v1.2的固件，所以在官方的固件发布描述中，一般会存在如下图所述的描述。

固件在出厂时加密，厂商决定更改加密方案并发布一个未加密的转换版本v1.1，其中包含了新版本的解密程序，这样后续发布加密固件时可使用新版本的解密程序进行解密。

以过渡版本v1.1作为分界线，我们分别对其前后版本固件的解密进行说明。

对于v2.0及更高版本的固件即过渡版本之后的固件（假设都使用同一种加密方案，无其它过渡版本）：与上述场景1中描述的一致，可以通过寻找过渡版本v1.1，从中分析出v2.0的解密方法从而对v2.0固件进行解密

对于v1.0及更低版本的固件即过渡版本之前的固件（假设都使用同一种加密方案，无其它过渡版本）：一是可购买实体设备，通过设备的调试接口或管理服务等直接从设备中提取解密后的固件。二是企商汇需设法获取内容完整的固件，直接对加密的固件进行分析，寻找包含在其中的解密算法。第三种方法则比较取巧，需要历史版本固件存在RCE漏洞可以获取到设备的Linux Shell，从而分析其固件升级逻辑获取解密算法。

说明：对于上述方法没有绝对的优劣势，需根据具体情况进行选择，对于有条件的小伙伴，推荐购买相应实体设备，一是有几率通过调试接口或管理服务等直接从设备上dump出解密后的固件，二是能从Flash中提取出包含解密方法的完整版固件，以便于后续的分析。

固件在出厂时加密，厂商决定更改加密方案并发布一个包含新版本解密程序的加密固件，这样后续发布加密固件时可使用新版本的解密程序进行解密。

此类场景发布的固件自始至终都是加密形态存在的，与上述场景中v1.1及之前的固件类似，常见的解密方法有3种，具体情况得具体选择。

2.2 设备启动流程中的加解密逻辑

接下来我们从设备启动流程来描述下固件的加解密逻辑。

首先我们来看看设备的启动流程：

上述的启动过程包含BootROM、SPL、BootLoader、Kernel、FileSystem五大部分，其中BootROM是由芯片厂商固化在芯片内的程序，设备厂商一般无法自定义，其余四块内容厂商都可进行定制，但对SPL进行加密的场景没有见过，这里不加以赘述。下表展示了常见情况下固件中的某块数据被加密后解密方法可能存在的位置：

类型

特点

被加密后由哪块数据负责解密

FileSystem

厂商核心数据

一般由BootLoader或者Kernel负责解密

Kernel

开源、可定制

一般由BootLoader负责解密

BootLoader

开源、可定制

SPL负责解密（SPL不能过大，难以植入复杂的解密逻辑）

2.3 固件更新流程中的加解密逻辑

接下来我们从设备固件升级流程来描述下固件的加解密逻辑。

固件更新流程如下：

从固件的更新流程中我们知道对固件的解密有2种情况，但由后台服务调用解密逻辑进行解密是比较常见的，所以在拿到文件系统后，如果想分析其解密逻辑以实现对其它版本固件的解密，可以从设备的固件更新功能入手来定位解密逻辑。

2.4 常见解密方法总结

从上述固件的发布场景、设备的启动和固件升级流程中，我们发现固件的加密情况有很多种，厂商会根据设备性能、应用场景、预算等多个条件来选择适合的加密方式，某些对安全性要求较高的产品如工控设备等往往还会采用硬件加密的形式，将解密算法存储在单独的芯片中，强行读取会导致芯片损坏。(PS:在本文中我们只讲述了一些常见的解密方法和技巧，大家有更好的想法或方法欢迎在评论区留言交流)

针对物联网终端设备的固件解密，我们总结了如下五种方法和技巧：

对于固件出厂时未加密，后续发布的固件是加密的情况，可以通过对比边界版本，解包最后一个未加密版本逆向升级程序还原加密过程，以实现对加密固件的解密。

如果设备存在UART、JTAG等调试接口，可通过连接硬件接口获取设备的Shell，从而dump出设备的固件。

对于可直接进入Linux Shell的情况，具体的操作可参考我们之前发布的《物联网终端安全入门与实践之玩转物联网固件（上）》一文。

但由于某些设备安全限制较高导致无法进入Linux Shell，我们可尝试进入BootLoader Shell（最常见的是Uboot Shell）对固件进行提取。这里要说明的一点是部分设备更新固件后会将解密后的新版固件写回Flash，这种情况下dump出的固件是未加密的，而相反的是部分设备Flash中的固件一直是加密状态存在，只是在每次设备启动时进行动态解密。所以此种方法提取出的固件可能也是加密的，但好处在于可以避免因拆解设备Flash去读固件导致设备损坏的风险，并且可以获取到较为完整的固件（官方下载的固件可能只是某块数据的更新包）。

对于有Telnet、SSH等服务的设备，可以通过这些服务进入设备的Linux Shell进行固件提取。服务一般在设备的web管理页面中可手动开启，但需要说明的一点是某些厂商会开发自家的CLI屏蔽掉底层Linux Shell，连接这些服务进入的Shell只是厂商的CLI，也无法提取文件系统，不过某些设备（光猫居多）的CLI存在可进入Linux Shell的命令，具体可自行在互联网上搜索相应的方法。

基于低版本固件RCE漏洞获取设备Shell分析解密逻辑实现对新版固件的解密

如果设备历史加密版本固件出现过RCE漏洞，可将存在漏洞的固件刷入设备，通过RCE漏洞获取设备Linux Shell，再分析其包含的解密逻辑，最终通过该解密逻辑实现对更新版本固件的解密。需要注意的是存在RCE漏洞版本的固件所使用的加密方案需要与新版本固件一致。

常见情况下固件的解密逻辑肯定是存在Flash中的，当获取到完整版固件（拆机从Flash读取或者从BootLoader Shell中提取等）后，可以直接对整个固件进行逆向分析寻找解密逻辑代码实现对固件的解密，但此种方法难度较大，并且这类设备安全性一般较高，很有可能分析出了解密逻辑但拿不到解密密钥，如密钥单独存放在某个安全芯片中。

0x03 解密实战

本章首先讲述一些判断固件是否被加密或压缩的方法，之后通过两个实例讲解不同场景下如何对物联网设备固件进行解密，由于篇幅限制，这里仅对上述解密方法中的其中2种辅以实例讲解，另外两种网上均有不错的分析文章，文末也会推荐相应的文章供大家学习。

3.1 判断固件是否被加密或压缩的方法

对于存在过渡版本的固件，可以通过阅读厂商所发布固件的Notes关键信息，能够帮助我们判断固件从哪个版本开始进行加密。

查看固件的熵值进行判断，熵是对随机性的一种度量，它的值在0到1之间，值越高表示随机性越好，接近1的值被认为是高熵，反之亦然，压缩或加密的数据具有较高的熵值。我们可以通过binwalk -E以图形化的形式查看加密和未加密固件熵值的变化，如下图1中未加密的固件熵值存在较大波动，而下图2中加密的固件熵值基本都保持在1。

3.2 实例一：DrayTek Vigor2962固件解密

一般拿到一个加密固件后，我们可以先从多个角度对其进行分析，不要急于购买设备或者拆解设备，或许互联网上就存在着你要想的那个key。

help

address offset

print Board Info structure

control

memory

TFTP protocol

an ELF image

boot image to flash

memory compare

information

memory copy

checksum calculation

disable data cache

TFTP protocol

Driver model low level access

Draytek ops

Use tftp client to get firmware then boot

echo args to console

edit environment variable

Write SoC eFuse entries

environment handling commands

exit script

a Ext2 filesystem

a Ext4 filesystem

s size

flattened device tree utility commands

Look up a filesystem type

control gpio pins

write memory to block device

usage

system

disable instruction cache

print header information for application image

image

compare

a symbolic link

a filesystem

Record file over serial line

address range

lzma uncompress a memory region

memory display

compute MD5 message digest

MDIO utility commands

MII utility commands

MMC sub system

display MMC info

boot image via network using NFS protocol

disk partition related commands

send ICMP ECHO_REQUEST to network host

print environment variables

pxe files

Perform RESET of the CPU

an environment variable

save file to a filesystem

save environment variables to persistent storage

environment variables

system

print local hushshell variables

什么是eMMC？

eMMC ( Embedded Multi Media Card) 采用统一的MMC标准接口，把高密度NAND Flash以及MMC Controller封装在一颗BGA芯片中。针对Flash的特性，产品内部已经包含了Flash管理技术，包括错误探测和纠正，Flash平均擦写，坏块管理，掉电保护等技术。用户无需担心产品内部Flash晶圆制程和工艺的变化。同时eMMC单颗芯片为主板内部节省更多的空间。

简单地说，eMMC=Nand Flash+控制器+标准封装

这里介绍以下Uboot Shell中常见的操作eMMC的命令：

常见的TypeID对应的文件系统如下表：

查看所有分区中的文件内容，发现rootfs.uboot.img的确存在分区2中。

分区1

分区2

分区3

分区4

交换分区，无法查看

分区5

分区6

在Uboot Shell中将eMMC的某分区中的文件读到内存中某个地址的方法如下：

从加载的地址处读取固定大小数据的方法如下

这里有个问题就是内存中读到了数据，如何保存？

尝试将数据保存到U盘上，提示报了Unsupported feature metadata_csum found, not writing.Uboot下ext4分区不支持metadata_csum和64位特性。

通过记录日志的形式：由于我们使用的是Xshell连接的串口，而Xshell自带了日志记录功能，所以需在使用md命令读取内存中数据前将日志启动，读取完成后将日志中记录的十六进制字符串转为二进制程序即可。

注：由于波特率只有115200，传输速度较慢，需要挂机跑一晚。

这里说明下为什么拿到文件系统后还需要进一步分析其解密逻辑：

官网固件是加密的，想要分析其它版本的固件，需刷入所需版本的固件后按照上述方法进行提取

由于波特率较低传输速率慢，单次提取耗时较长，我们花费了几乎1晚的时间，才完成了Vigor 2962某版本未加密固件的提取

分析出解密逻辑，可以直接使用该解密方法实现对其它版本固件的解密，这种以点带面的解密方法的使用，节省了大量的固件解密时间/设备采购成本

针对DrayTek Vigor2962固件的解密，首先尝试寻找过渡版本以及互联网搜索公开的解密方法未果，之后尝试通过自带的SSH、Telnet服务以及历史RCE漏洞获取Shell均未成功。之后，拆机连接UART串口也无法获取到Linux Shell。最终，利用Uboot Shell dump出eMMC分区中的未加密固件，继而分析其解密逻辑，实现了对Vigor 2962最新版本固件的解密。