本文将以施耐德昆腾系列PLC的NOE-711以太网模块的固件为例，讲解一下基于VxWorks操作系统的嵌入式设备固件的一些常用分析方法。

固件提取

通常我们能够通过设备厂商的官网获取到设备固件的升级包，从该升级包中将真正的固件进行提取后才能进行分析。提取固件的常用方法是使用Binwalk等二进制分析工具对固件升级包进行自动化分析，待确认升级包类型后再进行固件提取或其他操作。测试固件下载地址

通过Binwalk进行自动分析可以发现，NOE 771模块的升级包NOE77101.bin中内嵌了一个使用zlib压缩的文件。

通过调用Binwalk的-e参数进行自动提取后，Binwalk会把自动提取后的文件以偏移地址命名并存储在特定的目录中。

继续使用Binwalk对提取的385文件进行分析可以确认，该文件的确是我们所需要分析的VxWorks固件，因此提取的385文件也就是我们需要分析的固件文件了。

分析固件内存加载地址

为了对VxWorks系统固件进行逆向分析，我们首先必须要知道固件在内存中的加载地址。加载地址的偏差会影响到一些绝对地址的引用例如跳转函数表、字符串表的引用等。

下图是VxWorks系统在PowerPC架构下的内存分布图，如图所示VxWorks的系统固件将会被加载到一个由BSP (Board Support Package)定义的内存地址中。

方法一 通过封装的二进制文件头直接识别加载地址

某些设备的固件会使用某种格式进行封装，比较常见的是使用ELF(executable and linkable format)格式进行封装。采用ELF格式封装后的文件头部有特定的数据位记录了该固件的加载地址，因此针对该情况我们可以直接使用greadelf等工具直接读取ELF文件头，从而直接获取到固件的加载地址，此外IDA也能直接识别ELF格式封装的VxWorks固件，无需额外处理即可进行自动化分析。

方法二 分析固件头部的初始化代码，寻找加载地址的特征

在很多情况下我们拿到的固件是没有采用ELF格式封装的，这时就需要我们通过对固件的某些特征进行分析来判断具体的加载地址。还是以施耐德的NOE 711固件为例, 在具体分析某个固件时首先我们需要知道目标设备的CPU架构，具体可以如下图所示通过binwalk -A指令来对固件的CPU架构进行分析，此外也可以用binwalk -Y指令来调用capstone反汇编引擎来进行辅助判断，不过我实际测试下来存在一些误报的情况会把NOE 711的固件识别成arm架构的。

在得知目标CPU架构后就可以使用IDA加载固件并对其代码进行初步分析。

下图是默认加载后的IDA界面，仅仅分析出了极少数的函数。接下来就需要根据固件头部的这段代码来寻找加载地址的特征。

在固件头部有如下图所示的一段有趣的代码，在r1和r3寄存器进行赋值后进行了跳转。

下图是PowerPC的寄存器用途说明，从图中可以看到R1寄存器是栈指针，而R3寄存器则是第一个参数。

现在回到我们之前看的固件头部代码处，这段代码相当于是先将栈地址设置为0x10000，将第一个参数(r3寄存器)设置为0x0，随后在栈上开辟0x10个字节的空间后跳转到当前地址+0x1cd34处执行。

根据VxWorks官网文档对对内存布局的描述，Initial Stack是usrInit函数的初始化栈。

而usrInit函数则是VxWorks系统引导后运行的第一个函数，再结合之前我们分析的那段代码，可以基本确定在大部分情况下第一个跳转的地址就是usrInit这个函数的地址。

随后我们再回忆一下之前看到的VxWorks PowerPC内存布局图可以发现，初始化栈的地址同时也是固件的内存加载地址，因此r1寄存器指向的0x10000就是我们所寻找的固件加载地址。

方法三 基于bss区数据初始化代码的特征，计算加载地址

另一个分析固件加载地址的常用方法是，找到bss区域的初始化代码后间接计算出固件加载地址。bss(Block Started by Symbol)区在VxWorks系统中主要用于存储一些当前未赋值的变量,在系统启动过程中VxWorks会使用bzero函数对bss区的数据进行清零 。

如下图所示我们可以得知VxWorks固件自身有三个section，text, data以及bss这三个部分共同组成了VxWorks固件.

从下图所示的内存布局中可以看到bss区紧跟着固件的text和data段之后，因此只要我们找到bss区清零的函数，分析出清零函数的结束位置及后将其减去固件文件的大小即可获得固件的内存加载地址。

接下来我们再看一下VxWorks中的userInit函数，从下图可以看到usrInit除了是系统引导后执行的第一个函数外，在这个函数中还会首先对bss区的数据进行清理。

对usrInit这个函数进行查看后，可以发现其中有不少的bl跳转函数。根据usrInit的描述，第一个跳转的函数就是负责初始化BBS区的函数。

下图是BSS初始化函数的代码，结合PowerPC的寄存器用途可知r3和r4寄存器分别是函数sub_18D59C的两个参数。r3的值为0x339418, r4的值为0x490D2C - 0x339418 = 0x157914相当于长度。因此我们可以得知0x339418就是bss区的起始地址，0x490D2C就是bss区的结束地址。

在得到bss区结束地址后，我们就可以进一步的计算出固件的加载地址，不过使用这个方法有一个前提条件就是提取出的固件文件本身是完整的，如果提取出的固件文件不完整这个方法则会失效。

上面介绍了三种比较常用的VxWorks固件加载地址分析方法，此外还有通过焊接UART接口查看系统引导过程的串口输出等各种其他非常规手段。在分析出固件加载地址后就可以使用新的加载地址重新加载固件进行分析了

下图是Windows下的IDA6.8中重新加载后固件的对比图，Mac 下的IDA 在修复了加载地址后还是只能关联识别出很少的函数。

利用符号表修复函数名

虽然IDA此时能够正确的识别函数及其调用关系，但依然无法自动识别出函数名，这对固件的分析工作造成了很大的阻碍。 此时可以查看固件在编译时是否编入了符号表，如固件编入了符号表那么我们就可以利用符号表中的内容来修复IDA中所显示的函数名。

通过使用binwalk可以帮助我们辅助分析VxWorks固件中是否编入了符号表，并识别出符号表在固件中的位置。如下图所示binwalk识别出的符号表地址在文件偏移0x301E74处。

如下图所示，VxWorks 5系列的符号表有他独特的格式，他以16个字节为一组数据，前4个字节是0x00，之后是符号名字符串所在的内存地址，后4个字节是符号所在的内存地址，最后4个字节是符号的类型，例如0x500为函数名。

基于符号表的特征，我们能够轻松的获取到固件中符号表的起始及结束位置。此时我们就可以使用IDA的api来修复函数名，这里将使用如下图所示的Python脚本。

完成函数名修复后的IDA界面如下图所示，通过修复符号表IDA识别出了8000多个函数。至此VxWorks系统固件的预处理工作就全部完成了，现在我们就可以根据函数名来对一些关键服务的代码进行静态分析了。

固件分析

在完成上述的一些预处理工作后，一个固件分析的入手点就是查看例如loginUserAdd等关键函数的调用关系。如下图所示loginUserAdd函数的用途是在登录表中添加一个用户，这个账号可以用于登录例如telnet及ftp等服务。

通过分析loginUserAdd函数的调用，可以看到在usrAppInit等函数中均调用了loginUserAdd函数。

再进一步查看loginUserAdd函数可以发现在这个函数中所添加的用户及密码哈希。此类方法也是用于发现后门账号的有效手段之一。

此外还可以关注某些服务的初始化函数，例如在usrNetAppInit函数中就可以发现许多网络服务的初始化函数调用。

至此VxWorks固件分析的常用方法就介绍完毕了，通过使用类似的分析方法，我们也能够在基于VxWorks的其他嵌入式设备的固件中发现一些有趣的信息，下面是其中的两个例子。

Reference

• Developing PowerPC Embedded Application Binary Interface (EABI) Compliant Programs
• Reference Materials VxWorks for PowerPC
• usrConfig
• loginLib

snmp-set fuzzer是一个用于对目标设备的snmp可写oid节点数据进行Fuzz的小工具。项目的地址是https://github.com/dark-lbp/snmp_fuzzer

为什么要编写snmp-set fuzzer这个工具

• 在对许多工业控制设备进行安全测试时发现大量的设备默认开启了snmp服务并支持snmp写操作，且部分设备使用了默认的snmp community值且无法修改。
• 希望有一个相对灵活且自动化的小工具能够对这些开放了snmp写权限的设备进行检测从而评估设备的安全性。

如何使用snmp-set fuzzer

在对目标设备进行fuzzing之前我们, 我们首先需要对目标设备的可写OID节点进行扫描，snmp-set fuzzer会使用snmp-get-next请求来遍历所有的oid节点，通过将获取到的数据使用snmp-get请求写回目标设备并根据返回值来判断该oid节点是否可写。

下面是对某个设备进行oid节点扫描并将扫描结果进行保存的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

>>> from snmp_set_fuzz import *
>>> target = '192.168.70.50'
# 定义用于监控设备存活的TCP端口
>>> port = 80
# 定义每个oid节点Fuzz的次数
>>> count = 10
# 获取与目标设备连接的网卡名
>>> nic = conf.route.route(target)[0]
# 创建SnmpTarget，定义各个参数
>>> Target = SnmpTarget(name='test', monitor_port=port, community='private',
 oid='.1.3', version=2, target=target, nic=nic, fuzz_count=count)
# 扫描目标设备的snmp oid信息
>>> Target.oid_scan()
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.1.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.2.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.3.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.4.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.2.1.1.4.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.5.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.2.1.1.5.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.6.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.2.1.1.6.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.1.7.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.1.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.1.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.2.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.3.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.4.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.5.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.6.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.2.1.2.2.1.7.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.2.1.2.2.1.7.0 is writeable
..............
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.3.1.1.1.1.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.3.1.1.1.2.0
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.3.1.1.1.3.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.3.1.1.1.3.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.3.1.1.1.4.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.3.1.1.1.4.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.4.1.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.4.1.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.4.2.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.4.2.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] Found oid :1.3.6.1.4.1.95.2.4.3.0
[INFO    ][snmp_set_fuzz.oid_scan] 1.3.6.1.4.1.95.2.4.3.0 is writeable
[INFO    ][snmp_set_fuzz.oid_scan] End of MIB
# 保存扫描的结果
>>> Target.save_scan_result()
>>> # This cmd will save all result to ./output folder.

snmp-set fuzzer也同样支持从保存的pcap数据包文件直接获取可写oid节点清单。

1
2
3
4
5
6
7
8
9
10
11
12
13

>>> from snmp_set_fuzz import *
>>> target = '192.168.70.50'
>>> port = 80
>>> count = 10
>>> nic = conf.route.route(target)[0]
>>> Target = SnmpTarget(name='test', monitor_port=port, oid='.1.3', version=2, target=target, nic=nic, fuzz_count=count)
>>> # 查看前目标的可写oid清单
>>> print(Target.set_packets)
>>> []
>>> # 调用read_test_case_from_pcap来获取可写oid节点数据
>>> Target.read_test_case_from_pcap('./output/192.168.70.50_snmp_set_packet_list.pcap')  
>>> print(Target.set_packets)
<192.168.70.50_snmp_set_packet_list.pcap: TCP:0 UDP:37 ICMP:0 Other:0>

在直接扫描或读取以前扫描生成的pcap文件获取到可写oid节点后，就可以使用snmp-set fuzzer进行fuzzing测试了。下面是执行fuzz的例子，测试过程中将基于各个可写oid节点的数据类型对写入数据进行随机变异后使用snmp-set请求发送给目标设备并对其反馈进行检测，当目标设备对某个写请求不进行反馈或反馈异常时，会对目标设备的存活进行检测。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

>>> from snmp_set_fuzz import *
>>> target = '192.168.70.50'
>>> port = 80
>>> count = 10
>>> nic = conf.route.route(target)[0]
>>> Target = SnmpTarget(name='test', monitor_port=port, oid='.1.3', version=2, target=target, nic=nic, fuzz_count=count)
>>> Target.read_test_case_from_pcap('./output/192.168.70.50_snmp_set_packet_list.pcap')
>>> Target.fuzz()
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 0/10
[WARNING ][snmp_set_fuzz.fuzz] Target not response with snmp set packet in packet NO.0,TestCase No.0
[INFO    ][snmp_set_fuzz.fuzz] Target is still alive!
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 1/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 2/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 3/10
[WARNING ][snmp_set_fuzz.fuzz] Set failed with error code: wrongLength (8) in packet NO.3,TestCase No.0
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 4/10
[WARNING ][snmp_set_fuzz.fuzz] Set failed with error code: wrongLength (8) in packet NO.4,TestCase No.0
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.0 5/10
[WARNING ][snmp_set_fuzz.fuzz] Set failed with error code: wrongLength (8) in packet NO.5,TestCase No.0
........
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 4/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 5/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 6/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 7/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 8/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.4 9/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.5 0/10
[INFO    ][snmp_set_fuzz.fuzz] Running test case No.5 1/10
[WARNING ][snmp_set_fuzz.fuzz] Target not response with snmp get packet in packet NO.1,TestCase No.5
[ERROR   ][snmp_set_fuzz.fuzz] Can't Connect to Target at TCP Port: 80
>>> # 目标设备已崩溃
>>> # 调用save_fuzz_result来保存fuzz结果到./output目录
>>> Target.save_fuzz_result()

工控设备默认开启SNMP的危害

在以往的测试过程中通过snmp-set fuzzer发现过一些工控设备的漏洞，主要集中在对snmp写操作的数据没有进行有效的校验。例如某设备支持通过snmp写操作来修改设备网卡的mac地址，但是没有对mac地址的长度进行校验，只要传入过长或者过短的mac地址都会造成设备瘫痪。还有些设备的网卡可以通过snmp写操作来开启和禁用，这样直接就会造成设备的网络中断影响业务。此外通常厂商还会有其自定义的私有oid节点，这些节点也很可能会存在一些安全问题，导致设备出现各种预期外的异常。

在使用shodan对开启了snmp服务的控制设备进行了简单的搜索后可以发现，目前网络上还是有不少开启了snmp服务的控制设备直接暴露在互联网中，如果这些设备对snmp写操作没有进行有效控制的话，将会面临极大的安全风险。下面是暴露在互联网上的开启了snmp服务控制设备截图。

SNMP协议在带来方便管理的同时也引入了一些安全性上的问题，这些问题在工业控制领域显得尤为突出，大量的设备默认开启SNMP协议且使用public、private等默认community值进行验证。因此如果在实际生产环境中不需要使用到SNMP服务的话，建议还是关闭SNMP的功能，

通过阅读Vxworks 5.5的mips官方文档可以找得到如下所示的一张图，图中对VxWorks在MIPS架构下的内存布局进行了描述，其中bss(Block Started by Symbol)区在VxWorks系统中主要用于存储一些当前未赋值的变量。

由于bss段的数据在固件中是没有进行赋值的未初始化数据，因此我们可以尝试从路由器实际运行的内存中dump出bss段信息，并将其还原到IDA中。

为了dump bss段的信息，首先我们需要知道bss段的起始地址及大小，这部分的信息我们可以通过分析VxWorks系统的初始化代码进行实现。由于bss段存储的是未初始化的变量数据，因此在每次VxWorks系统加载过程中都会使用bzero函数对bss段的数据使用进行一次清除。

在IDA中我们可以通过追踪VxWorks的启动函数usrInit->sysStart来找到这段初始化bss段的代码。

此时我们就可以使用串口通讯dump处0x8024BB00至0x802A07B0的数据了。

dump完成后即可编写idapython脚本还原bss数据，还原代码如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import idc
import idaapi
import idautils


bss_dump_path = 'path of bss_dump'
bss_dump_data = open(bss_dump_path, 'rb').read()
bss_start_address = 0x8024BB00
bss_end_address = 0x802A07B0

# Add segment
idc.AddSeg(bss_start_address, bss_end_address, 0, 1, 4, 0)
idc.RenameSeg(bss_start_address, ".bss")
idc.SetSegClass(bss_start_address, ".bss")

for offset in range(len(bss_dump_data)):
    idc.PatchByte(bss_start_address + offset, ord(bss_dump_data[offset]))

还原bss区的变量数据对使用IDA进行静态分析还是有很大的帮助的，例如在还原bss段数据前所有对bss段的引用数据都为空无法辅助判断该地址的用途。

在还原bss段数据后，bss段的变量引用就可以通过变量的数据来辅助判断程序的处理逻辑。

同样的有些函数的地址是保存在BSS区的，如果我们不修复BSS区的数据那么在分析例如下图所示的一些函数时将会造成不少的困难。

通过导出路由器的BSS区数据可以更方便的辅助我们使用IDA等工具对设备的固件进行静态分析，此外如果遇到了未导出的地址也可以通过串口读取对应地址段的数据在IDA中使用类似的方法进行扩充。

焊接串口调试

在主板上焊接引脚后，可以通过使用万用表测量等方法确定GND、TX、RX等接口，随后即可使用TTL转USB的转换接口查看串口信息。

连接TTL-USB转接口

连接TTL-USB转接口的具体接线方法如下，需要将路由器和TTL-转接口的TX,RX口反接。

这里遇到了一个坑，之前使用的转接口是PL-2303HX芯片的转接口，发生了各种诡异的情况导致无法正常的使用。最后查了网上的各种资料，推荐使用FT-232芯片的转接口说是兼容性比较好，换上新的转接口后果然能够正常使用了。

使用任意串口通讯软件打开串口后即可看到类似如下内容的串口信息。

此时如果设备的接线正确，就可以通过键盘输入?键获取VxWorks的CmdTask命令行(前提是VxWorks固件中编入了这个模块)。

cmd命令说明

在对这些cmd命令进行了尝试后，发现了一些有用的命令，下面会列举一些命令进行简单说明。

• tftp - tftp命令行工具。
• mem - 内存操作相关的命令行工具。
• flash - flash相关的命令行工具。
• net - 网络相关的命令行工具。
• system - 系统命令相关的指令

tftp 命令行工具说明

tftp命令行支持的功能如下图所示。这个命令看起来非常美好，我们既可以通过tftp -put指令直接上传路由器的内存信息，也可以通过tftp -get指令从tftp server中下载数据写入到特定的内存地址中。

然而在实际使用中遇到了各种奇怪的问题，tftp -put指令一直无法正常使用，总是返回如下的错误信息。

通过对请求的数据包进行分析后发现了一些怪异的情况，下图是一个正常的TFTP写请求数据流。

下图是路由器实际发送的数据包，可以看到服务器返回了TFTP的ACK请求，但是路由器却没有对其进行响应，不断的重新发送写请求。由于固件中没有编入WDB调试模块，因此在无法对tftp进行调试的前提下只能先放弃使用tftp 命令行dump路由器内存的想法。

当然tftp -get命令也是类似的错误。

mem 命令行工具说明

mem命令行支持的功能如下图所示

使用mem -dump命令可以查看设备中的内存信息，不过串口输出的内存信息不是很稳定，经常因为各种原因导致格式错乱。

使用mem -md命令可以对内存中的数据进行修改。

可以看到通过mem内存操作命令行工具，已经可以实现诸如内存dump及打二进制patch修改程序逻辑等功能。

如下图所示，通过编写脚本模拟串口操作即可实现dump特定内存信息的效果。在脚本编写过程中也遇到过一些坑，例如dump的内存信息经常因为路由器的一些其他输出信息导致格式错乱，或在某些特定情况下会出现CmdTask崩溃或卡死导致输入无响应等异常情况需要处理。

flash 命令行工具说明

flash命令行支持的功能如下图所示, 可以通过这些命令对flash进行读写等操作。

对于Flash的写操作需要慎重，该操作很有可能会影响到路由器的正常启动，导致设备异常。其他还支持例如查看flash存储的布局信息的命令flash -layout。

net 命令行工具说明

net命令行支持的功能如下图所示, 可以通过这些命令对TCP/UDP的运行时信息进行显示。

通过使用net -show命令即可查看路由器的TCP/UDP端口使用情况，方便后续进行针对性的测试。

system 命令行工具说明

system命令行支持的功能如下图所示, 可以通过这些命令执行诸如系统重启，重置，设置debug级别等相关操作。

根据帮助功显示的功能来看system命令本身也比较简单，但是在对固件中cmd指令处理的函数进行分析后发现了有趣的事情。CmdTask模块所支持的指令是通过如下图所示的代码进行添加的，通过调用cmdAdd可以添加命令行所支持的指令。

因此只要查看一下所有的cmdAdd调用信息就可以找到命令行所支持的全部指令及指令解析函数逻辑。下图是sytem函数的指令添加代码。

指令解析函数sub_80159CE4中会对指令的参数等进行判断，下图是system命令行中对应的参数解析代码。

再确认一下system命令的帮助输出，帮助中的确是没有moduletree这个参数的。

执行一下试试，结果的确有输出，输出还挺有趣的涉及到了http请求中传输的一些json数据内容，这部分将在后续的文档中进行说明。

经过测试除了moduletree参数system指令还有一个-symble的指令，该指令输出的结果如下。会把系统中的符号信息进行输出。

至此，路由器cmd命令行的获取及使用方法介绍就结束了，通过分析可以看到命令行的帮助有时并不会将所有的命令行指令进行说明，通过分析命令行处理相关的代码，有时会有一些额外的惊喜等着我们。

系统固件通常会以一定的格式封装在固件升级包中。为了提取系统固件可以先使用Binwalk对wr886nv7.bin进行初步分析。

从上图可以看到，除了一个比较明显的uImage header头以外这个升级包中还有一大堆的LZMA数据信息。通过使用binwalk或直接使用dd命令能够对升级包中的uimage镜像进行提取。

1
2

# count长度应该是header + lzma包的长度
dd if=wr886nv7.bin of=uboot_0x366C.img bs=1 skip=13932 count=20852

使用binwalk继续分析uboot的镜像，可以发现这个uboot镜像的Data部分使用了LZMA进行压缩。

解压uboot的LZMA数据

1

dd if=uboot_new.img of=uboot.lzma bs=1 skip=64

由于uboot image中缺乏符号表且大小只有52K不到，因此此处暂时不对其进行进一步的分析。

VxWorks 系统固件分析

在wr886nv7.bin中除了uImage外，还有一个2M多的有趣的lzma压缩数据。

从升级包中提取该0xA200压缩数据并解压。

1
2
3
4

# count 是0xc317e - 0xa200
dd if=wr886nv7.bin of=A200.lzma bs=1 skip=41472 count=757630
# 使用lzma进行解压
lzma -d A200.lzma

使用Binwalk查看解压出的数据后发现这个文件很可能就是路由器所运行的系统固件，VxWorks系统版本5.5.1.

固件加载地址分析

在对0xA200地址之前的一些数据进行分析后可以看到一个疑似uimage header的数据段，其中有两处地址指向了0x80001000，这个地址也和很多同类路由器设备的固件加载地址相同，因此我们可以尝试使用该地址作为固件加载地址进行分析。

使用IDA加载固件进行分析

在使用IDA加载前，首先我们需要确定CPU架构及加载地址。CPU架构信息已经在升级包中的uimage header中进行了定义，同时我们也可以使用binwalk -Y命令进行识别。

加载地址的话，在前面的分析中已经初步可以判定为0x80001000，下一步就是使用IDA对固件进行加载分析了。在IDA中加载VxWorks固件。

在IDA中填写固件加载地址信息0x80001000。

成功加载固件后的IDA界面大致如下图所示，可以看到默认加载的情况下还是有大量的函数。

尝试修复函数名

通过初步对加载的VxWorks固件进行分析后发现，这个固件中并没有编入符号表，这对后续研究产生了很大的影响。再次对固件升级包中的内容进行分析后发现，有一个格式为data的文件很有趣。

1
2
3
4
5

# 使用binwalk -e 默认提取升级包中的文件。
binwalk -e wr886nv7.bin
# 进入目录后查找，是否存在包含VxWorks关键函数名的文件。 
cd _wr886nv6-20180123.bin.extracted
grep -r bzero ./

在对C4FAB的内容进行查看后发现有惊喜，文件中保存的数据很像独立的符号表，其中找到了大量的VxWorks关键函数名。

在对这个文件进行了初步的分析后发现这个文件还是有很明显的特征的。

根据这个独立符号文件的特征，我们可以编写对应的ida_python脚本来对固件进行修复。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

# coding=utf-8
import idc
import idaapi
import idautils
sym_file = open("PATH OF SYM FILE", 'rb').read()


table_data = sym_file[0x08:0x9f80]
print(table_data[-8:].encode('hex'))
string_table = sym_file[0x9f80:]


def get_string(offset):
    string = ""
    while True:
        if string_table[offset] != '\x00':
            string += string_table[offset]
            offset += 1
        else:
            break
    return string


def get_sym_data():
    sym_data = []
    for offset in range(0, len(table_data), 8):
        table = table_data[offset: offset + 8]
        flag = table[0]
        # print('flag: %s' % flag)
        string_offset = int(table[1:4].encode('hex'), 16)
        # print('string_offset: %s' % string_offset)
        string = get_string(string_offset)
        # print('string: %s' % string)
        target_address = int(table[-4:].encode('hex'), 16)
        # print('target_address: %s' % hex(target_address))
        sym_data.append([flag, string, target_address])

    return sym_data

def fix_idb(sym_data):
    for sym in sym_data:
        flag, string, target_address = sym
        idc.MakeName(target_address, string)
        if flag == '\x54':
            print("Start fix Function %s at %s" % (string, hex(target_address)))
            idc.MakeCode(target_address)
            idc.MakeFunction(target_address, idc.BADADDR)
            # print('flag: %s' % flag)
            # print('string: %s' % string)
            # print('target_address: %s' % hex(target_address))




if __name__ == '__main__':
    sym_data = get_sym_data()
    fix_idb(sym_data)

脚本运行后固件看起来就清晰了很多。

至此，固件分析的预处理工作就成功完成了，此时固件中依然还有很多很函数无法被正确被识别，还需要后续的一些操作进行手动修复。基本修复后的IDA界面会像下图所示, 具体的修复方法将会在后续的文档中进行说明。

根据固件及设备分析后修复的segments信息