【文章首发于IOTsec-Zone】
拿到固件后binwalk查看一下相关信息（wwwroot/conf/exec/NOE77101.bin）

发现没有什么可利用信息后直接进行提取文件

最终发现有两个文件，并且其中一个是vxworks系统文件

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

binwalk -A 查一下架构

可以看到是ppc架构大端

ida32打开固件进行分析，选择ppc架构

加载基址目前可以先不用管（不知道），一路回车即可


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

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

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

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

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

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


可以看到识别出的基址和我们之前计算得到的是一致的，并且之后还会自动识别函数以及对函数名进行恢复

（PS：最终还利用了FirmwareFix插件来对字符串进行恢复）

最终在usrAppInit发现有硬编码账户的存在（vxWorks提供了一个用户接口usrAppInit，所以可以直接从该函数看）