MindShaRE: Hardware Reversing with the Belkin Surf N300 Router

MindShaRE is our periodic look at various reverse engineering tips and tricks. The goal is to keep things small and discuss some everyday aspects of reversing. You can view previous entries in this series here.

In late 2018, the ZDI received a collection of submissions affecting a version of SuperTask! RTOS that runs on a collection of devices. These bug reports were submitted by two new researchers to the program: Josep Pi Rodriguez and Pedro Guilln Nuez. One of the routers on the affected device list was the Belkin Surf N300 router (Model number F7D2301).

A large part of the materials in this blog were developed by the researchers, with the addition of lessons learned during the reproduction and verification of their research. While the bugs are still in the disclosure phase, we would like to share what we have learned in our venture into embedded software vulnerability research. In this blog, we will walk through the process of configuring a JTAG tool, attaching it to the target and getting GDB running.

Specifically, we’ve tested these vulnerabilities against the Belkin Surf N300 router, model number F7D2301, hardware version 1.

This router uses 802.11n technology and provides up to 300 Mbps throughput. Dual-plane antennas and Multiple In Multiple Out (MIMO) technology provide three-dimensional, whole-home coverage for consistent signal. The router is attached to its base by two screws under the label. We had to cut open the label to access them.

The case is secured with six clips. We found the easiest way to open the case is by starting at the top clip near the WiFi Protected Setup (WPS) button and working our way clockwise. Occasional uses of a long flat-head screwdriver or spudger helped persuade the last few clips to be undone. 

With the case open, we can see the following major components: a Ralink RT3052F System-on-Chip (SoC) with a MIPS24KEc processor and an EtronTech EM638165TS SDRAM.

Three Phillips screws hold down the board, and the underside of the PCB contains one additional chip:

From this view, you can see the Winbond W25Q16BVSIG SPI Flash chip.

On the front side of the board, there are two debugging interfaces, EJTAG, and UART (baud rate 115200) located at U5 and J2 respectively. These are not always easy to spot, so a thorough search is often required. In this case, we notice a standard 14 pin JTAG header indicated by U5 (see Figure 8 below).

In both our and the researcher’s setup, the R27, R22, R21 and R23 resistors need to be desoldered for the EJTAG header to work properly. These are presumably pull up/down resistors that disable the debugging interface for production run on the circuit level. The JTAG interface maybe disabled by the control register settings in your SoC. You should check out the Ralink documentation [PDF] for the preconditions for enabling the JTAG interface.

Talking to the CPU

In order to verify the vulnerabilities submitted by the researchers, we used a BusBlaster v3c JTAG debugger to interact with the MIPS core in the Ralink 3052F SoC. Along with the BusBlaster, we used the following software to interact with the CPU:

-   Ubuntu 18.04 LTS
-   urjtag 2018.09
-   OpenOCD
-   GDB
-   telnet

BusBlaster Architecture

We found this short video provides an in-depth overview of the BusBlaster design philosophy and architecture. We strongly recommend you watch the video should you choose to use one. In short, BusBlaster is a JTAG interface that leverages the FTDI2232H chip and the Xilinx XC2C32A CoolRunner-II Complex Programmable Logic Device (CPLD) chip. The FTDI2232H handles USB communication and provides a basic JTAG interface while the reprogrammable CPLD handles signal level translation and details relating to the specific hardware interface type to be supported (in this case, a JTAGkey compatible interface). The FTDI2232H exposes two USB interfaces to the host. USB interface 1 is used to reprogram the onboard CPLD, allowing the BusBlaster to be reconfigured to support various kinds of hardware interfaces, including JTAG. USB interface 0 is used to interface to your actual JTAG target. Pay careful attention to specify the correct USB interface according to the function you wish to perform (BusBlaster reconfiguration vs JTAG target access) as specifying the wrong interface can lead to confusion and unnecessary debugging efforts.

urjtag

The urjtag package provided in the Ubuntu repository is old (version 0.1, from 2007) and buggy. Unless you like to deal with random segmentation faults, we recommend compiling the latest version on your own. We used the following configure options:

With the newly compiled urjtag, test the BusBlaster’s functionality and integrity by attempting to communicate with the onboard CPLD by providing the correct VID and PID to urjtag.

urjtag should be able to obtain the Device ID and manufacturer information of the onboard Xilinx CPLD via USB interface 1.  Now that we’ve verified the BusBlaster is in working order, the next step is to configure the BusBlaster to work as a JTAG interface.  To do this, we program the CPLD with the JTAGkey buffer logic available at Github.

After performing the steps in the above image, the CPLD has been programmed and the BusBlaster reconfigured to support a JTAGkey compatible interface. Next, connect the TDI, TDO, TMS, TCK and GND pins of the U5 JTAG debugging port to the BusBlaster. Use USB interface 0 of the FT2232H to detect the Ralink SoC and verify all connections are working properly. As previously noted, ensure you use USB interface 0 when attempting to communicate with your JTAG target.

Once everything was connected, the overall hardware setup looked as follows:

We can see that urjtag has successfully read the device ID 0x1305224F, which corresponds to the Ralink RT3052F SoC as noted in its datasheet. urjtag was unable to automatically print the manufacturer name because the default MANUFACTURERS file does not contain an entry for Ralink, which is not a concern.

OpenOCD

With the JTAG connection tested working, we are ready for OpenOCD. Launch OpenOCD using the following command:

This allows OpenOCD to establish a JTAG debug connection with the RT3052F SoC and opens a service listening on TCP port 4444. We now can interact with OpenOCD via telnet.

Since the CPU architecture of our host and target are different, we will need to use the multi-architecture version of GDB to connect to the GDB server.

Conclusion

And there we have it! We have now successfully connected to the Ralink SoC via JTAG and have full on-chip debugging power. With some luck and hard work, you should be able to find some bugs and make something like this happen:

Tips for submitting bugs concerning hardware

To help us verify your hardware-related submissions, include as much information as possible and document all your steps. The following list should give you some idea.

Give us all the versions!

·   Hardware Name, model number
·   Circuit board version
·   Firmware version

 Documentation

·   How did you obtain the firmware?
o   e.g. Flash dump via flashrom
o   e.g. Vendor firmware download link
·   How did you test your PoC/exploit?
o   Physical hardware
o   Emulation
·   Did you emulate the firmware? If so, how?
o   e.g. QEMU set up files/disk images/configuration files.
o   e.g. NVRAM library emulation code
·   Did you attach a hardware debugger?  If so, how did you connect to the hardware?  Were any hardware modifications required?
o   Describe any hardware modifications with text and pictures
o   e.g. Removal of pull up/down resistor
o   Describe exactly the hardware tool and how it is connected with text and pictures
o   e.g. Where are the pin header locations and what are the pinouts? 
o   Provide all hardware documentation available
o   e.g. Schematics, PCB layout, theory of operation, circuit description, etc.
·   Describe any other useful interfaces found including serial UARTs, consoles, etc.

Optional, but highly recommended:

·   High resolution, in focus photos of all circuit boards, front and back.
o   Both PCB designators and IC markings should be clearly visible across the entire board
·   Purchasing link

Acknowledgements

Lastly, I would like to thank the researchers Josep Pi Rodriguez and Pedro Guilln Nuez for their patience and support during the verification phase of the submission. I would also like to recognize the help that I received from Jonathan Andersson and Ricky Lawshae. Without their guidance and persistent help this blog would not have been possible.

I hope to see your hardware-related bug reports in the future. Until then, you can find me on Twitter @TrendyTofu, and follow the team for the latest in exploit techniques and security patches.