2017, Vol. 63
文章信息
- 朱晓东, 尹青, 常瑞, 张胜桥
- ZHU Xiaodong, YIN Qing, CHANG Rui, ZHANG Shengqiao
- 基于结构化特征库的递进式固件格式解析
- Structured Feature Library-Based Progressive Firmware Format Parsing
- 武汉大学学报(理学版), 2017, 63(2): 125-132
- Journal of Wuhan University(Natural Science Edition), 2017, 63(2): 125-132
- http://dx.doi.org/10.14188/j.1671-8836.2017.02.005
-
文章历史
- 收稿日期：2016-05-06
引用本文
|
随着信息技术的进步，嵌入式设备越来越多地出现在了家庭、企业和许多关键领域中，比较常见的设备有以路由器、交换机、防火墙为代表的网络设备，以智能手机、平板电脑、USB存储设备为代表的个人媒体终端，以复印机、打印机、传真机为代表的办公设备，以及以PLC (programmable logic controller)、RTU (remote terminal unit) 为代表的工控设备等.这些设备处理和存储的信息往往是极其关键的，所以对于其固件的安全要求变得越来越高.
然而，固件的安全面临着很大的挑战.一方面，设备厂商没有给予安全足够的重视，固件发布之前缺乏足够的安全检查，包含大量已知漏洞，即使对于已公开的漏洞也没有及时发布相应的补丁；另一方面，出于安全考虑所进行的固件完整性检验反而阻碍了第三方补丁的开发.因此，进行固件安全性分析便显得尤为重要.
目前，国内外对于嵌入式设备固件安全性分析的研究已有很多成果.2010年，Delugré[1]逆向了博通 (Broadcom) 以太网卡的固件，并在设备上实现了简单的动态调试；Chipounov和Candea[2]提出了一种逆向网络设备驱动的工具DevNIC，可以自动逆向驱动的逻辑，生成新的设备驱动程序代码.2011年，Duflot等[3]提出了一种在固件运行时进行完整性验证的方法；Cui等[4]提出了一种利用软件共生体提高嵌入式系统安全性的方法.2012年，Blanco和Eissle[5]通过修改博通网卡的固件，提供了一种对管理、控制和数据帧进行捕获功能的“监控模式”，对网卡的功能进行了全面的控制.2013年，Zaddach等[6]提出了一种快速检测和分析固件的方法，并通过希捷硬盘固件和威康网络摄像头960系列固件的逆向，展示了手动的固件分析过程；Cui等[7]研究了针对惠普打印机远程固件更新的固件修改漏洞的分析和利用，通过标准的打印文件进行任意的恶意软件注入，并展示了373个激光打印机固件镜像的第三方库中存在的漏洞，说明了固件更新签名不能起到很好的安全效果；Basnight等[8]研究了可以用来进行恶意固件修改的PLC漏洞，揭示了对PLC设备固件进行修改的可行性及威胁程度.2014年，赵亚新等[9]针对基于JTAG的嵌入式设备固件动态分析技术进行了研究，对固件的动态分析与调试具有启发意义.2015年，Shoshitaishvili等[10]提出了一个嵌入式设备固件分析平台Firmalice，用来分析认证绕过漏洞.2016年，Zhu等[11]提出了一种ARM架构下确定固件镜像加载地址的分析方法；Chen等[12]提出了基于Linux的嵌入式固件自动化动态分析平台FIRMADYNE，可以对小端ARM、小端MIPS和大端MIPS的固件进行动态化分析.
固件格式解析是研究固件安全的基础，只有正确识别固件格式，获取指令集、引导代码、内核、文件系统、压缩算法、校验机制等信息，明确固件提供的函数库、交叉编译器版本，才能搭建漏洞分析和补丁开发环境，最终提高固件的安全性.现有的固件格式解析技术往往依赖于研究者的经验，只能通过手工操作，或是对特定的某个类型或某几个类型的固件进行分析.
本文提出了一种基于结构化特征库的递进式固件格式解析方法，在大量分析研究各嵌入式设备厂商固件格式的基础上，对固件镜像所反映出的多种特征进行综合分析，建立了常见固件格式的结构化特征库，并引入递进式算法最大限度地在没有源码的情况下准确解析二进制数据块的内部文件，从二进制数据集中提取出有意义的文件，识别固件中的Bootloader、Kernel、文件系统、配置文件、压缩数据等.
1 研究基础 1.1 嵌入式设备组成结构嵌入式设备由嵌入式处理器、外围硬件设备、操作系统和用户应用程序等部分组成，可看成是软硬件于一体的可独立工作的特殊“器件”.嵌入式处理器主要由一个单片机或微控制器 (MCU) 构成.外围硬件设备由存储器、电源、输入输出接口以及通信器件等组成.嵌入式设备与PC机相比，使用闪存 (flash memory) 作为存储介质，存储容量相对较小.用户应用程序包主要包括由厂商定制的应用软件、远程升级管理服务器、图形界面等.
硬件平台包括处理器和外围设备，它们位于嵌入式设备结构中的最底层.嵌入式操作系统与通用操作系统的功能类似，为用户屏蔽硬件层的具体细节提供了一个透明的操作空间.应用层软件则位于嵌入式操作系统之上，用户也可直接在操作系统上进行开发.
1.2 嵌入式设备固件格式固件一般由头部和数据两部分组成.固件文件头部存储了与整个固件相关的信息，如固件版本、固件生产日期、固件大小、校验和等.数据部分包含引导程序 (Bootloader)、压缩的内核代码 (Kernel)、根文件系统 (RootFS)、配置文件等.一般的固件文件格式如图 1所示.
|
| 图 1 嵌入式设备固件组成 Figure 1 Embedded device firmware structure |
固件文件格式分析是固件逆向的前提，常见的固件格式包括Bin、Usr、Rfu等.
1) 固件头
一般情况下分析头部信息的数据就能够知道整个固件文件的结构.常见的固件头格式包括Trx Header、DLOB Header、ZynOS Header、IMG0(VxWorks) Header、TP-Link Header、Ciso VxWorks Header、Realtek Header等.
如Trx文件开头是28字节的头部，其余为数据部分.magic字段存放魔数 (magic)，即固件头部特征标识.len字段记录了整个固件文件的长度.crc32字段用于存放数据区的32位CRC32校验码.flag_version字段用于存放固件标识和版本信息 (0~15表示标志，16~31表示版本).offsets[3]数组存放内核、文件系统等各个部分在固件文件中的偏移.
2) 内核
常见的固件内核包括Linux、VxWorks、WinCE等.
最后生成的Linux内核镜像有zImage和uImage两种.其中zImage下载到目标板中后，可以直接用uboot命令“go”进行跳转.此时内核直接解压启动，但无法挂载文件系统.
uImage文件通过mkimage处理zImage文件生成，是Uboot专用的映像文件.它是在zImage之前加上一个长度为0x40的头，说明这个映像文件的类型、加载位置、生成时间、大小等信息.通过分析uImage头部结构能够获取有助于固件逆向的相关信息.
3) 文件系统
常见的嵌入式文件系统有Jffs2、Yaffs、Cramfs、Squashfs.
Cramfs是专门针对闪存设计的只读压缩文件系统.Cramfs文件系统根据目前读取文件的进度与位置，动态地将数据解压缩到内存中.Cramfs中不会保存文件的时间戳 (Timestamps) 信息.
Squashfs是一套基于Linux内核使用的压缩只读文件系统.该文件系统能够压缩系统内的文档、inode以及目录，通常采用Zlib和Lzma数据压缩算法.Squashfs压缩比例较高，其数据、inodes和目录都是经过压缩的，同时它还支持大端 (Big Endian) 和小端 (Little Endian) 两种格式，方便开发者根据硬件特征进行选择.
Jffs2是一种日志文件系统，能够在设备遭受不正常断电情况下保持数据完整性.
Yaffs是一种类日志文件系统，可在意外掉电重启后恢复数据记录.
2 结构化固件格式特征库 2.1 设计Linux系统下的file命令通过Magic签名文件中的规则识别文件的类型.基于这种思想，结构化固件格式特征库的总体设计思路是：采用自定义的Magic签名文件描述每类固件镜像的特征 (如固件头部特征、文件系统类型特征、压缩格式特征等)，每类特征使用单独的Magic签名文件进行存储，签名文件的每行为一条测试项，每条测试项从一个特定的偏移 (Offset) 开始比较.测试项之间引入从属关系，只有上级的测试项通过，才会比较次级测试项.如果全部测试 (主、从测试项) 通过，则会得到一条固件识别信息.每条测试项包含Offset、Type、Test和Message 4个域：
1) Offset
Offset是指被测试文件中的特定偏移位置，表示该测试项将从这里开始测试，类型为数字型或表达式.
2) Type
Type是指被测试位置的数据类型，有表 1所示的几种形式.
| 类型 | 意义 |
| byte | 一个字节 |
| short | 二字节，leshort表示小端字节序，beshort表示大端字节序 |
| long | 四字节，lelong表示小端字节序，belong表示大端字节序 |
| quad | 八字节，lequad表示小端字节序，bequad表示大端字节序 |
| string | 字符串 |
3) Test
Test测试项将本列的值与文件中的值进行比较，用于匹配固件特征库.如果类型是数值型，那么该值被指定为C语言格式；如果是字符型，则被指定为C语言格式字符串，并允许转义，如“\n”转义表示新行.
4) Message
如果比较测试通过，就输出固件识别信息Message.如果Message中包含格式化参数，那么来自文件的值将会使用Message中的格式化字符串进行输出.例如，测试项“0 string ELF elf file flag：%s”如果Test域匹配成功，则输出“elf file flag：ELF”.
测试项数值型前面的一个字符串表示可能要执行的操作，规则如表 2所示.“X”表示匹配任意值.数值型使用C语言格式，如11是十进制，011表示八进制，0x11是十六进制数.字符型值要求来自文件的字符串必须匹配指定的字符串.可用的操作符有“=”、“＜”、“＞”，匹配非空行 (>\0) 即大于空行.
| 字符串表示 | 执行的操作 |
| “=X” | 来自文件中的值必须等于X |
| “>X” | 来自文件中的值必须大于X |
| “ < X” | 来自文件中的值必须小于X |
| “!X” | 如果文件中的字符串不是“X”则测试成功 |
签名特征只起到识别文件系统类型的作用，识别文件系统类型后还需要提取其他特征进一步解析文件系统 (如解压缩内部文件).为了服务于递进式的固件格式解析，采用多级特征元识别的测试项设计方法，将可以决定后续特征匹配判定的签名特征作为主特征元，然后根据具体的文件类型添加能够描述文件系统特征的从特征元.在进行特征匹配时，只有在主特征元匹配成功后，才会对从特征元进行匹配，只有第一级的从特征元匹配成功后，才会对第二级的从特征元进行匹配，以此类推.在建立对应的测试项时，在Offset域前添加大于号“>”来表示当前测试项为从特征元的测试项.从属的层次关系用“>”的个数表示，个数越多层次等级越高.
以嵌入式设备常见的ELF文件编码格式为例进行进一步说明.在文件类型特征Magic签名文件中的部分描述如下：
|
在Magic签名文件的Offset列中，有的测试项在数值前面包含了一个或者多个“>”符号，以表示测试的等级 (或深度)，没有“>”表示0级.从上面的例子看，如果第0级的测试“0 string \177ELF”没有通过，会跳过大于0级的所有行，寻找下一个等级为0的行，即该文件剩下的行都不会执行.
另外，匹配Magic签名文件的测试项时，需要对分析文件的偏移位置进行定位，考虑检索的灵活性，将文件偏移位置的定位分为间接偏移的相对偏移两种类型.
间接偏移是指将从文件中获取的值作为偏移量，格式为：
(x. [bisl/BISL] [+-] [y])
“x”表示使用文件中位于x位置的值作为偏移，“[bisl]”指little-endian的byte/int/short/long，“[BISL]”指big-endian的byte/int/short/long.如“(0x3c.l)”表示从文件0x3c处获取lelong类型的值作为此处的偏移，“(0x3c.l+0x12)”表示从文件0x3c处获取lelong类型的值加上0x12作为此处的偏移.
相对偏移表示指定的偏移是相对上一个测试等级的偏移，格式为：& value.
“value”表示相对偏移的值.
2.2 建立递进式固件格式解析的基础是结构化固件格式特征库的建立，通过对各类固件的存储机制、头部信息、引导程序、内核结构、文件系统格式、压缩算法等组成格式进行逐层分析和特征提取，形成认知模型并组成结构化固件特征库，为固件格式识别提供特征描述、查询和推理支持.
1) 固件头部特征库
固件头部通常包括设备头部和固件格式头部两部分.设备头部包含固件创建日期、版本、厂商标识等跟设备厂家密切相关的信息，通过识别固件的设备标识信息可以获取设备类型、厂家等信息.固件格式头部包含魔数、长度、校验和、版本标志以及数据部分信息等字段，一般情况下，获取固件格式头部信息就可以知道整个固件文件的结构.图 2为Ciso无线路由器Wrt54G固件头部结构，为典型的Trx格式固件头部.从图中可以看出二进制数据头部有“W54G”的设备标识信息，在偏移0x20位置有“HDR0”的Trx固件小端格式头标识，之后有固件大小和固件校验信息.对固件解析帮助最大的部分为0x30~0x3b中offset字段的值，offset[0]=0x1C可能表示固件加载的偏移地址，offset[1]=0xA77D4附近可定位到文件系统位置.结合固件头部结构可以分析出该固件的基本信息，对固件的存储布局有一个初步的认识.
|
| 图 2 Trx固件头部结构 Figure 2 Trx firmware head structure |
根据特征设计规则，将Trx固件头部进行抽象和特征提取，其小端模式特征库建立如表 3所示 (大端模式Offset为0处的字符串为“0RDH”).
| Offset | Type | Test | Message |
| 0 | string | HDR0 | TRX firmware header, little endian, header size: 28 bytes |
| >4 | lelong | < 1 | invalid |
| >4 | lelong | x | image size: %d bytes |
| >8 | lelong | x | CRC32:0x%x |
| >12 | leshort | x | Flags:0x%x |
| >14 | leshort | >5 | invalid |
| >14 | leshort | x | version: %d |
固件头部特征表是对某一类型固件头部的概括，通过对不同类型的固件头部进行特征表建立，即可形成固件头部特征库.
2) 文件系统特征库
分析嵌入式设备主流文件系统的二进制形式，将签名总结如表 4所示.
| FS类型 | Offset | Type | Magic |
Squashfs |
0 | string | sqsh/ hsqs/ sqlz/ qshs/ tqsh/ hsqt/ shsq |
| Yaffs | 0 | string | \x03\x00\x00\x00\x01 \x00\x00\x00\xFF\xFF |
| Cramfs | 0 | lelong/belong | 0x28cd3d45 |
| Jffs2 | 0 | leshort/beshort | 0x1985 |
| MemFS | 0 | string | owowowowowowowowo wowowowowowow |
| Romfs | 0 | string | -rom1fs-\0 |
| Ext2/Ext3 | 0 | leshort | 0xEF53 |
除Squashfs外，其余文件系统的签名都比较固定，上述签名可作为识别文件系统类型的特征.其中Squashfs较为特殊，共有7个签名特征，设备厂商通常会对其进行自定义修改，不同特征代表的类型有所差异.sqsh/hsqs为标准的大/小端文件系统，sqlz为经过Lzma压缩的大端文件系统，qshs是3.3版本的Lzma压缩的大端文件系统，hsqt是DD-WRT固件常用的小端文件系统，shsq是D-Link路由器常用小端文件系统.
表 5总结的是Squashfs文件系统几个比较明显的从特征元，其中Offset列的 & value表示相对于主特征元位置的偏移.
| Offset | 数据类型 | 特征意义 |
| & 28 | short | version |
| & 20 | short | compression type |
| & 40 | quad | size |
| & 12 | long | blocksize |
| & 4 | long | inodes |
通过这几个从特征元基本可以对Squashfs文件系统进行较为完备的描述，不仅为解压和解包固件提供参考，还能获取blocksize、inodes等信息，为正确打包文件系统提供关键信息 (Squashfs文件系统打包需要提供blocksize、inodes等信息).
经过分析得出Offset=20处的从特征元可取不同的值，查询时满足其中一个值即可判断所表述的意义，类似于“if/else”判断语句，称这样的特征元为分支特征元.不同分支调用相应的解压函数进行尝试性解压，然后使用对应版本的文件系统解包工具解开二进制形式的文件系统，提取内部文件.
offset=28处的字段为关键从特征元，该值取值范围的不同将影响其余特征元的偏移位置，将这种特征元称为影响因子，记为t1.t1不仅表示版本号，而且不同的t1值会对其他特征元产生影响.当t1>3时，Squashfs以压缩形式存储在固件中，各偏移字段的意义如表 6所示.
| Offset | Type | Test | Message |
| >28 | short | >3 | compression |
| >>20 | short | 1 | gzip |
| >>20 | short | 2 | lzma |
| >>20 | short | 3 | gzip (非标准类型定义) |
| >>20 | short | 4 | lzma (非标准类型定义) |
| >>40 | quad | x | size |
| >>12 | long | x | blocksize |
| >4 | long | x | inodes |
当t1=3时，Squashfs可能被压缩，也可能没有被压缩，没有一定规律，具体情况需要手动进行分析解包.但在某些偏移位置存储的值仍然具有一定意义，如表 7所示.
| Offset | Type | Test | Message |
| >28 | short | =3 | ? |
| >>63 | quad | x | size |
| >>51 | long | x | blocksize |
| >4 | long | x | inodes |
特征库的建立体现高级语言的语法特点，分为不同的处理模块，根据影响因子的不同，调用不同的子模块处理，使用分级的思想模拟“if/else”判断语句，提高了特征查找的效率.
3) 压缩算法特征库
压缩算法的特征库建立实现较为简单，只需根据签名匹配，然后调用相应的算法进行解压操作即可.常见的压缩算法签名总结如表 8所示.
| 压缩算法 | Offset | Type | Magic |
| Bzip2 | 0 | string | BZhx1AY & SY (x为整数， 1≤x≤9) |
| Lzop | 0 | string | \x89\x4c\x5a\x4f\x00\ x0d\x0a\x1a\x0a |
| Lzip | 0 | string | LZIP |
| 7-zip | 0 | string | 7z\274\257\047\034 |
| Gzip | 0 | string | \x1f\x8b\x08 |
| Zlib | 0 | beshort | 0x789C，0x78DA，0x7801 |
| Lzma | 0 | string | \xFFLZMA\x00 |
| JAR | 0 | belong | 0xcafed00d |
固件格式解析建立在特征识别的基础上，对原始二进制固件代码进行各种形式的解包和处理.格式解析主要包括：固件头部识别、Bootloader类型识别、操作系统类型识别、压缩格式识别、文件系统侦查解析和指令集类型识别，并在识别这些类型的基础上提取固件中的文件，解读内部配置文件和代码功能，提取可供参考的关键信息.基于特征库的固件格式解析框架如图 3所示.
|
| 图 3 基于特征库的固件格式解析框架 Figure 3 Feature library-based firmware format parsing framework |
格式识别建立在特征匹配成功的基础上，目的是从表面上无差别的二进制数据块中分割出有意义的文件，得到固件中各主要模块的大致分布情况.
在2.1节提出结构化特征库设计规范时，引入了主从特征元的设计思想，各个测试项之间可以看成一个树形的层次结构，形成了一种“if/else”的逻辑关系.如果第n级测试成功，才会测试第n+1级，否则跳过等级为n+1的行直到下一个等级为n或者更低级的行继续执行.整个测试识别过程形成了一个递进式的特征匹配过程.具体的识别算法如Algorithm 1.
|
固件识别阶段已初步定位二进制数据块中的已知文件系统类型和压缩文件的偏移地址，接下来要做的就是根据识别结果完成固件解包工作.由于固件中可能存在文件嵌套压缩的情况，即从某个压缩数据文件中可以解压出多个新的压缩文件.而最初的识别阶段只能对二进制数据块做初步的分析，无法识别出第一层压缩文件内部包含的文件类型，这可能会导致无法完成固件的正确解包.
为了解决解包不彻底的问题，提出迭代式解包算法.具体过程为：在扫描识别压缩算法并使用相应的解压算法进行解压之后，将解压产生的文件继续作为输入，进行下一次的扫描识别，如果仍存在压缩文件等打包格式，则进行相应的解压，然后将产生的文件继续作为输入.这样就形成了一个迭代的扫描和解压流程，直到产生的文件中不再存在可识别打包文件.
出于安全考虑，某些压缩算法可能被厂商自定义修改，即使识别出压缩算法类型也无法准确定位压缩数据的偏移位置，无法解包压缩文件.为此，提出自定义的解包算法对该类压缩文件进行解包.具体过程为：识别出压缩算法后，取不同的偏移位置对压缩头部附近的数据进行尝试性解压，从而识别出厂商所自定义的压缩算法，完成解包工作.
固件解析还需要对固件文件进行解读，如目标设备的指令集类型、固件中使用的库函数信息、交叉编译版本、设备提供的可执行指令、操作系统类型及版本号、各文件内部的链接关系等都是需要解读的重要信息，最大限度地获取隐藏于固件中的有用信息.
Busybox是嵌入式设备下常用的工具集.Busybox根据配置脚本生成的配置文件.config将需要的命令模块编译到程序中，逆向还原该配置文件，从而确定设备提供的命令.
嵌入式设备rcS启动配置文件定义了文件系统挂载 (mount)、内核模块加载 (insmod)、web服务启动等命令.通过解读rcS文件可以了解内核启动流程及提供的服务.
4 固件格式解析效果测试 4.1 固件解析测试本文选取了10款不同的设备固件作为测试数据，分别是S3c2410实验箱 (通用嵌入式教学实验箱)、Mini2440开发板 (手机开发实验板)、TQ2440开发板、Ciso Wrt54G路由器、ZyXEL P-1302路由器、Planex路由器、DLink DIR-806路由器、HP 5200激光打印机、TP-Link TL-SC3130智能网络摄像机和360智能网络摄像机.
ZyXEL路由器固件解析结果如图 4.
|
| 图 4 ZyXEL路由器固件解析结果 Figure 4 Firmware parsing result of ZyXEL router |
对10款设备固件进行解析，解析结果整理后如表 9所示.
| 项目 | S3c2410 | Mini2440 | TQ2440 | Ciso | ZyXEL | Planex | DLink | HP Printer | TP-Link | 360 |
| 固件格式 | BIN | BIN | 无 | BIN | BIN | BIN | BIN | RFU | BIN | BIN |
| 架构 | ARM | ARM | ARM | MIPS | MIPS | MIPS | ARM | MIPS | ARM | ARM |
| 固件头 | 无 | 无 | uImage | Trx | 非标准 | 非标准 | DLOB | 无 | Ubiquiti | uImage |
| 内核 | Linux2.4 | Linux2.6 | Linux2.6 | Linux2.4 | Linux2.6 | Linux2.4 | Linux2.6 | 类Linux | Linux2.4 | Linux2.6 |
| 文件系统 | Ext2 | Yaffs | JFFS2 | Squashfs2.0 | Squashfs3.0 | Squashfs2.0 | Squashfs4.0 | Lynx | Ext2 | CramFS |
| 压缩算法 | Gzip | Gzip | 无 | Gzip | LZMA | LZMA | LZMA | Zlib、Gzip | LZMA | 无 |
| 校验机制 | CRC32 | CRC32 | CRC | CRC32 | CRC32 | CRC32 | CRC32 | CRC32 | CRC32 | CRC |
| 编译器 | Gcc2.9.3 | Gcc4.4.1 | Gcc3.2.3 | Gcc3.2.4 | Gcc4.3.4 | Gcc3.4.6 | Gcc4.5.3 | 非标准 | Gcc2.95.3 | Gcc4.5.3 |
| 支持库 | Glibc | uClib | Glibc | uClib | ZClib | uClib | uClib | ZClib | uClib | uClib |
从表 9中可以看出，除少部分非标准固件头格式外，对于10款不同的设备，均可以自动化地准确识别其固件的内核架构、固件头、内核版本、文件系统、压缩算法、校验机制、编译器和支持库等信息，相比于其他识别工具只能识别特定固件的特定信息，基于结构化特征库的递进式固件格式解析方法具有更大范围的适用性.
对于非标准固件头，未识别的原因是固件格式结构化特征库中没有相应的记录，因而在进行特征匹配时无法成功匹配.可见该识别方法的局限性在于识别结果依赖于固件格式结构化特征库的完备程度，可以在下一步工作中加入学习模块，自动在库中添加新类型.
5 结论本文提出了一种基于结构化固件格式特征库的递进式固件格式解析方法，通过建立常见固件格式结构化特征库，利用递进式特征匹配算法，可以对输入的固件文件进行自动化的解析，剥离出各部分的文件，获取其指令集、引导代码、内核、文件系统、压缩算法、校验机制等信息，并提取固件提供的函数库、交叉编译器版本等.最后利用10种来自不同型号开发板、实验箱、路由器、打印机、智能网络摄像机等设备的固件进行测试，结果显示该方法可以自动化解析不同的固件格式，提取多种有用信息，具有良好的自动化性能和适用性.
| [1] | DELUGRÉ G.Closer to Metal:Reverse-Engineering the Broadcom NetExtreme's Firmware[R/OL].[2015-10-25].http://esec-lab.sogeti.com/static/publications/10-hack.lu-nicreverse_slides.pdf. |
| [2] | CHIPOUNOV V, CANDEA G.Reverse Engineering of Binary Device Drivers with RevNIC[DB/OL].[2015-11-25].http://llvm.org/pubs/2010-04-EUROSYS-RevNIC.pdf. |
| [3] | DUFLOT L, PEREZ Y A, MORIN B.Run-Time Firmware Integrity Verification:What if You Can't Trust Your Network Card[DB/OL].[2015-12-25].https://www.ssi.gouv.fr/uploads/IMG/pdf/paper.pdf. |
| [4] | CUI A, STOLFO S J.Defending embedded systems with software symbiotes[C]//Recent Advances in Intrusion Detection.Berlin:Springer, 2011:358-377. |
| [5] | BLANCO A, EISSLER M.One Firmware to Monitor'em All[R/OL].[2012-10-25].http://ekoparty.org/archive/2012/BlancoEissler_2012-paper.pdf |
| [6] | ZADDACH J, COSTIN A.Embedded Devices Security and Firmware Reverse Engineering[R/OL].[2015-08-11].http://s3.eurecom.fr/docs/bh13us_zaddach.pdf. |
| [7] | CUI A, COSTRLLO M, STOLFO S J.When Firmware Modifications Attack:A Case Study of Embedded Exploitation[C/OL].[2015-12-26].https://pdfs.semanticscholar.org/55b9/7032a03aeaca9fd3fdcb87baa789a1f968b6.pdf. |
| [8] | BASNIGHT Z, BUTTS J, LOPEZ J, et al. Firmware modification attacks on programmable logic controllers[J]. International Journal of Critical Infrastructure Protection, 2013, 6(2) : 76–84. DOI:10.1016/j.ijcip.2013.04.004 |
| [9] | 赵亚新, 郭玉东, 舒辉. 基于JTAG的嵌入式设备固件分析技术[J]. 计算机工程与设计, 2014, 35(10) : 3410–3415. ZHAO Y X, GUO Y D, SHU H. Analysis technology of embedded device firmware based on JTAG[J]. Computer Engineering&Design, 2014, 35(10) : 3410–3415(Ch). |
| [10] | SHOSHITAISHVILI Y, WANG R, HAUSER C, et al.Firmalice-Automatic Detection of Authentication Bypass Vulnerabilities in Binary Firmware[C/OL].[2015-11-26].https://www.lastline.com/papers/2015_ndss15_firmalice-2.pdf. |
| [11] | ZHU R, TAN Y, ZHANG Q, et al. Determining image base of firmware for ARM devices by matching literal pools[J]. Digital Investigation, 2016, 16 : 19–28. DOI:10.1016/j.diin.2016.01.002 |
| [12] | CHEN D D, EGELE M, WOO M, et al.Towards Automated Dynamic Analysis for Linux-based Embedded Firmware[C/OL].[2015-09-26].https://www.internetsociety.org/sites/default/files/blogs-media/towards-automated-dynamic-analysis-linux-based-embedded-firmware.pdf. |