问题多又多
记一次痛苦的VxWorks路由器漏洞挖掘
路由器很老了，是Mercury MW300R的某个版本，网上找不到固件，所以最开始想用uart进shell
拆开过后可以快速找到UART引脚
UART调试
I 打开UART
路由器断电，然后把万用表调到测接地，黑笔随便找一个电路板上的接口（我用的wifi天线的），红笔测口子，响的那个就是接地
接着路由器连上电源，万用表调到测电压，黑笔随便找一个电路板上的接口，红笔挨个测试接口
- 如果为3.3V左右，那么是电源线（3.3V）
- 如果为0V，为接地（GND）
- 如果为2.5V左右，为TXD（路由器的Write）
- 如果不断跳动，为RXD（路由器的Read）
然后第一点不寻常的就来了
我在测试的时候只能通过排除法筛选出了RXD，我的RXD一直为0V
这个时候通过
1 | FT232: 3.3V -> 路由器: 3.3v |
插上路由器电源线，但是不插插头，通过串口就能连上了
但是会发现无法输入，导致设备一直重启，在这个地方无法停下autoboot，很显然需要输入来打断
但是路由器的RXD一直为0V，说明并没有开启向路由器写入的功能，通过仔细观察电路，发现RXD出口有下面几个接口，不断测试发现RXD可以在下方的焊点使用
但是我没有架子，而且焊点太小了（本人电烙铁太菜），所以折弯了一根曲别针来传信号
II 开始调试 A
能用的功能特别少，而且tftp功能用不了，不过md可以查看内存
其实这里可以参考这篇博客进行dump提取的，但是当时没想到。
III 开始调试 B
在进入uboot的时候发现ctrl+C会打断一个TP-Link的shell
后续发现插上插头后有概率会停在这里
使用命令查看内存分配
1 | flash -layout |
看到这里我才明白最开始进的是uboot的控制窗口，这里才是真正的Flash存储的启动点
修改了这篇博客的脚本按照一样的思路试图提取固件出来，但是binwalk没有任何识别，所以UART走到尽头了
CHA341A法
就是传统的飞线法，路由器上能用芯片夹的就两个芯片，用CHA341编程器读取一下就知道了（记得装驱动）
关于组装可以看这篇
芯片没有识别到，但是重要的是芯片存储的大小，通过上flash layout可以看到总空间大小是1024KB=1MB，选择大小为1MB的芯片就好了
用binwalk看一下，发现是VxWorks的系统，而且根本就没有Unix/Linux的文件系统，而是使用了Wind River 文件系统，怪不得所有东西都是一坨，而且知道了程序入口是0x80001000
可以参考这篇来慢慢提取，不过也可以直接
1 | binwalk -Me MW300R.bin |
看上去挺多的，其实根本不慌，随便看一个
再看看Wind River那段的数据，按顺序就对对应的不同文件了
可以按照对应的格式写脚本提取，不过本文的中心并不在这儿。
在提取的时候发现
把49200文件特殊看一下
恭喜，找到了主要文件的
用ida 32位 MIPS大端序打开
根据前文提到的入口地址0x80001000设置入口
在开头按下C就IDA就开始自动分析了
漏洞挖掘
上面的二进制分析起来还是有难度的，不过用常规思路（包括web）即可
比如一个很明显的DOS洞，很明显只做了前端校验
直接把路由器打崩，得重启才能恢复正常工作
引用
https://e3pem.github.io/2019/07/03/IoT/提取tl-wdr5620固件/
https://blog.quarkslab.com/reverse-engineering-a-vxworks-os-based-router.html