Serial Communication

For any IoT or embedded device, the different components of a device need to interact with each other and exchange data. Serial communication and parallel communication are the two ways in which components on a device exchange data.

As the name suggests, serial communication is used to transfer one bit at a time through a given medium (see Figure 4-1), whereas in parallel communication, a block of data is transferred at the same time with each of the bits requiring a separate channel (and additionally a reference line—typically ground).

Because parallel communication transfers a huge chunk of data at a time, this method requires several separate lines to facilitate the communication. As you can imagine, this would result in the requirement for more real estate on the board, which is often not preferred. A parallel communication protocol is shown in Figure 4-2.

That is the reason serial communication is a more common method of communication whenever we deal with embedded devices: Unlike parallel communication it requires just a single line to facilitate the data exchange.

Some of the popular serial communication channels you might have heard are Recommended Standard 232 (RS232), Universal Serial Bus (USB), PCI, High-Definition Multimedia Interface (HDMI), Ethernet, Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I²C), Controller Area Network (CAN), and so on. The first serial communication channel used was RS232, which offered a data transmission rate of 20 kbps; then came the USB 1.0, offering rates of 12 Mbit/s; followed by USB 2.0, with a speed of 480 mbps; and finally the USB 3.0, with a speed of 5 Gbps—almost 10 times faster than its predecessor. It should also be noted that due to recent advancements in technology, serial communication is getting cheaper, faster, and more reliable.

Now that we have a basic idea of serial communication and some of its examples, let’s move on to UART, which is what we focus on in this chapter.

The What, Why, and How of UART

UART, as described earlier, is an asynchronous serial communication protocol used in many embedded and IoT devices. Asynchronous simply means that unlike a synchronous protocol (e.g., SPI), it does not have a clock that syncs for both the devices between which the communication taking place.

The data in the case of UART would be transferred without the need for an additional line of external clock (CLK). This is also why many other precautions are taken while transferring data asynchronously between devices over serial to minimize packet loss. We discuss baud rate, which will make this clearer to you, in later sections of this chapter.

UART Data Packet

You might be able to understand it much better way with the visual representation given in Figure 4-3.

Most of the devices that I’ve encountered use the configuration of 8N1, which means eight data bits, no parity bits, and one stop bit (see Figure 4-4). We can understand this better if we hook up a logic analyzer to a device’s UART interfaces. A logic analyzer is a device that helps you display various signals and logic levels from a digital circuit. It’s extremely easy to use and straightforward to set up with the protocol or communication that you are trying to analyze. I would recommend getting a good logic analyzer such as the Saleae Logic Analyzer or Open Workbench Logic Sniffer for all your logic analyzer purposes.

Baud Rate

Working with UART and discussing the nonrequirement of CLK brings us to the concept of baud rate, which specifies the rate at which data are transferred between devices, or more appropriately, the number of bits per second that are being transferred. This is required because there is no clock line in the case of UART communication, so both the communications need to have a mutual understanding of the speed of data communication. That is why both the components will agree on a single baud rate during the entire UART data exchange process.

During any of the UART exploitation that you perform in your security research journey, one of the initial steps will always be to identify the baud rate of the target device. This can be done in a number of ways, such as looking at the output while interfacing over serial at a given baud rate, and if the data appears to be not readable, moving to the next baud rate. To make things easier, there are a couple of standard values of baud rate to which you will find most devices adhering. The common baud rates are 9600, 38400, 19200, 57600, and 115200. Having said that, a device developer is free to choose a custom value for baud rate.

To identify the correct baud rate using the approach just mentioned, we use a script written by Craig Heffner, called baudrate.py available at https://github.com/devttys0/baudrate/blob/master/baudrate.py . This script allows us to change baud rates while maintaining a serial connection, to easily identify what the correct value of the baud rate is by looking at the output and visually inspecting which baud rate gives readable output.

Before connecting to a device over serial and identifying baud rate values, let’s first go through the hardware connections that need to be made to interact with the target device over UART and exploit the device.

Connections for UART Exploitation

To perform a UART-based exploitation, we need two primary components: the target device and a device that could emulate a serial connection to access the end device, so that the target device is able to interact with our system.

To make the connections, we first need to identify where the UART port on the device is, or what the UART pins are. This can be done by a visual inspection of the internal device components and looking for three or four pins or pads close to each other. That is an easy way to find UART pins, but in some cases, you might also encounter devices that have the UART pins scattered across the board and not together at a single place. Figures 4-5 through Figures 4-7 are references to help you identify UART ports in your target device.

CASE 1 —EDIMAX 3116W

CASE 2 —TP-LINK MR3020

CASE 3 —HUAWEI HG533

To find all these pins, we use a multimeter that helps us identify the pins based on either the continuity test (for GND) or by looking at the voltage difference (for the remaining three pins).

A multimeter is a combination of a voltmeter and ammeter, which means it allows us to look at both the value of voltage and the value of current during the analysis. This is extremely useful. Even though most of the time we will be simply looking at the voltage value, in some cases, you might be required to look at the value of current flowing between two different pins to perform further analysis. Let’s get started.

Identifying UART Pinouts

As mentioned earlier, a multimeter is a device that can measure voltage (V), current (A), and resistance (R), thus the name multimeter—a combination of both voltmeter and ammeter.

We will keep the target device powered off initially, as we are going to perform a continuity test to identify ground.

To use a multimeter, plug in the probes as shown in Figure 4-8.

Once the multimeter is connected, let’s go ahead and find the different UART pinouts as described in the following steps.

1. 1.

   Place the black probe on a ground surface; this could be any metallic surface (e.g., the Ethernet shield of the device) or the GND of the Attify Badge. Place the red probe on each of the four pads individually. Repeat with the other pads until you hear a beep. The place where you hear a beep is the ground pin on the target device. Make sure your device is turned off. One of the other things to note here is that there will be a number of ground pins or pads on the target device, but we are only concerned with the GND in the UART pin pair.

   Ensure that your multimeter is as shown in Figure 4-9.

   

    
2. 2.

   Put the multimeter pointer back to the V–20 position, as we are now going to measure voltage. Keep the black probe to GND and move your red probe over other pins of the UART (other than the GND). Power cycle the device and turn it on. The place where you see a constant high voltage is the Vcc pin. If you miss it on the first try, power cycle it again.

    
3. 3.

   Reboot the device again and measure the voltage between the remaining pads and GND. Due to the huge amount of data transfer initially during bootup, you will notice a huge fluctuation in the voltage value during the initial 10 to 15 seconds. This pin will be the Tx pin.

    
4. 4.

   Rx can be determined by the pin having the lowest voltage during the entire process, with the black probe connected to the GND of the Attify Badge. Alternatively, you will usually have only a single pin left by this step, which will be Rx.

    

By now you should have been able to successfully identify all the different pins present in the UART of your target device. Make note of these values because we are going to be using this while making our connections.

Note

You could also analyze these values by hooking up a logic analyzer and looking at the values that are being passed.

Introduction to Attify Badge

One of the tools that is an absolute necessity in an IoT pentester’s arsenal is a device capable of working with different hardware communication protocols. The tool that we are going to use for all our hardware exploitation needs is Attify Badge.

The Attify Badge is a multipurpose tool that helps you communicate to other IoT/embedded devices over various communication interfaces such as UART, SPI, I²C, and even standards such as JTAG. It uses an FTDI chip that allows it to convert the hardware communication protocol in a language that is understood by our systems. Figure 4-10 shows an Attify Badge.

The tool contains a total of 18 pins out of which 10 pins are for voltage (3.3V and 5V) and ground, which are the top nine pins and the bottom right pin. As seen in Figure 4-11, the pins D0 through D3 serve special a purpose when it comes to interacting with embedded device hardware.

Table 4-1 provides the pinouts for Attify Badge for interacting with different hardware communication protocols.

Table 4-1

Attify Badge Pinouts

Pin	UART	SPI	I2C	JTAG
D0	TX	SCK	SCK	TCK
D1	RX	MISO	SDA*	TDI
D2		MOSI	SDA*	TDO
D3		CS		TMS

To connect the Attify Badge to our system, we will need to use a micro USB cable. If you are using AttifyOS or running on Mac OS, you do not need any special tools to work with Attify Badge. However, on Windows, you might need to download the FTDI driver available from https://www.ftdichip.com/FTDrivers.htm to get the device working with your system.

To verify it is has successfully connected, you can run lsusb (on a Linux machine), which would show you a device listed as Future Devices Technology International, which is the Attify Badge.

Making Final Connections

Once you have identified the pinouts of the device, the next step will be to connect the device’s UART pins to the Attify Badge’s UART.

Attify badge pins that we are concerned with at this point in time are D0 and D1, which stand for transmit and receive, respectively. The IP camera’s transmit (Tx) would go to the Attify Badge’s Rx (D1), and vice versa for Rx of IP camera and Tx(D0) of the Attify Badge, connected using jumper cables. The GND of IP camera would be connected to the Attify Badge’s GND. Table 4-2 simplifies the connections for you.

Table 4-2

Connections for Target IoT Device to Attify Badge for UART Exploitation

Pin on IP camera	Connected to the Attify Badge
Tx	D1 (as D1 is the Rx for badge)
Rx	D0 (as D0 is the Tx for badge)
GND	GND
Vcc	Not connected

Remember to not connect the Vcc of the IP camera, as doing that would risk permanent damage to your device. Go ahead and make the connections between the IP camera UART ports and the Attify Badge using the jumper wires, and connect the Attify Badge to your system. Figure 4-12 shows the final connection.

That is all the connections required to perform the UART-based analysis and exploitation.

Identifying Baud Rate

As discussed earlier, baud rate is the first thing we should identify whenever we are performing a UART-based exploitation. We use the script baudrate.py, as mentioned earlier. Before proceeding, we need an additional piece of information, which is the device entry of the Attify Badge connected to our laptop. This can be found by looking at the entries of /dev/ as shown in Figure 4-13.

As you can see, we have our entry listed in the image at the COM port /dev/ttyUSB0, which is also the default COM port used by baudrate.py. Go ahead and run it:

git clone https://github.com/devttys0/baudrate.git

sudo python baudrate.py

You might see gibberish data at first as soon as the IP camera boots up because the device might not be configured to transfer data at the default value baudrate.py chooses. Use the up and down arrow keys to move between different values of the baud rate. The baud rate where you can see readable characters is the correct baud rate of the device. In our case, the correct baud rate is 38400. If you don’t see any data at all, reboot the device and make sure that the connections are right, with the correct values of Tx and Rx.

That is how to identify the baud rate of any target device.

Interacting with the Device

Once we have identified the correct baud rate, the next step is to interact with the device over UART. This could either be done through the baudrate.py script itself, by pressing Ctrl+C once it detects the correct baud rate, lauching a utility called minicom. The other way is to manually launch a utility, such as screen or minicom, with the identified configurations.

We therefore have both the data values we require here:

1. 1.

   Baud rate of the device: 38400

    
2. 2.

   COM port used by the Attify Badge: /dev/ttyUSB0Let’s go ahead and launch screen with the previously given values.

   sudo screen /dev/ttyUSB0 38400
    

Run this command and reboot the device to be able to see the debug logs of the device booting up as shown in Figure 4-14 .

If we wait for a couple more seconds for the device to boot completely and load up busybox, we will have a full unauthenticated root shell on the IP camera as shown in Figure 4-15.

Congratulations! You now have a complete unauthenticated root shell to the device. You can perform several things here, such as analyzing the device’s file system, modifying some of the configurations, identifying hidden sensitive values, dumping the firmware, and so on.

You can also use the Attify Badge tool (Figure 4-16) available at https://github.com/attify/attify-badge to perform this process using a graphical user interface (GUI).

During your IoT security research journey, you will be surprised by the number of real-world commercial devices that grant you unauthenticated root access to the device.

Some of the things to take a note of while performing UART exploitation, are as follows:

• Make sure the connections are correct; that is, Tx from one device goes to the Rx of others and Rx of the other goes to Tx.

• GND is connected to other device’s GND.

• Vcc is not connected to anything.

• The value of baud rate is correctly identified, otherwise you might see nonreadable data.

• Make sure you use a proper voltage converter when using a 3.3V serial device to a 5V serial device or other voltage levels.

Conclusion

In this chapter, we had a look at how we can get started performing embedded device exploitation for IoT devices using serial communication, and specifically, UART.

UART will be useful for you at a number of places, and you’ll often encounter devices with no protection, giving you access to an unauthenticated root shell over UART.

I would highly recommend you try additional activities once you have UART access, such as interacting with the bootloader, modifying certain values in configurations, figuring out ways to dump firmware over UART, and so on.