Hardware Hacking I: Playing around with routers
Introduction
This is the first part of a series of articles I will post to talk about hardware hacking and share what I learned during the analysis. In this one in particular, I will talk about what I found analyzing a relatively old router that I bought last month at a street market in my neighborhood.
I will bring some interesting content that I found when analyzing this equipment just by reading the router label, and how to find the correct UART pins to communicate with the router. I really suggest you read more about what the UART protocol is, but in summary this protocol uses two pins for data transfer, one to send and another to receive, and other two for ground and power supply. As we will see, we don’t need to use this last one since the equipment is already turned on by the power supply cable.
After some hours studying about this topic, I decided to buy old devices and start practicing what I have learned. At the market I bought three routers for R$30.00 ( roughly US$ 6.00), two of them are the exact same, a dsl-100hn-t1-nv, and they will be the focus of this article. The strategy of getting two of the same device is desired because if any problem happens (yes, it happened), I will have another one to continue the research.
Let’s Go, Kitty!
I started analyzing the information printed under the router, in the router label, such as the MAC address, the SSID and, correlating it with the default password, I got some interesting information which I hadn’t ever paid much attention to before studying this topic. What I initially noticed was the following:
- The Serial Number, SN, is equal to MAC Address;
- The SSID is the name of the ISP along with the last 2 bytes of the MAC, “E8B0”;
- The default password of the router is the last 5 bytes of the MAC address, “33D717E8B0”.
Opening the router case, I quickly identified the UART pins since the male pins were already soldered on the board. The EEPROM (Electrically Erasable Programmable Read-Only Memory) was really close to the soldered pins and, because of that, I needed to warp this a little bit to be able to connect the ch341a, an EEPROM extractor, on the memory, but it’s material for another post.
I will discuss more about the memory in the next post, but I have some useful information I want to say here for those who want to enter this area. First, I wasn’t able to read the memory chip name because it was blanky but we have methods like chalking over to make the words more visible. Second, you may not want to spend so much time with it since you can get this information and more about the EEPROM via UART protocol, during the router boot, as we will see below.
To communicate with the router using the UART interface we need a serial to USB converter and I used the PL2303 for that. In a UART connection, one thing you need to pay attention to is to connect the sender pin, also known as TX, of the converter to the receiver, also known as RX, of the router and vice-versa, since one will read what the other is sending.
So, using a multimeter in continuity test mode, I was able to identify the ground pin testing each UART pin with the negative leg of the capacitor present on the circuit (it’s the leg below the gray line). After that, I needed to discover which pin is the output voltage, the Vcc. To do that, I turned on the router and tested every pin to find out which one had a more stable voltage, and to do that I put one probe on the ground and another on the pin that I wanted to test. Doing that, I found that the last pin, to the left to the right, was the Vcc. I didn’t need to use this pin since the circuit already will be charged by the 12V power supply.
At this point, if I make any mistake guessing which pin is the TX or the RX I will not blow the board. So, to identify which one is the TX, I booted the device and with one probe of the multimeter on the ground and another taking turns testing the two pins left, I paid attention to identify which one had more voltage variation and which one was less variation and/or voltage equal to zero. The pin with more variation during the boot probably is the TX and the one with less variation or zero voltage will be the RX. It happens because, when a device is booting, a lot of information is transmitted so we have more voltage variation on TX because of this data transfer.
At some point of the research I accidentally dropped my phone on the board trying to take pictures of the connections. Since I bought two units of the same router, I was able to continue the research taking more care in this last shoot. The broken router board started to get really hot and the UART Vcc dropped from 3.3V to 0.28V. Probably a short circuit happened and, because of that, I started again with another router.
This accident didn’t make the broken router totally useless. In the second part of this series I will try to read the EEPROM of this broken router and fortunately, it will work. It’s possible because when we are interacting with the EEPROM using a tool like CH341a, we don’t need to turn on the equipment as a whole, just the memory, and the tool provides connections to do that. It’s done this way since we don’t want interference caused by a concurrency reading between the CH341a and the rest of the device.
Continuing, I used a handful command to prompt a shell and interact with the router called screen. To do so, I need to know the tty device of my converter and the baudrate. The first one was easy to find because I just have one connected to my laptop, so I ran the ls /dev/tty* command and found that was /dev/ttyUSB.
Now we need a few things before being able to see the router’s boot data and interact with it using the UART. First, we must identify where the serial to usb converter was mounted and to do so I just runned the `ls /dev/tty*` and found it on /dev/ttyUSB. Then, we need a tool to see the bootloader output and send commands to the router, and to do so we can use the `screen` command. The Screen command is a tool that enables us to open a shell session passing the port where the device was mounted, in this case /dev/ttyUSB, and the baud rate. Since in UART communication we don’t have any wire to share the baud rate (bits per second) we need to discover it by guessing. Exists tools to brute force and automate the process of guessing but just testing the more common baud rates, like 19200, 115200, 38400 and 57600, I was able to identify that the 115200 was the correct one.
Nice! Now I was able to read the initial logs generated during the boot process and I stopped it to interact with the U-boot, the bootloader. The HELP command gave me the list of available commands. It has some useful commands like: ATSH, which prints more information about the device; ATEN, which switches the router to debug mode to unlock more commands. For example, one of the debug commands permits me to dump the memory via UART (which is very slow because of baud rate).
Running ATSH I was able to get more information about the manufacturer, checksums and other interesting information.
Proceeding to full boot of the system, I used the flag “-L” so the screen command will save the logs into a file to better analyze the output when the boot completes. The more relevant information gather was:
- Linux version: 2.6.36 (gcc 4.3.4);
- Memory location of each partition, which will be used later to dump the filesystem and the firmware;
- EEPROM name and type, a SPI Flash MX25L12805D;
- Used softwares and its versions.
At the end of the boot process, a /bin/login was prompted to authenticate and access the router CLI. In the next post I will talk more about interesting things found during the firmware analysis.
Conclusion
For me, the funny part of pentesting a hardware compared to a web server is that you make more things with your hands, will get stuck more often in problems that you can’t easily find the solution on the internet, and will need to find how to solve the problem on your own. I don’t have a big background in this area, so if something wasn’t clear or if you think that I made some wrong assumptions, please get in contact with me via email or LinkedIn, it will be very helpful!
I see you in the next post!
