针对Belkin Surf N300路由器的硬件逆向研究

SuperTask! RTOS是一种实时操作系统，2018年底，两名安全研究人员在该系统的某个版本中发现了一系列的安全漏洞。其中，在受这些漏洞的影响的设备列表中，就包括 Belkin Surf N300路由器（型号为F7D2301) 。

本文中的大部分材料取材于上面两位安全研究人员编写的报告，之所以写作本文，是为了复现和验证他们的研究过程，并从中汲取经验教训。虽然这些安全漏洞仍处于披露阶段，但我们希望分享我们在嵌入式软件漏洞研究中所学到的知识。在本文客中，我们将为读者详细介绍 JTAG工具 的配置、将其附加到目标机器并运行GDB的具体过程。

准确来说，我们已经在型号为F7D2301、硬件版本为1的Belkin Surf N300路由器上对这些漏洞进行了相关的测试。

该路由器使用802.11n技术，可提供高达300 Mbps的吞吐量。其中，双平面天线和多输入多输出（ MIMO ）技术可以为用户提供三维的、全家范围的一致信号。由于该路由器通过标签下方的两个螺钉固定在底座上，所以，要想进行物理访问，需要切开该标签。

这个路由器的外壳由六个夹子固定。我们发现，打开机箱的最简单方法是从WiFi保护设置（WPS）按钮附近的顶部开始下手，然后按照顺时针方向完成相应的操作。松开最后几个夹子时，可以借助于长平头螺丝刀或圆头螺丝刀。

打开机箱后，我们可以看到以下主要组件：带有MIPS24KEc处理器的Ralink RT3052F片上系统（SoC），以及EtronTech EM638165TS SDRAM内存。

我们看到，电路板上有3个十字螺丝，同时，PCB的下侧还有一个额外的芯片：

从这个角度来看，你可以看到Winbond W25Q16BVSIG SPI Flash芯片。

在电路板的正面，有两个调试接口，分别是位于U5和J2处的EJTAG和UART。这些东东不是很容易发现，因此，我们要仔细查找。后来，我们发现了一个由U5指示的标准14引脚JTAG头（见图8）。

对于作者使用的试验设备来说，需要对R27、R22、R21和R23电阻进行拆焊，以使EJTAG接头能够正常工作。这些电阻可能是上拉/下拉电阻，它们禁用了用于生产过程中使用的电路级调试接口。当然，我们也可以通过SoC中的控制寄存器设置来禁用JTAG接口。关于这方面内容的详细介绍，请参考 Ralink的相关文档 [PDF]，其中详细介绍了启用JTAG接口的前提条件。

与CPU进行交互

为了验证研究人员提交的漏洞，我们使用JTAG调试器 BusBlaster v3c 与Ralink 3052F SoC中的MIPS内核进行交互。除了BusBlaster之外，与CPU交互过程中还需要使用以下软件：

·Ubuntu 18.04 LTS

·  urjtag 2018.09

· OpenOCD

· GDB

· telnet

BusBlaster架构

我们发现，这个 短视频 对BusBlaster的设计理念和架构进行了全面的概述，因此，我们强烈建议您观看该视频。简而言之，BusBlaster是一个使用FTDI2232H芯片和Xilinx XC2C32A CoolRunner-II复杂可编程逻辑器件（CPLD）芯片的JTAG接口。FTDI2232H用于处理USB通信并提供基本JTAG接口，而可重编程CPLD则可以处理信号电平转换以及要支持的特定硬件接口类别方面的细节信息（在本例中为JTAGkey兼容接口）。同时，FTDI2232H向主机公开了两个USB接口。USB接口1用于重新编程板载CPLD，通过重新配置BusBlaster，可以支持各种硬件接口，包括JTAG。USB接口0用于连接实际的JTAG目标。请注意，我们需要根据自己要使用的功能（BusBlaster重新配置与JTAG目标访问）来指定相应的USB接口，因为指定错误的接口会导致混乱，从而带来不必要的麻烦。

urjtag

需要注意的是，Ubuntu存储库中提供的urjtag包的版本较低（0.1版本），并且漏洞百出。除非您喜欢处理随机分段错误，否则我们建议您自行编译最新版本。我们使用的配置选项如下所示：

./configure --with-libftdi --with-ftdi --with-ftd2xx --with-gnu-ld

完成上述操作后，请检查配置报告并确保已满足所有依赖项。

编译urjtag后，插入BusBlaster，并使用lsusb命令记下设备的VID和PID。

之后，我们就可以使用新编译的urjtag了，不过，我们需要向urjtag提供正确的VID和PID，这样就可以尝试与板载CPLD进行通信，进而测试BusBlaster的功能和完整性了。

如果一切正常的话，urjtag应该能够通过USB接口1获得板载Xilinx CPLD的器件ID和制造商信息。现在，我们已经确认BusBlaster可以工作正常，下一步是将BusBlaster配置为JTAG接口。为此，我们可以使用 Github 上提供的JTAGkey缓冲逻辑对CPLD进行编程。

完成上图中的各个步骤后，对CPLD的编程处理就算完成了，并且BusBlaster也被重新配置为支持JTAGkey兼容接口。接下来，将U5 JTAG调试端口的TDI、TDO、TMS、TCK和GND引脚连接到BusBlaster。同时，使用FT2232H的USB接口0检测Ralink SoC，并验证所有连接是否正常工作。如前所述，在与JTAG目标通信时，一定要使用USB接口0。

一切连接就绪后，整体硬件设置如下所示：

接下来，再次使用urjtag，并通过运行detect命令检查通过USB接口0连接的设备的标识符。该命令会搜索连接到JTAG接口的所有设备。

我们可以看到，urjtag已经成功读取了器件ID 0x1305224F，它对应于Ralink RT3052F SoC，具体如数据表所述。不过，urjtag无法自动打印制造商名称，因为默认的MANUFACTURERS文件中并没有提供Ralink的相关条目。

OpenOCD

测试完JTAG连接后，我们就可以使用 OpenOCD 了。首先，使用下列命令来启动OpenOCD了：

sudo openocd -c "bindto 0.0.0.0" -f ./dp_busblaster.cfg -c "transport select jtag" -f ./rt3052.cfg -d2

rt3052.cfg的内容如下所示：

这意味着允许OpenOCD与RT3052F SoC建立JTAG调试连接，并打开一个服务来侦听TCP端口4444。现在，我们就可以通过telnet与OpenOCD进行交互了。

建立连接后，GDB调试服务器将在端口3333上运行，而监视器控制台将在端口4444上运行（具体如图17所示）。我们可以使用telnet连接到监视器控制台并与目标交互，或使用GDB命令monitor。

由于我们的主机和目标的CPU架构不同，因此，这里需要使用GDB的多架构版本来连接GDB服务器。

我们的gdbscript的内容如下所示：

·set architecture mips

· set endian little

· target remote localhost:3333

· monitor halt

· monitor rt3052.cpu curstate

· continue

结束语

现在，我们已经可以通过JTAG成功连接到Ralink SoC，并具有了完整的片上调试功能。凭借些许运气和努力工作，应该能够找到一些安全漏洞：