【文章首发于IOTsec-Zone】
拿到固件后binwalk查看一下相关信息(wwwroot/conf/exec/NOE77101.bin)
image.png
发现没有什么可利用信息后直接进行提取文件

最终发现有两个文件,并且其中一个是vxworks系统文件
image.png

在末尾也可以看到使用的VxWorks的内核版本为2.5,并且自带了符号表

binwalk -A 查一下架构
image.png
可以看到是ppc架构大端

ida32打开固件进行分析,选择ppc架构
image.png
加载基址目前可以先不用管(不知道),一路回车即可
image.png

image.png
进入后发现由于ida不知道入口点在哪儿,所以一个函数也没有识别出来

结合VxWorks的官方文档可以知道vxworks最开始的代码时对栈进行初始化,完成后会跳转到usrInit,即vxworks系统引导完成后的第一个函数。我们来对最凯斯的代码进行分析

首先在最开始处按c使ida将最开始的数据识别成函数
image.png

结合刚才所知内容与汇编代码相结合分析,最后跳转的loc_1CD94应该为usrInit函数,它上面有两个操作:1.设置r1=0x00010000,2.设置r3=0
r1寄存器为ppc中的栈寄存器,r3则是参数寄存器
image.png

由此可知栈在一开始便被抬高了0x10000,加载偏移即为0x10000
关闭ida,清除数据库重新打开固件
在设置加载基址后一路回车即可
image.png

但是此时IDA还是不能很好的识别出所有函数,和之前的差别不大,所以考虑使用vxhunter脚本来进行恢复,将py3版本的脚本下载好后放入ida的plugins目录中进行使用
image.png

image.png
可以看到识别出的基址和我们之前计算得到的是一致的,并且之后还会自动识别函数以及对函数名进行恢复
image.png
(PS:最终还利用了FirmwareFix插件来对字符串进行恢复)

最终在usrAppInit发现有硬编码账户的存在(vxWorks提供了一个用户接口usrAppInit,所以可以直接从该函数看)
image.png

Q.E.D.


来都来了,点个广告再走吧(=・ω・=)