Introduction

This blog post acts as an illustrated guide on how to identify the serial interface on the WAG54G home router, and how to solder on header pins and obtain console access to the device. This is a simple but important step for performing runtime analysis and development on these types of devices.

The world of hardware hacking for software security professionals is an area which has been gaining popularity in recent years. The simplest reasoning could be:

1. The cost of test equipment is becoming affordable to the hobbyist (oscilloscopes, logic analyzers, SDR, etc)
2. Embedded devices are powerful enough to provide rich functionality to consumers with reduced costs. These devices are often interconnected and expose attack surface relevant to security researchers.
3. The amount of introductory information for practitioners is increasing, lowering the bar to entry.

My interest in the area came about when wanting to assess the security of the WAG54G home router. I was interested in researching attack vectors allowing persistent access into a home network while leaving minimal footprint. The target environment consisted of multiple PC’s running Linux and Windows hosts, with hardened guest VM’s reverted to a clean snapshot on every boot. Rather than auditing for vulnerabilities in the hypervisor, I opted to audit the home router - a single egress point for the whole network which allows MITM and payload delivery to VM’s on every boot; it also has direct access to the internet for C&C. To do this research, I first needed to gain local access to the device.

Linksys WAG54G-AU

The Linksys WAG54G-AU is a 2.4GHz 802.11g ADSL modem/router, with a 4 port 10/100 Ethernet switch supporting network services like DHCP and VPN along with several basic network security features. The following photos show what the device looks like before and after unboxing:

Hacking

To find the devices serial interface, we will need to open the enclosure by removing the rubber feet found on its underside. This will reveal four Torx T10 screws which can be unscrewed.

For the astute reader, you may notice one of the rubber feet is “protected” with an anti-tamper label. When removed, this label will leave a “Void” message printed on the outer casing.

After removing the casing, we can look at the circuit board to manually identify components such as memory, CPU (SoC), and other IC’s such as the Wi-Fi controller. This can be useful if you want to understand at a very granular level how the components work and how you can interface with them. By reading the unique identifiers printed on each component, we can search online for the corresponding data sheets. In our case, we are only interested in identifying the pinout for serial communication, so looking up datasheets isn’t strictly necessary:

There are several methods that can be used to find the serial interface:

1. Reading the legend printed on the PCB, cross reference with data sheets or online resources for serial pinouts.
2. Identify the UART controller on the board.
3. Look for “interesting” pin configurations such as 4 pins that could be RX, TX, VCC, GND.

In our case, we opted for the last technique. Studying the underside of the PCB, it’s simple to identify through hole solder joints and their pin layouts. It’s also possible to follow the trace lines and identify which components the joints connect with.

In the above photo, we identified an interesting combination of pins in the top left corner. The following photo shows a magnified version of the underside joints, in which it’s simple to see how pins 1 and 5 are connected:

The following photo shows a magnified version from the top side of the PCB, in which it is simple to see pins 3 and 4 have trace lines connected, while pin 2 is not connected to anything:

At this point, we can use a multimeter to probe each solder joint and verify properties that can indicate what they may be used for in serial communication:

• Pin 1: This was identified as ground from a continuity test. To perform this test, place one of your probes on a grounded component such as the outer shield for the WiFi-controller, and place the other probe against each pin. If the piezo buzzer sounds, it means there is very little resistance between the two paths.
• Pin 2: This isn’t connected to anything.
• Pin 3: This appears to be RX, voltage idle with slight drop from 3.28V to 3.27V during the device boot process. This was identified by placing one probe on ground, and the other on the pin. We could see the voltage drop on the multimeter.
• Pin 4: This appears to be TX, voltage fluctuates between 2.6V to 3.28V during the device boot process. This would be related to boot messages being sent to the console. This was identified by placing one probe on ground, and the other on the pin. Reading the voltage during the bootup of the device, we could see the fluctuations on the multimeter.
• Pin 5: This appears to be VCC, voltage is idle at 3.28V for the entire time. This was identified by placing one probe on ground, and the other on the pin.

If you have not used a multimeter before or are unfamiliar with this process, there is a fantastic write-up on how to do this testing by Craig Heffner at http://www.devttys0.com/2012/11/reverse-engineering-serial-ports/.

With this information at hand, it’s reasonably safe to assume we have found the serial port and corresponding pin configuration, and can begin our testing. Using a soldering iron and sucker tool we cleared the existing solder from the joints, and soldered in the 5 header pins:

To interface with the serial port, we made use of the Bus Pirate from dangerousprototypes. They have good documentation on how to communicate over a variety of protocols, and in our case we used the following:

The bus pirate IO Pin descriptions: http://dangerousprototypes.com/docs/Bus_Pirate_I/O_Pin_Descriptions

The bus pirate UART configuration: http://dangerousprototypes.com/bus-pirate-manual/bus-pirate-uart-guide/

With the following pin configuration:

• Bus Pirate (MOSI) -> Pin 3
• Bus Pirate (MISO) -> Pin 2
• Bus Pirate (GND) -> Pin 1

After connecting the bus pirate to the WAG54G, we also needed to connect it to our workstation. This can be done following these steps:

1. Connect the bus pirate over USB to the Windows workstation
2. Open device manager, identify the COM port assigned to the bus pirate under Ports (COM & LPT). In our case, it’s COM4.
3. Open Putty, select the “Serial” radio button. Enter COM4 into the “Serial line” input box.
4. Change the baud rate to 38400bps.
5. Click Open

After connecting the bus pirate to the workstation, the last step is to configure it for serial communication. Using our Putty session, execute the following commands:

m
select UART (3)
select 38400bps (7)
select 8,NONE (1)
select 1 stop bits (1)
select idle 1 receive polarity (1)
select normal (H=3.3V,L=GND) (2)
look at the macro menu (0)
select (3) bridge mode.

We have now successfully connected the bus pirate to our workstation and WAG54G. We can power up the router, and see the Putty session filled with log messages from the Linux boot process.

Conclusion

At this point we have successfully gained console access to the WAG54G over its serial interface. This is useful for accessing the device while performing security research/exploit dev, and can be a starting ground for further hardware hacks (such as attaching a USB drive for tool storage, or reflashing the firmware). In a future blog post, I will cover the methods used for auditing for vulnerabilities and how this console access was useful in exploit development.